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

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

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

Apache Iceberg目前看則會顯得相對平庸一些，簡單說社區(qū)關(guān)注度暫時(shí)比不上delta，功能也不如Hudi豐富，但卻是一個(gè)野心勃勃的項(xiàng)目，因?yàn)樗哂懈叨瘸橄蠛头浅?yōu)雅的設(shè)計(jì)，為成為一個(gè)通用的數(shù)據(jù)湖方案奠定了良好基礎(chǔ)。

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

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

Databricks和Delta

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

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

在沒有delta數(shù)據(jù)湖之前，Databricks的客戶一般會采用經(jīng)典的lambda架構(gòu)來構(gòu)建他們的流批處理場景。

以用戶點(diǎn)擊行為分析為例，點(diǎn)擊事件經(jīng)Kafka被下游的Spark Streaming作業(yè)消費(fèi)，分析處理（業(yè)務(wù)層面聚合等）后得到一個(gè)實(shí)時(shí)的分析結(jié)果，這個(gè)實(shí)時(shí)結(jié)果只是當(dāng)前時(shí)間所看到的一個(gè)狀態(tài)，無法反應(yīng)時(shí)間軸上的所有點(diǎn)擊事件。

所以為了保存全量點(diǎn)擊行為，Kafka還會被另外一個(gè)Spark Batch作業(yè)分析處理，導(dǎo)入到文件系統(tǒng)上（一般就是parquet格式寫HDFS或者S3，可以認(rèn)為這個(gè)文件系統(tǒng)是一個(gè)簡配版的數(shù)據(jù)湖），供下游的Batch作業(yè)做全量的數(shù)據(jù)分析以及AI處理等。

這套方案其實(shí)存在很多問題 :

第一、批量導(dǎo)入到文件系統(tǒng)的數(shù)據(jù)一般都缺乏全局的嚴(yán)格schema規(guī)范，下游的Spark作業(yè)做分析時(shí)碰到格式混亂的數(shù)據(jù)會很麻煩，每一個(gè)分析作業(yè)都要過濾處理錯(cuò)亂缺失的數(shù)據(jù)，成本較大。

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

第三、用戶無法高效upsert/delete歷史數(shù)據(jù)，parquet文件一旦寫入HDFS文件，要想改數(shù)據(jù)，就只能全量重新寫一份的數(shù)據(jù)，成本很高。事實(shí)上，這種需求是廣泛存在的，例如由于程序問題，導(dǎo)致錯(cuò)誤地寫入一些數(shù)據(jù)到文件系統(tǒng)，現(xiàn)在業(yè)務(wù)方想要把這些數(shù)據(jù)糾正過來；線上的MySQL binlog不斷地導(dǎo)入update/delete增量更新到下游數(shù)據(jù)湖中；某些數(shù)據(jù)審查規(guī)范要求做強(qiáng)制數(shù)據(jù)刪除，例如歐洲出臺的GDPR隱私保護(hù)等等。

第四、頻繁地?cái)?shù)據(jù)導(dǎo)入會在文件系統(tǒng)上產(chǎn)生大量的小文件，導(dǎo)致文件系統(tǒng)不堪重負(fù)，尤其是HDFS這種對文件數(shù)有限制的文件系統(tǒng)。

所以，在Databricks看來，以下四個(gè)點(diǎn)是數(shù)據(jù)湖必備的：

事實(shí)上，Databricks在設(shè)計(jì)delta時(shí)，希望做到流批作業(yè)在數(shù)據(jù)層面做到進(jìn)一步的統(tǒng)一(如下圖)。業(yè)務(wù)數(shù)據(jù)經(jīng)過Kafka導(dǎo)入到統(tǒng)一的數(shù)據(jù)湖中（無論批處理，還是流處理），上層業(yè)務(wù)可以借助各種分析引擎做進(jìn)一步的商業(yè)報(bào)表分析、流式計(jì)算以及AI分析等等。

所以，總結(jié)起來，我認(rèn)為databricks設(shè)計(jì)delta時(shí)主要考慮實(shí)現(xiàn)以下核心功能特性：

Uber和Apache Hudi

Uber的業(yè)務(wù)場景主要為：將線上產(chǎn)生的行程訂單數(shù)據(jù)，同步到一個(gè)統(tǒng)一的數(shù)據(jù)中心，然后供上層各個(gè)城市運(yùn)營同事用來做分析和處理。

