數據湖近幾年迅速躥紅，今天筆者做一個綜述，包括數據湖的緣起、數據湖的定義、數據湖的特征、數據湖的技術、數據湖的趨勢和數據湖的案例六大部分，如果你要入門數據湖，一定要看一看。

注：文末列出了所有參考文獻，方便你拓展閱讀。

一、數據湖的緣起

10年前，Pentaho公司（一家開源BI公司）的CTO詹姆斯·迪克森在他的博客中第一次提出“數據湖”（Data Lake）的概念；10年后的今天，在業界“數據中臺”大火的時代背景下，再來討論“數據湖”，應該別有一番韻味。

1、從事務系統到數據倉庫

要了解數據湖的來龍去脈，首先得提數據倉庫的緣起[1][2]。

“數據倉庫”，由比爾·恩門（Bill Inmon）于1990年提出，其被廣泛接受的定義是，一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支持管理決策，通常也被認為是決策支持型應用的必要條件。

此處的定義大多都是針對事務型數據系統而制定的。所謂事務型數據系統，是指記錄業務交易的系統，這個名詞先是在金融業，特別是銀行實施信息化IT系統時使用的。例如銀行的交易流水數據庫，每分每秒都有大量的交易被數據庫所記錄并持久化的保存下來，其最小的顆粒度就是一筆“交易”。

但事務性數據系統存在諸多劣勢：試想，如果一個銀行的分行長想知道今天到目前為止共有多少現鈔存款入賬，那么系統就需要遍歷今天截止到目前的所有交易行為，并篩選其中的存款行為進行匯總。查詢交易的行為需要遍歷當前系統的所有記錄，因此當這一行為頻率變高時，會對數據系統造成巨大的讀取壓力。

除開查詢或分析任務對事務型數據系統造成的資源壓力外，系統執行任務時，返回的結果只代表著任務開始運行那一刻的數據狀態，假設執行查詢任務消耗了1分鐘，這1分鐘內很有可能發生多次的交易撤銷、額度修改，增加交易等行為。有些數據系統允許在讀取數據的同時寫入數據，那么查詢任務返回的結果并不能代表最新的狀態；有些數據系統則有“讀鎖”，即在讀取數據的時候不允許寫入數據，那么這個長達1分鐘的查詢任務會使得業務交易失敗或者暫緩進入數據系統，如果其中發生業務中斷，這些交易數據可能面臨丟失的風險。

當然，我們可以通過技術手段來避免或緩解事務型數據系統的不足，因此事務型的數據庫并不是不能做業務分析，只是當決策者需要進行經營性的分析和決策時，大多數時候它并非最優方案。此時，數據倉庫面向主題且便于分析的優勢就體現出來了：

數據倉庫是面向主題的。相對于事務型系統將交易類型（存款）、交易幣種（人民幣或外幣）、交易數值（存款額）以一條事務（Transcation）的方式存儲，數據倉庫通常會將一條事務中的不同信息拆分到不同的主題域中分別存儲，例如交易類型表、交易幣種表和交易額度表等。

數據倉庫是集成的。不同主題域中的信息之間以統一的ID，如交易流水號為標識進行鏈接。這樣的好處是當分行長想知道今天到目前為止一共有多少人民幣存款入賬時，只需要先篩選出交易類型為存款，交易幣種為人民幣的交易流水號，再基于這些流水號去匯總交易額度，比起原先需要遍歷全部交易記錄后才能匯總的方式大大節約了系統資源的開銷。

數據倉庫是相對穩定的。數據倉庫通常以時間窗口作為數據批量導入的分區，例如每一小時或一天從事務型系統導入一次數據，在下一次數據導入任務開始之前，系統處于一個相對穩定的狀態，有利于進行經營性的業務分析。

數據倉庫是反映歷史變化的。正是由于通常數據倉庫中的數據是基于預先設定好的時間窗口從事務型系統中獲取數據，無論是一分鐘、一小時還是一天、一周，它都是可以反映數據整體歷史變化的，分行長可以清楚地知道今天銀行的人民幣存款入賬環比昨天增長或減少了多少，同比上個月的今天又發生了什么變化。

因此，比起事務型的數據系統，數據倉庫能更有效地對業務數據進行統計分析，無論是在提高效率、穩定性還是降低資源成本上都有其優勢，所以被廣為接受而大行其道。

