目前市面上流行的三大開源數據湖方案分別為：delta、Apache Iceberg和Apache Hudi。

其中，由于Apache Spark在商業化上取得巨大成功，所以由其背后商業公司Databricks推出的delta也顯得格外亮眼。

Apache Hudi是由Uber的工程師為滿足其內部數據分析的需求而設計的數據湖項目，它提供的fast upsert/delete以及compaction等功能可以說是精準命中廣大人民群眾的痛點，加上項目各成員積極地社區建設，包括技術細節分享、國內社區推廣等等，也在逐步地吸引潛在用戶的目光。

Apache Iceberg目前看則會顯得相對平庸一些，簡單說社區關注度暫時比不上delta，功能也不如Hudi豐富，但卻是一個野心勃勃的項目，因為它具有高度抽象和非常優雅的設計，為成為一個通用的數據湖方案奠定了良好基礎。

很多用戶會想，看著三大項目異彩紛呈，到底應該在什么樣的場景下，選擇合適數據湖方案呢？今天我們就來解構數據湖的核心需求，深度對比三大產品，幫助用戶更好地針對自身場景來做數據湖方案選型。

首先，我們來逐一分析為何各技術公司要推出他們的開源數據湖解決方案，他們碰到的問題是什么，提出的方案又是如何解決問題的。我們希望客觀地分析業務場景，來理性判斷到底哪些功能才是客戶的痛點和剛需。

Databricks和Delta

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

圖片來源：https://www.slideshare.net/databricks/making-apache-spark-better-with-delta-lake

在沒有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增量更新到下游數據湖中；某些數據審查規范要求做強制數據刪除，例如歐洲出臺的GDPR隱私保護等等。

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

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

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

所以，總結起來，我認為databricks設計delta時主要考慮實現以下核心功能特性：

Uber和Apache 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所側重的核心特性：

Netflix和Apache 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 Metastore沒有文件級別的統計信息，這使得filter只能下推到partition級別，而無法下推到文件級別，對上層分析性能損耗無可避免。

最后，Hive對底層文件系統的復雜語義依賴，使得數據湖難以構建在成本更低的S3上。

于是，Netflix為了解決這些痛點，設計了自己的輕量級數據湖Iceberg。在設計之初，作者們將其定位為一個通用的數據湖項目，所以在實現上做了高度的抽象。

雖然目前從功能上看不如前面兩者豐富，但由于它牢固堅實的底層設計，一旦功能補齊，將成為一個非常有潛力的開源數據湖方案。

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

痛點小結

我們可以把上述三個項目針對的痛點，放到一張圖上來看?？梢园l現標紅的功能點，基本上是一個好的數據湖方案應該去做到的功能點：

七大維度對比

在理解了上述三大方案各自設計的初衷和面向的痛點之后，接下來我們從7個維度來對比評估三大項目的差異。通常人們在考慮數據湖方案選型時，Hive ACID也是一個強有力的候選人，因為它提供了人們需要的較為完善功能集合，所以這里我們把Hive ACID納入到對比行列中。

第一、ACID和隔離級別支持

這里主要解釋下，對數據湖來說三種隔離分別代表的含義：

• Serialization是說所有的reader和writer都必須串行執行；
• Write Serialization: 是說多個writer必須嚴格串行，reader和writer之間則可以同時跑；
• Snapshot Isolation: 是說如果多個writer寫的數據無交集，則可以并發執行；否則只能串行。Reader和writer可以同時跑。

綜合起來看，Snapshot Isolation隔離級別的并發性是相對比較好的。

第二、Schema變更支持和設計

這里有兩個對比項，一個是schema變更的支持情況，我的理解是hudi僅支持添加可選列和刪除列這種向后兼容的DDL操作，而其他方案則沒有這個限制。另外一個是數據湖是否自定義schema接口，以期跟計算引擎的schema解耦。這里iceberg是做的比較好的，抽象了自己的schema，不綁定任何計算引擎層面的schema。

第三、流批接口支持

目前Iceberg和Hive暫時不支持流式消費，不過Iceberg社區正在issue 179上開發支持。