在2014年的時(shí)候，Uber的數(shù)據(jù)湖架構(gòu)相對比較簡單，業(yè)務(wù)日志經(jīng)由Kafka同步到S3上，上層用EMR做數(shù)據(jù)分析；線上的關(guān)系型數(shù)據(jù)庫以及NoSQL則會通過ETL（ETL任務(wù)也會拉去一些Kakfa同步到S3的數(shù)據(jù)）任務(wù)同步到閉源的Vertica分析型數(shù)據(jù)庫，城市運(yùn)營同學(xué)主要通過Vertica SQL實(shí)現(xiàn)數(shù)據(jù)聚合。當(dāng)時(shí)也碰到數(shù)據(jù)格式混亂、系統(tǒng)擴(kuò)展成本高（依賴收Vertica商業(yè)收費(fèi)軟件）、數(shù)據(jù)回填麻煩等問題。

后續(xù)遷移到開源的Hadoop生態(tài)，解決了擴(kuò)展性問題等問題，但依然碰到Databricks上述的一些問題，其中最核心的問題是無法快速upsert存量數(shù)據(jù)。

如上圖所示，ETL任務(wù)每隔30分鐘定期地把增量更新數(shù)據(jù)同步到分析表中，全部改寫已存在的全量舊數(shù)據(jù)文件，導(dǎo)致數(shù)據(jù)延遲和資源消耗都很高。

此外，在數(shù)據(jù)湖的下游，還存在流式作業(yè)會增量地消費(fèi)新寫入的數(shù)據(jù)，數(shù)據(jù)湖的流式消費(fèi)對他們來說也是必備的功能。所以，他們就希望設(shè)計(jì)一種合適的數(shù)據(jù)湖方案，在解決通用數(shù)據(jù)湖需求的前提下，還能實(shí)現(xiàn)快速的upsert以及流式增量消費(fèi)。

Uber團(tuán)隊(duì)在Hudi上同時(shí)實(shí)現(xiàn)了Copy On Write和Merge On Read的兩種數(shù)據(jù)格式，其中Merge On Read就是為了解決他們的fast upsert而設(shè)計(jì)的。

簡單來說，就是每次把增量更新的數(shù)據(jù)都寫入到一批獨(dú)立的delta文件集，定期地通過compaction合并delta文件和存量的data文件。同時(shí)給上層分析引擎提供三種不同的讀取視角：僅讀取delta增量文件、僅讀取data文件、合并讀取delta和data文件。滿足各種業(yè)務(wù)方對數(shù)據(jù)湖的流批數(shù)據(jù)分析需求。

最終，我們可以提煉出Uber的數(shù)據(jù)湖需求為如下圖，這也正好是Hudi所側(cè)重的核心特性：

Netflix和Apache Iceberg

Netflix的數(shù)據(jù)湖原先是借助Hive來構(gòu)建，但發(fā)現(xiàn)Hive在設(shè)計(jì)上的諸多缺陷之后，開始轉(zhuǎn)為自研Iceberg，并最終演化成Apache下一個(gè)高度抽象通用的開源數(shù)據(jù)湖方案。

Netflix用內(nèi)部的一個(gè)時(shí)序數(shù)據(jù)業(yè)務(wù)的案例來說明Hive的這些問題，采用Hive時(shí)按照時(shí)間字段做partition，他們發(fā)現(xiàn)僅一個(gè)月會產(chǎn)生2688個(gè)partition和270萬個(gè)數(shù)據(jù)文件。他們執(zhí)行一個(gè)簡單的select查詢，發(fā)現(xiàn)僅在分區(qū)裁剪階段就耗費(fèi)數(shù)十分鐘。

他們發(fā)現(xiàn)Hive的元數(shù)據(jù)依賴一個(gè)外部的MySQL和HDFS文件系統(tǒng)，通過MySQL找到相關(guān)的parition之后，需要為每個(gè)partition去HDFS文件系統(tǒng)上按照分區(qū)做目錄的list操作。在文件量大的情況下，這是一個(gè)非常耗時(shí)的操作。

同時(shí)，由于元數(shù)據(jù)分屬M(fèi)ySQL和HDFS管理，寫入操作本身的原子性難以保證。即使在開啟Hive ACID情況下，仍有很多細(xì)小場景無法保證原子性。另外，Hive Metastore沒有文件級別的統(tǒng)計(jì)信息，這使得filter只能下推到partition級別，而無法下推到文件級別，對上層分析性能損耗無可避免。

最后，Hive對底層文件系統(tǒng)的復(fù)雜語義依賴，使得數(shù)據(jù)湖難以構(gòu)建在成本更低的S3上。

于是，Netflix為了解決這些痛點(diǎn)，設(shè)計(jì)了自己的輕量級數(shù)據(jù)湖Iceberg。在設(shè)計(jì)之初，作者們將其定位為一個(gè)通用的數(shù)據(jù)湖項(xiàng)目，所以在實(shí)現(xiàn)上做了高度的抽象。