2、從數據倉庫到數據集市

后來，數據倉庫領域的大師Ralph Kimball又演化出“維度建模”的概念，認為數據倉庫是一系列數據集市的集合。如果說數據倉庫中包含著許多不同的主題域，那么數據集市可以理解為主要面向業務應用的單一主題域。

比如，分行長可以建設面向存儲部門的、專門提供存款數據的“存款數據集市”，面向商業貸款部門的“貸款數據集市”，面向信用卡部門的“信用卡數據集市”等，其數據都源自數據倉庫，但數據集市的匯總程度更高、更注重業務表示。例如“環比存款增長率”這個指標在數據倉庫中可能表示為“上月存款額”和“本月存款額”兩個不同的數值，而在數據集市或者數據倉庫的“集市層”中，就表示為計算后的一個數值，可以直接被業務所用而無需再做多余的計算。

3、數據湖的由來

數據湖最早是由Pentaho的創始人兼CTO， 詹姆斯·迪克森，在2010年10月紐約Hadoop World大會上提出來的。當時Pentaho剛剛發布了Hadoop的第一個版本。在這樣的一個大背景下，可以合理的猜測，當時James Dixon提出數據湖的概念，是為了推廣自家的Pentaho產品以及Hadoop的。

Pentaho是個BI分析組件。當時的BI分析主要是基于數據集市（Data Mart）的。數據集市的建立需要事先識別出感興趣的字段、屬性，并對數據進行聚合處理。這樣BI分析面臨兩個問題：

（1）只使用一部分屬性，這些數據只能回答預先定義好（pre-determined）的問題。

（2）數據被聚合了，最低層級的細節丟失了，能回答的問題被限制了。

而基于Hadoop的BI分析，可以解決這個問題——把所有數據都原樣存在Hadoop中，后面需要的時候再來取用。如果說數據集市、數據倉庫里面是瓶裝的水——它是清潔的、打包好的、擺放整齊方便取用的；那么數據湖里面就是原生態的水——它是未經處理的，原汁原味的。數據湖中的水從源頭流入湖中，各種用戶都可以來湖里獲取、蒸餾提純這些水（數據）。

接下來發生的事件讓數據湖的內涵獲得了拓展，這是詹姆斯·迪克森沒想到的。

2011年，福布斯在文章《Big Data Requires a Big, New Architecture》中報道了“data lake”這個詞，并給出了數據倉庫與數據湖的對比：數據倉庫的數據在被集成時就會被預先分類，并以最優的方式進行存儲，以支撐特定的分析；但在大數據時代，我們從源系統抽取數據時可能無法明確知道這些數據的價值，因此無法給出一個最優的存儲方式。

例如，分行長從交易系統中將所有的數據都抽取過來，但并不知道業務部門想做什么類型反映業務歷史的變化。因此建議將這些數據先保存在一個海量的數據庫中。由于數據來源的格式五花八門而且會越存越多，因此這個數據庫需要具備容易訪問且存儲成本低（允許硬件資源擴容的成本而盡可能降低其他成本，例如軟件使用費用、人工維護費用等）的特性，需要進行分析時，再來組織和篩選所需數據，這個數據庫就是數據湖（Data Lake）。

彼時的數據湖概念更多地是關于當企業在處理海量異構的數據時，如何在數據產生實際的應用價值之前，為海量數據構建一個易訪問且成本低的存儲方式，和數據資產化、資產服務化等當下熱點名詞并沒有太大關系。

2014年，福布斯雜志上刊登了一篇名為《The Data Lake Dream》的文章，文章作者EddDumbill描述了數據湖的愿景：

（1）融合所有數據，解決系統間數據孤島、各類應用統一訪問問題；

（2）數據可獲取性提高，應用部署時間縮短；

（3）具有彈性的分布數據處理的平臺，能同時支撐批量和實時數據操作處理和分析；

（4）數據湖增加安全和管控層面的功能；

（5）重視集中、自動的元數據管理和入湖標準，避免成為沒有價值的數據。

數據湖可以解決數據孤島問題這種特性似乎也挺符合數據湖的理念的。各種數據源都匯聚到一個湖里，自然就解決了數據孤島問題，但這應該并不是James的本意。從他后來的blog中可以看出，他所認為的數據湖是這樣的：