第四、接口抽象程度和插件化

這里主要從計算引擎的寫入和讀取路徑、底層存儲可插拔、文件格式四個方面來做對比。這里Iceberg是抽象程度做得最好的數據湖方案，四個方面都做了非常干凈的解耦。delta是databricks背后主推的，必須天然綁定spark；hudi的代碼跟delta類似，也是強綁定spark。

存儲可插拔的意思是說，是否方便遷移到其他分布式文件系統上（例如S3），這需要數據湖對文件系統API接口有最少的語義依賴，例如若數據湖的ACID強依賴文件系統rename接口原子性的話，就難以遷移到S3這樣廉價存儲上，目前來看只有Hive沒有太考慮這方面的設計；文件格式指的是在不依賴數據湖工具的情況下，是否能讀取和分析文件數據，這就要求數據湖不額外設計自己的文件格式，統一用開源的parquet和avro等格式。這里，有一個好處就是，遷移的成本很低，不會被某一個數據湖方案給綁死。

第五、查詢性能優化

第六、其他功能

這里One line demo指的是，示例demo是否足夠簡單，體現了方案的易用性，Iceberg稍微復雜一點（我認為主要是Iceberg自己抽象出了schema，所以操作前需要定義好表的schema）。做得最好的其實是delta，因為它深度跟隨spark易用性的腳步。

Python支持其實是很多基于數據湖之上做機器學習的開發者會考慮的問題，可以看到Iceberg和Delta是做的很好的兩個方案。

出于數據安全的考慮，Iceberg還提供了文件級別的加密解密功能，這是其他方案未曾考慮到的一個比較重要的點。

第七、社區現狀（截止到2020-01-08）

這里需要說明的是，Delta和Hudi兩個項目在開源社區的建設和推動方面，做的比較好。Delta的開源版和商業版本，提供了詳細的內部設計文檔，用戶非常容易理解這個方案的內部設計和核心功能，同時Databricks還提供了大量對外分享的技術視頻和演講，甚至邀請了他們的企業用戶來分享Delta的線上經驗。

Uber的工程師也分享了大量Hudi的技術細節和內部方案落地，研究官網的近10個PPT已經能較為輕松理解內部細節，此外國內的小伙伴們也在積極地推動社區建設，提供了官方的技術公眾號和郵件列表周報。

Iceberg相對會平靜一些，社區的大部分討論都在Github的issues和pull request上，郵件列表的討論會少一點，很多有價值的技術文檔要仔細跟蹤issues和PR才能看到，這也許跟社區核心開發者的風格有關。

總結

我們把三個產品（其中delta分為databricks的開源版和商業版）總結成如下圖：

如果用一個比喻來說明delta、iceberg、hudi、hive-acid四者差異的話，可以把四個項目比做建房子。由于開源的delta是databricks閉源delta的一個簡化版本，它主要為用戶提供一個table format的技術標準，閉源版本的delta基于這個標準實現了諸多優化，這里我們主要用閉源的delta來做對比。

Delta的房子底座相對結實，功能樓層也建得相對比較高，但這個房子其實可以說是databricks的，本質上是為了更好地壯大Spark生態，在delta上其他的計算引擎難以替換Spark的位置，尤其是寫入路徑層面。

Iceberg的建筑基礎非常扎實，擴展到新的計算引擎或者文件系統都非常的方便，但是現在功能樓層相對低一點，目前最缺的功能就是upsert和compaction兩個，Iceberg社區正在以最高優先級推動這兩個功能的實現。

Hudi的情況要相對不一樣，它的建筑基礎設計不如iceberg結實，舉個例子，如果要接入Flink作為Sink的話，需要把整個房子從底向上翻一遍，把接口抽象出來，同時還要考慮不影響其他功能，當然Hudi的功能樓層還是比較完善的，提供的upsert和compaction功能直接命中廣大群眾的痛點。

Hive的房子，看起來是一棟豪宅，絕大部分功能都有，把它做為數據湖有點像靠著豪宅的一堵墻建房子，顯得相對重量級一點，另外正如Netflix上述的分析，細看這個豪宅的墻面是其實是有一些問題的。