雖然目前從功能上看不如前面兩者豐富，但由于它牢固堅(jiān)實(shí)的底層設(shè)計(jì)，一旦功能補(bǔ)齊，將成為一個(gè)非常有潛力的開源數(shù)據(jù)湖方案。

總體來說，Netflix設(shè)計(jì)Iceberg的核心訴求可以歸納為如下：

痛點(diǎn)小結(jié)

我們可以把上述三個(gè)項(xiàng)目針對的痛點(diǎn)，放到一張圖上來看?？梢园l(fā)現(xiàn)標(biāo)紅的功能點(diǎn)，基本上是一個(gè)好的數(shù)據(jù)湖方案應(yīng)該去做到的功能點(diǎn)：

七大維度對比

在理解了上述三大方案各自設(shè)計(jì)的初衷和面向的痛點(diǎn)之后，接下來我們從7個(gè)維度來對比評估三大項(xiàng)目的差異。通常人們在考慮數(shù)據(jù)湖方案選型時(shí)，Hive ACID也是一個(gè)強(qiáng)有力的候選人，因?yàn)樗峁┝巳藗冃枰妮^為完善功能集合，所以這里我們把Hive ACID納入到對比行列中。

第一、ACID和隔離級別支持

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

• Serialization是說所有的reader和writer都必須串行執(zhí)行；
• Write Serialization: 是說多個(gè)writer必須嚴(yán)格串行，reader和writer之間則可以同時(shí)跑；
• Snapshot Isolation: 是說如果多個(gè)writer寫的數(shù)據(jù)無交集，則可以并發(fā)執(zhí)行；否則只能串行。Reader和writer可以同時(shí)跑。

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

第二、Schema變更支持和設(shè)計(jì)

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

第三、流批接口支持

目前Iceberg和Hive暫時(shí)不支持流式消費(fèi)，不過Iceberg社區(qū)正在issue 179上開發(fā)支持。

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

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

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

第五、查詢性能優(yōu)化

第六、其他功能

這里One line demo指的是，示例demo是否足夠簡單，體現(xiàn)了方案的易用性，Iceberg稍微復(fù)雜一點(diǎn)（我認(rèn)為主要是Iceberg自己抽象出了schema，所以操作前需要定義好表的schema）。做得最好的其實(shí)是delta，因?yàn)樗疃雀Sspark易用性的腳步。

Python支持其實(shí)是很多基于數(shù)據(jù)湖之上做機(jī)器學(xué)習(xí)的開發(fā)者會考慮的問題，可以看到Iceberg和Delta是做的很好的兩個(gè)方案。

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

第七、社區(qū)現(xiàn)狀（截止到2020-01-08）

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

Uber的工程師也分享了大量Hudi的技術(shù)細(xì)節(jié)和內(nèi)部方案落地，研究官網(wǎng)的近10個(gè)PPT已經(jīng)能較為輕松理解內(nèi)部細(xì)節(jié)，此外國內(nèi)的小伙伴們也在積極地推動社區(qū)建設(shè)，提供了官方的技術(shù)公眾號和郵件列表周報(bào)。

Iceberg相對會平靜一些，社區(qū)的大部分討論都在Github的issues和pull request上，郵件列表的討論會少一點(diǎn)，很多有價(jià)值的技術(shù)文檔要仔細(xì)跟蹤issues和PR才能看到，這也許跟社區(qū)核心開發(fā)者的風(fēng)格有關(guān)。

總結(jié)

我們把三個(gè)產(chǎn)品（其中delta分為databricks的開源版和商業(yè)版）總結(jié)成如下圖：

如果用一個(gè)比喻來說明delta、iceberg、hudi、hive-acid四者差異的話，可以把四個(gè)項(xiàng)目比做建房子。由于開源的delta是databricks閉源delta的一個(gè)簡化版本，它主要為用戶提供一個(gè)table format的技術(shù)標(biāo)準(zhǔn)，閉源版本的delta基于這個(gè)標(biāo)準(zhǔn)實(shí)現(xiàn)了諸多優(yōu)化，這里我們主要用閉源的delta來做對比。

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

Iceberg的建筑基礎(chǔ)非常扎實(shí)，擴(kuò)展到新的計(jì)算引擎或者文件系統(tǒng)都非常的方便，但是現(xiàn)在功能樓層相對低一點(diǎn)，目前最缺的功能就是upsert和compaction兩個(gè)，Iceberg社區(qū)正在以最高優(yōu)先級推動這兩個(gè)功能的實(shí)現(xiàn)。

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

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