（1）數據湖應該是來源于單一的數據源；

（2）你可以有多個數據湖；

（3）如果存儲來自多個系統的數據并對他們進行關聯，那么這不是數據湖，而是由多個數據湖填充而成的水上花園（Water Garden）

不過，創始人怎么想已經不重要了……目前大家普遍認為，解決數據孤島是數據湖的一大特點，畢竟這是一個看上去很美好的事。

然后云計算的“XaaS”的風潮助推了數據湖的興起，例如軟件即服務（SaaS，Software as a Service），平臺即服務（PaaS，Platform as a Service），基礎設施即服務（Iaas，Infrastructure as a Service）。從這個時候開始，單純的數據湖就朝向一個“平臺級的方案”而演進。

數據湖從本質上來講，是一種企業數據架構方法。物理實現上則是一個數據存儲平臺，用來集中化存儲企業內海量的、多來源，多種類的數據，并支持對數據進行快速加工和分析。

目前Hadoop是最常用的部署數據湖的技術，以前這個概念國內談的少，但絕大部分互聯網公司都已經有了，國內一般把整個HDFS叫做數據倉庫（廣義），即存放所有數據的地方，而國外一般叫數據湖（data lake）。

真正將數據湖推而廣之的是亞馬遜AWS。AWS 構筑了一套以 S3 為中心化存儲、Glue 為元數據服務，E-MapReduce、Athena 為引擎的開放協作式的產品解決方案，AWS 之后，各個云廠商也紛紛跟進數據湖的概念，并在自己的云服務上提供類似的產品解決方案。

2014年6月26日，西瓜哥在“高端存儲知識”公眾號發表了一篇文章”你知道數據湖泊（DATA LAKE)嗎?”一文，首次把數據湖這個概念引入中國。由于那時還沒有標準的翻譯，為了和數據倉庫術語字數對齊，翻譯成數據湖泊。

現在，數據湖已經得到快速發展，很多廠商都推出了自己的解決方案。當前商業的數據湖產品包括AWS數據湖、華為數據湖、阿里云數據湖、Azure數據湖，開源的數據湖產品包括delta、iceberg和hudi等等。

二、數據湖的定義

下面是維基等組織給出的數據湖的早期定義，隨著數據湖的發展，其實數據湖早已不是原來的“湖”的概念了：

Wikipedia：

數據湖是一類存儲數據自然/原始格式的系統或存儲，通常是對象塊或者文件。數據湖通常是企業中全量數據的單一存儲。全量數據包括原始系統所產生的原始數據拷貝以及為了各類任務而產生的轉換數據，各類任務包括報表、可視化、高級分析和機器學習。

數據湖中包括來自于關系型數據庫中的結構化數據（行和列）、半結構化數據（如CSV、日志、XML、JSON）、非結構化數據（如email、文檔、PDF等）和二進制數據（如圖像、音頻、視頻）。

數據沼澤是一種退化的、缺乏管理的數據湖，數據沼澤對于用戶來說要么是不可訪問的要么就是無法提供足夠的價值。

AWS：

數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。您可以按原樣存儲數據（無需先對數據進行結構化處理），并運行不同類型的分析 – 從控制面板和可視化到大數據處理、實時分析和機器學習，以指導做出更好的決策。

微軟：

Azure的數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力，這些能力使得用戶可以存儲任意規模、任意類型、任意產生速度的數據，并且可以跨平臺、跨語言的做所有類型的分析和處理。數據湖在能幫助用戶加速應用數據的同時，消除了數據采集和存儲的復雜性，同時也能支持批處理、流式計算、交互式分析等。

數據湖能同現有的數據管理和治理的IT投資一起工作，保證數據的一致、可管理和安全。它也能同現有的業務數據庫和數據倉庫無縫集成，幫助擴展現有的數據應用。

Azure數據湖吸取了大量企業級用戶的經驗，并且在微軟一些業務中支持了大規模處理和分析場景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解決了許多效率和可擴展性的挑戰，作為一類服務使得用戶可以最大化數據資產的價值來滿足當前和未來需求。

三、數據湖的特征

筆者結合多方的觀點[2][3][4][5][6][7]，給出數據湖的六大核心特征，從這些特征看，數據湖更是一種企業數據架構方法：

（1）“保真性”。數據湖中對于業務系統中的數據都會存儲一份“一模一樣”的完整拷貝。與數據倉庫不同的地方在于，數據湖中必須要保存一份原始數據，無論是數據格式、數據模式、數據內容都不應該被修改。在這方面，數據湖強調的是對于業務數據“原汁原味”的保存。同時，數據湖應該能夠存儲任意類型/格式的數據，包括結構化、半結構化和非結構化數據。

（2）“靈活性”：如果數據倉庫屬于計劃經濟，那數據湖就屬于市場經濟[7]，數據倉庫強調“寫入型schema”， ?“寫入型schema”背后隱含的邏輯是數據在寫入之前，就需要根據業務的訪問方式確定數據的schema，然后按照既定schema，完成數據導入，帶來的好處是數據與業務的良好適配；但是這也意味著數倉的前期擁有成本會比較高，特別是當業務模式不清晰、業務還處于探索階段時，數倉的靈活性不夠。數據湖強調的是“讀取型schema”，背后的潛在邏輯則是認為業務的不確定性是常態：我們無法預期業務的變化，那么我們就保持一定的靈活性，將設計去延后，讓整個基礎設施具備使數據“按需”貼合業務的能力。

（3）“可管理”：數據湖應該提供完善的數據管理能力。既然數據要求“保真性”和“靈活性”，那么至少數據湖中會存在兩類數據：原始數據和處理后的數據。數據湖中的數據會不斷的積累、演化。因此，對于數據管理能力也會要求很高，至少應該包含以下數據管理能力：數據源、數據連接、數據格式、數據schema（庫/表/列/行）。同時，數據湖是單個企業/組織中統一的數據存放場所，因此，還需要具有一定的權限管理能力。

（4）“可分析”：從批處理、流式計算、交互式分析到機器學習，各類計算引擎都屬于數據湖應該囊括的范疇。一般情況下，數據的加載、轉換、處理會使用批處理計算引擎；需要實時計算的部分，會使用流式計算引擎；對于一些探索式的分析場景，可能又需要引入交互式分析引擎。隨著大數據技術與人工智能技術的結合越來越緊密，各類機器學習/深度學習算法也被不斷引入，例如TensorFlow/PyTorch框架已經支持從HDFS/S3/OSS上讀取樣本數據進行訓練。因此，對于一個合格的數據湖項目而言，計算引擎的可擴展/可插拔，應該是一類基礎能力。

（5）“可追溯”：數據湖是一個組織/企業中全量數據的存儲場所，需要對數據的全生命周期進行管理，包括數據的定義、接入、存儲、處理、分析、應用的全過程。一個強大的數據湖實現，需要能做到對其間的任意一條數據的接入、存儲、處理、消費過程是可追溯的，能夠清楚的重現數據完整的產生過程和流動過程。

（6）“可存儲”：數據湖需要提供足夠用的、可擴展的統一數據存儲能力，理論上，數據湖本身應該內置多模態的存儲引擎，以滿足不同的應用對于數據訪問需求（綜合考慮響應時間/并發/訪問頻次/成本等因素）。但是，在實際的使用過程中，數據湖中的數據通常并不會被高頻次的訪問，而且相關的應用也多在進行探索式的數據應用，為了達到可接受的性價比，數據湖建設通常會選擇相對便宜的存儲引擎（如S3/OSS/HDFS/OBS），并且在需要時與外置存儲引擎協同工作，滿足多樣化的應用需求。

四、數據湖的技術

數據湖要解決的核心問題是高效的存儲各類數據并支撐上層應用，傳統的數據湖一般采用HDFS為存儲引擎，但在實際應用中面臨著難以克服的問題，這直接催生了delta、iceberg和hudi[11]三大開源數據湖方案，雖然它們開始的時候是為了解決特定的應用問題的，但最終促成了數據湖特征的統一。

1、Delta

以Databricks推出的delta為例，它要解決的核心問題基本上集中在下圖：

在沒有delta數據湖之前，Databricks的客戶一般會采用經典的lambda架構來構建他們的流批處理場景。以用戶點擊行為分析為例，點擊事件經Kafka被下游的Spark Streaming作業消費，分析處理（業務層面聚合等）后得到一個實時的分析結果，這個實時結果只是當前時間所看到的一個狀態，無法反應時間軸上的所有點擊事件。所以為了保存全量點擊行為，Kafka還會被另外一個Spark Batch作業分析處理，導入到文件系統上（一般就是parquet格式寫HDFS或者S3，可以認為這個文件系統是一個簡配版的數據湖），供下游的Batch作業做全量的數據分析以及AI處理等。

這套方案其實存在很多問題 :

第一、批量導入到文件系統的數據一般都缺乏全局的嚴格schema規范，下游的Spark作業做分析時碰到格式混亂的數據會很麻煩，每一個分析作業都要過濾處理錯亂缺失的數據，成本較大；

第二、數據寫入文件系統這個過程沒有ACID保證，用戶可能讀到導入中間狀態的數據。所以上層的批處理作業為了躲開這個坑，只能調度避開數據導入時間段，可以想象這對業務方是多么不友好；同時也無法保證多次導入的快照版本，例如業務方想讀最近5次導入的數據版本，其實是做不到的。

第三、用戶無法高效upsert/delete更新歷史數據，parquet文件一旦寫入HDFS文件，要想改數據，就只能全量重新寫一份的數據，成本很高。事實上，這種需求是廣泛存在的，例如由于程序問題，導致錯誤地寫入一些數據到文件系統，現在業務方想要把這些數據糾正過來；線上的MySQL binlog不斷地導入update/delete增量更新到下游數據湖中；某些數據審查規范要求做強制數據刪除。

第四、頻繁地數據導入會在文件系統上產生大量的小文件，導致文件系統不堪重負，尤其是HDFS這種對文件數有限制的文件系統。

在Databricks看來，以下四個點是數據湖必備的：

事實上, Databricks在設計delta時，希望做到流批作業在數據層面做到進一步的統一(如下圖)。業務數據經過Kafka導入到統一的數據湖中（無論批處理，還是流處理），上層業務可以借助各種分析引擎做進一步的商業報表分析、流式計算以及AI分析等等。

2、Hudi

Uber的業務場景主要為：將線上產生的行程訂單數據，同步到一個統一的數據中心，然后供上層各個城市運營同事用來做分析和處理。在2014年的時候，Uber的數據湖架構相對比較簡單，業務日志經由Kafka同步到S3上，上層用EMR做數據分析；線上的關系型數據庫以及NoSQL則會通過ETL（ETL任務也會拉去一些Kakfa同步到S3的數據）任務同步到閉源的Vertica分析型數據庫，城市運營同學主要通過Vertica SQL實現數據聚合。當時也碰到數據格式混亂、系統擴展成本高（依賴收Vertica商業收費軟件）、數據回填麻煩等問題。后續遷移到開源的Hadoop生態，解決了擴展性問題等問題，但依然碰到Databricks上述的一些問題，其中最核心的問題是無法快速upsert存量數據。

如上圖所示，ETL任務每隔30分鐘定期地把增量更新數據同步到分析表中，全部改寫已存在的全量舊數據文件，導致數據延遲和資源消耗都很高。此外，在數據湖的下游，還存在流式作業會增量地消費新寫入的數據，數據湖的流式消費對他們來說也是必備的功能。所以，他們就希望設計一種合適的數據湖方案，在解決通用數據湖需求的前提下，還能實現快速的upsert以及流式增量消費。

Uber團隊在Hudi上同時實現了Copy On Write和Merge On Read 的兩種數據格式，其中Merge On Read就是為了解決他們的fast upsert而設計的。簡單來說，就是每次把增量更新的數據都寫入到一批獨立的delta文件集，定期地通過compaction合并delta文件和存量的data文件。同時給上層分析引擎提供三種不同的讀取視角：僅讀取delta增量文件、僅讀取data文件、合并讀取delta和data文件。滿足各種業務方對數據湖的流批數據分析需求。

最終，我們可以提煉出Uber的數據湖需求為如下圖，這也正好是Hudi所側重的核心特性。

3、Iceberg

Netflix的數據湖原先是借助Hive來構建，但發現Hive在設計上的諸多缺陷之后，開始轉為自研Iceberg，并最終演化成Apache下一個高度抽象通用的開源數據湖方案。Netflix用內部的一個時序數據業務的案例來說明Hive的這些問題，采用Hive時按照時間字段做partition，他們發現僅一個月會產生2688個partition和270萬個數據文件。他們執行一個簡單的select查詢，發現僅在分區裁剪階段就耗費數十分鐘。

他們發現Hive的元數據依賴一個外部的MySQL和HDFS文件系統，通過MySQL找到相關的parition之后，需要為每個partition去HDFS文件系統上按照分區做目錄的list操作。在文件量大的情況下，這是一個非常耗時的操作。同時，由于元數據分屬MySQL和HDFS管理，寫入操作本身的原子性難以保證。即使在開啟Hive ACID情況下，仍有很多細小場景無法保證原子性。另外，Hive Memstore沒有文件級別的統計信息，這使得filter只能下推到partition級別，而無法下推到文件級別，對上層分析性能損耗無可避免。最后，Hive對底層文件系統的復雜語義依賴，使得數據湖難以構建在成本更低的S3上。

于是，Netflix為了解決這些痛點，設計了自己的輕量級數據湖Iceberg。在設計之初，作者們將其定位為一個通用的數據湖項目，所以在實現上做了高度的抽象。雖然目前從功能上看不如前面兩者豐富，但由于它牢固堅實的底層設計，一旦功能補齊，將成為一個非常有潛力的開源數據湖方案。

總體來說，Netflix設計Iceberg的核心訴求可以歸納為如下：

因此，數據湖并不是炒作的新概念，而是來源于應用的驅動，delta、iceberg和hudi這類新技術實際是介于上層計算引擎和底層存儲格式之間的一個中間層，我們可以把它定義成一種“數據組織格式”，Iceberg 將其稱之為“表格式”也是表達類似的含義。它與底層的存儲格式（比如 ORC、Parquet 之類的列式存儲格式）最大的區別是，它并不定義數據存儲方式，而是定義了數據、元數據的組織方式，向上提供統一的“表”的語義。它構建在數據存儲格式之上，其底層的數據存儲仍然使用 Parquet、ORC 等進行存儲。

delta、iceberg和hudi誕生于不同公司，需要解決的問題存在差異，Iceberg 在其格式定義和核心能力上最為完善，但是上游引擎的適配上稍顯不足；Hudi 基于 Spark 打造了完整的流式數據落地方案，但是其核心抽象較弱，與 Spark 耦合較緊；Delta Lake 同樣高度依賴于 Spark 生態圈，與其他引擎的適配尚需時日，雖然這三個方案在設計初衷上稍有不同，但實現的思路和提供的能力卻非常相似，我們可以總結出數據湖技術需要具備的能力：

（1）同時支持流批處理

（2）支持數據更新

（3）支持事務（ACID）

（4）可擴展的元數據

（5）支持多種存儲引擎

（6）支持多種計算引擎

不同公司根據不同需求選擇了不同的數據湖產品，比如阿里云的 DLA 團隊選擇 hudi 作為其底層數據湖存儲引擎；騰訊選擇了 iceberg 作為他們的數據湖存儲引擎,比如文章《基于 Flink+Iceberg 構建企業級實時數據湖》[12]就介紹了騰訊的企業實時數據湖方案。

五、數據湖的趨勢

1、服務模式演進趨勢

下面是阿里云[3]給出的數據湖服務架構的演進過程，整體上可分為三個階段：

第一階段：自建開源Hadoop數據湖架構，原始數據統一存放在HDFS系統上，引擎以Hadoop和Spark開源生態為主，存儲和計算一體。缺點是需要企業自己運維和管理整套集群，成本高且集群穩定性差。

第二階段：云上托管Hadoop數據湖架構（即EMR開源數據湖），底層物理服務器和開源軟件版本由云廠商提供和管理，數據仍統一存放在HDFS系統上，引擎以Hadoop和Spark開源生態為主。這個架構通過云上 IaaS 層提升了機器層面的彈性和穩定性，使企業的整體運維成本有所下降，但企業仍然需要對HDFS系統以及服務運行狀態進行管理和治理，即應用層的運維工作。同時因為存儲和計算耦合在一起，穩定性不是最優，兩種資源無法獨立擴展，使用成本也不是最優。

第三階段：云上數據湖架構（無服務器），即云上純托管的存儲系統逐步取代HDFS，成為數據湖的存儲基礎設施，并且引擎豐富度也不斷擴展。除了Hadoop和Spark的生態引擎之外，各云廠商還發展出面向數據湖的引擎產品。如分析類的數據湖引擎有AWS Athena和華為DLI，AI類的有AWS Sagemaker。

這個架構仍然保持了一個存儲和多個引擎的特性，所以統一元數據服務至關重要，如AWS推出了Glue，阿里云EMR近期也即將發布數據湖統一元數據服務。該架構相對于原生HDFS的數據湖架構的優勢在于：

（1）幫助用戶擺脫原生HDFS系統運維困難的問題。HDFS系統運維有兩個困難：1）存儲系統相比計算引擎更高的穩定性要求和更高的運維風險 2）與計算混布在一起，帶來的擴展彈性問題。存儲計算分離架構幫助用戶解耦存儲，并交由云廠商統一運維管理，解決了穩定性和運維問題。

（2）分離后的存儲系統可以獨立擴展，不再需要與計算耦合，可降低整體成本

（3）當用戶采用數據湖架構之后，客觀上也幫助客戶完成了存儲統一化（解決多個HDFS數據孤島的問題）

2、技術架構演進趨勢

第一階段：以Hadoop為代表的離線數據處理基礎設施。如下圖所示，Hadoop是以HDFS為核心存儲，以MapReduce（簡稱MR）為基本計算模型的批量數據處理基礎設施。

第二階段：lambda架構。隨著數據處理能力和處理需求的不斷變化，越來越多的用戶發現，批處理模式無論如何提升性能，也無法滿足一些實時性要求高的處理場景，流式計算引擎應運而生，例如Storm、Spark Streaming、Flink等，如下圖所示，整個數據流向自左向右流入平臺。進入平臺后一分為二，一部分走批處理模式，一部分走流式計算模式。無論哪種計算模式，最終的處理結果都通過服務層對應用提供，確保訪問的一致性。

第三階段：Kappa架構。Lambda架構解決了應用讀取數據的一致性問題，但是“流批分離”的處理鏈路增大了研發的復雜性。因此，有人就提出能不能用一套系統來解決所有問題。目前比較流行的做法就是基于流計算來做。流計算天然的分布式特征，注定了他的擴展性更好。通過加大流計算的并發性，加大流式數據的“時間窗口”，來統一批處理與流式處理兩種計算模式。

3、湖倉一體的演進趨勢

數據倉庫的設計強調計劃，而數據湖強調市場，更具靈活性，因此對于處于不同階段的企業的效用是不一樣的：

1、當企業處于初創階段，數據從產生到消費還需要一個創新探索的階段才能逐漸沉淀下來，那么用于支撐這類業務的大數據系統，靈活性就更加重要，數據湖的架構更適用。

2、當企業逐漸成熟起來，已經沉淀為一系列數據處理流程，問題開始轉化為數據規模不斷增長，處理數據的成本不斷增加，參與數據流程的人員、部門不斷增多，那么用于支撐這類業務的大數據系統，成長性的好壞就決定了業務能夠發展多遠。數據倉庫的架構更適用。

對企業來說，數據湖和數據倉庫是否必須是一個二選一的選擇題？是否能有一種方案同時兼顧數據湖的靈活性和云數據倉庫的成長性，將二者有效結合起來為用戶實現更低的總體擁有成本？阿里云提出了大數據架構新概念：湖倉一體。

何謂湖倉一體？

（1）湖和倉的數據/元數據無縫打通，互相補充，數據倉庫的模型反哺到數據湖（成為原始數據一部分），湖的結構化應用知識沉淀到數據倉庫

（2）湖和倉有統一的開發體驗，存儲在不同系統的數據，可以通過一個統一的開發/管理平臺操作

（3）數據湖與數據倉庫的數據，系統可以根據自動的規則決定哪些數據放在數倉，哪些保留在數據湖，進而形成一體化

六、數據湖的案例

1、AWS數據湖

AWS數據湖[8]基于AWS Lake Formation構建，AWS Lake Formation本質上是一個管理性質的組件，它與其他AWS服務互相配合，來完成整個企業級數據湖構建功能。上圖自左向右，體現了數據沉淀、數據流入、數據計算、數據服務等步驟。

（1）數據沉淀：采用Amazon S3作為整個數據湖的集中存儲，包含結構化和非結構化的數據，按需擴展/按使用量付費

（2） 數據流入：元數據抓取、ETL和數據準備AWS將其單獨抽象出來，形成了一個產品叫AWS GLUE，GLUE基本的計算形式是各類批處理模式的ETL任務，任務的出發方式分為手動觸發、定時觸發、事件觸發三種

（3）數據處理：利用AWS GLUE進行批處理計算模式之外，也可以使用Amazon EMR進行數據的高級處理分析，或者基于Amazon EMR、Amazon Kinesis來完成流處理任務

（4）數據分析：數據通過Athena/Redshift來提供基于SQL的交互式批處理能力，通過 Amazon Machine Learning、Amazon Lex、Amazon Rekognition進行深度加工

2、華為數據湖

華為數據湖基于DLI Serverless[9]構建，DLI完全兼容Apache Spark、Apache Flink生態和接口，是集實時分析、離線分析、交 互式分析為一體的Serverless大數據計算分析服務。可以看到，DLI相當于是AWS的Lake Formation、GLUE、EMR（Flink&Spark）、Athena等的集合，承擔了所有的數據湖構建、數據處理、數據管理、數據應用的核心功能。

為了更好的支持數據集成、規范設計、數據開發、數據質量監控、數據資產管理、數據服務等數據湖高級功能，華為云提供了DAYU智能數據湖運營平臺[10]，DAYU涵蓋了整個數據湖治理的核心流程，并對其提供了相應的工具支持，如下圖所示。

3、阿里云數據湖

阿里云DLA數據湖解決方案[4]如上圖所示，DLA 核心在于打造云原生的服務與引擎，端到端解決基于 OSS 的管理、分析、計算問題，核心關鍵點如下。

（1）數據存儲：采用OSS作為數據湖的集中存儲，可以支撐EB規模的數據湖，客戶無需考慮存儲量擴容，各類型數據可以統一存儲

（2）數據湖管理：面對 OSS 數據開放性帶來的管理及入湖困難，DLA的Formation組件具備元數據發現和一鍵建湖的能力，DLA提供Meta data catalog組件對于數據湖中的數據資產進行統一的管理，無論數據是在“湖中”還是在“湖外”，比如利用元數據爬取功能，可以一鍵創建 OSS 上的元數據信息，輕松自動識別 CSV/JSON/Parquet 等格式，建立好庫表信息，方便后續計算引擎使用

（3）數據分析和計算：DLA提供了SQL計算引擎和Spark計算引擎兩種。無論是SQL還是Spark引擎，都和Meta data catalog深度集成，能方便的獲取元數據信息。基于Spark的能力，DLA解決方案支持批處理、流計算和機器學習等計算模式

（4）在數據集成和開發上：阿里云的數據湖解決方案提供兩種選擇：一種是采用dataworks完成；另一種是采用DMS來完成。無論是選擇哪種，都能對外提供可視化的流程編排、任務調度、任務管理能力。在數據生命周期管理上，dataworks的數據地圖能力相對更加成熟。

阿里云DLA解決方案的另一個特色在于“基于云原生的湖倉一體化”。傳統的企業級數據倉庫在大數據時代的今天，在各類報表應用上依然是無法替代的；但是數倉無法滿足大數據時代的數據分析處理的靈活性需求。

因此，阿里云推薦數據倉庫應該作為數據湖的上層應用存在：即數據湖是原始業務數據在一個企業/組織中唯一官方數據存儲地；數據湖根據各類業務應用需求，將原始數據進行加工處理，形成可再次利用的中間結果；當中間結果的數據模式（Schema）相對固定后，DLA可以將中間結果推送至數據倉庫，供企業/組織開展基于數倉的業務應用。阿里云在提供DLA的同時，還提供了云原生數倉（原ADB），DLA和云原生數倉在以下兩點上深度融合。

（1） 使用同源的SQL解析引擎。DLA的SQL與ADB的SQL語法上完全兼容，這意味著開發者使用一套技術棧即能同時開發數據湖應用和數倉應用。

（2） 都內置了對于OSS的訪問支持。OSS直接作為DLA的原生存儲存在；對于ADB而言，可以通過外部表的能力，很方便的訪問OSS上的結構化數據。借助外部表，數據可以自由的在DLA和ADB之間流轉，做到真正的湖倉一體。

結語

在寫這篇文章之前，筆者對于數據湖的理解是零碎的，不成體系的，通過這次歸納總結，我大致能理解數據湖的來龍去脈，希望對你也有所幫助。