一、Delta、Hudi、Iceberg對比概覽
由於Apache Spark在商業化上取得巨大成功，所以由其背后商業公司Databricks推出的Delta lake也顯得格外亮眼。在沒有delta數據湖之前，Databricks的客戶一般會采用經典的lambda架構來構建他們的流批處理場景。
Apache Hudi是由Uber的工程師為滿足其內部數據分析的需求而設計的數據湖項目，它提供的fast upsert/delete以及compaction等功能可以說是精准命中廣大人民群眾的痛點，加上項目各成員積極地社區建設，包括技術細節分享、國內社區推廣等等，也在逐步地吸引潛在用戶的目光。
Netflix的數據湖原先是借助Hive來構建，但發現Hive在設計上的諸多缺陷之后，開始轉為自研Iceberg，並最終演化成Apache下一個高度抽象通用的開源數據湖方案。
Apache Iceberg目前看則會顯得相對平庸一些，簡單說社區關注度暫時比不上delta，功能也不如Hudi豐富，但卻是一個野心勃勃的項目，因為它具有高度抽象和非常優雅的設計，為成為一個通用的數據湖方案奠定了良好基礎。
二、共同點
三者均為Data Lake的數據存儲中間層，其數據管理的功能均是基於一系列的meta文件。Meta文件的角色類似於數據庫的catalog\wal，起到schema管理、事務管理和數據管理的功能。與數據庫不同的是，這些meta文件是與數據文件一起存放在存儲引擎中的，用戶可以直接看到。這個做法直接繼承了大數據分析中數據對用戶可見的傳統，但是無形中也增加了數據被不小心破壞的風險。一旦刪了meta目錄，表就被破壞了，恢復難度很大。
Meta包含有表的schema信息。因此系統可以自己掌握schema的變動，提供schema演化的支持。Meta文件也有transaction log的功能（需要文件系統有原子性和一致性的支持）。所有對表的變更都會生成一份新的meta文件，於是系統就有了ACID和多版本的支持，同時可以提供訪問歷史的功能。在這些方面，三者是相同的。
三、關於Hudi
Hudi 的設計目標正如其名，Hadoop Upserts Deletes and Incrementals（原為 Hadoop Upserts anD Incrementals），強調了其主要支持 Upserts、Deletes 和 Incremental 數據處理，其主要提供的寫入工具是 Spark HudiDataSource API 和自身提供的 HoodieDeltaStreamer，均支持三種數據寫入方式：UPSERT，INSERT 和 BULK_INSERT。其對 Delete 的支持也是通過寫入時指定一定的選項支持的，並不支持純粹的 delete 接口。
在查詢方面，Hudi 支持 Hive、Spark、Presto。
在性能方面，Hudi 設計了 HoodieKey ，一個類似於主鍵的東西。對於查詢性能，一般需求是根據查詢謂詞生成過濾條件下推至 datasource。Hudi 這方面沒怎么做工作，其性能完全基於引擎自帶的謂詞下推和 partition prune 功能。
Hudi 的另一大特色是支持 Copy On Write 和 Merge On Read。前者在寫入時做數據的 merge，寫入性能略差，但是讀性能更高一些。后者讀的時候做 merge，讀性能差，但是寫入數據會比較及時，因而后者可以提供近實時的數據分析能力。 最后，Hudi 提供了一個名為 run_sync_tool 的腳本同步數據的 schema 到 Hive 表。Hudi 還提供了一個命令行工具用於管理 Hudi 表。
四、關於Iceberg
Iceberg 沒有類似的 HoodieKey 設計，其不強調主鍵。上文已經說到，沒有主鍵，做 update/delete/merge 等操作就要通過 Join 來實現，而 Join 需要有一個 類似 SQL 的執行引擎。
在查詢方面，Iceberg 支持hive、 Spark、Presto。
Iceberg 在查詢性能方面做了大量的工作。值得一提的是它的 hidden partition 功能。Hidden partition 意思是說，對於用戶輸入的數據，用戶可以選取其中某些列做適當的變換（Transform）形成一個新的列作為 partition 列。這個 partition 列僅僅為了將數據進行分區，並不直接體現在表的 schema 中。
除了 hidden partition，Iceberg 也對普通的 column 列做了信息收集。這些統計信息非常全，包括列的 size，列的 value count，null value count，以及列的最大最小值等等。這些信息都可以用來在查詢時過濾數據。
Iceberg 提供了建表的 API，用戶可以使用該 API 指定表名、schema、partition 信息等，然后在 Hive catalog 中完成建表。
五、關於Delta
Delta 的定位是流批一體的 Data Lake 存儲層，支持 update/delete/merge。由於出自 Databricks，spark 的所有數據寫入方式，包括基於 dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是支持的（開源的 SQL 寫暫不支持，EMR 做了支持）。不強調主鍵，因此其 update/delete/merge 的實現均是基於 spark 的 join 功能。在數據寫入方面，Delta 與 Spark 是強綁定的，這一點 Hudi 是不同的：Hudi 的數據寫入不綁定 Spark（可以用 Spark，也可以使用 Hudi 自己的寫入工具寫入）。
在查詢方面，開源 Delta 目前支持 Spark 與 Presto，但是，Spark 是不可或缺的，因為 delta log 的處理需要用到 Spark。這意味着如果要用 Presto 查詢 Delta，查詢時還要跑一個 Spark 作業。更為蛋疼的是，Presto 查詢是基於 SymlinkTextInputFormat 。在查詢之前，要運行 Spark 作業生成這么個 Symlink 文件。如果表數據是實時更新的，意味着每次在查詢之前先要跑一個 SparkSQL，再跑 Presto。為此，EMR 在這方面做了改進可以不必事先啟動一個 Spark 任務。
在查詢性能方面，開源的 Delta 幾乎沒有任何優化。
Delta 在數據 merge 方面性能不如 Hudi，在查詢方面性能不如 Iceberg，是不是意味着 Delta 一無是處了呢？其實不然。Delta 的一大優點就是與 Spark 的整合能力，尤其是其流批一體的設計，配合 multi-hop 的 data pipeline，可以支持分析、Machine learning、CDC 等多種場景。使用靈活、場景支持完善是它相比 Hudi 和 Iceberg 的最大優點。另外，Delta 號稱是 Lambda 架構、Kappa 架構的改進版，無需關心流批，無需關心架構。這一點上 Hudi 和 Iceberg 是力所不及的。
六、總結
三個引擎的初衷場景並不完全相同，Hudi 為了 incremental 的 upserts，Iceberg 定位於高性能的分析與可靠的數據管理，
Delta 定位於流批一體的數據處理。這種場景的不同也造成了三者在設計上的差別。尤其是 Hudi，其設計與另外兩個相比差別
更為明顯。 因此后面是趨同還築起各自專長優勢壁壘未可知。
Delta、Hudi、Iceberg三個開源項目中，Delta和Hudi跟Spark的代碼深度綁定，尤其是寫入路徑。這兩個項目設計之初，
都基本上把Spark作為他們的默認計算引擎了。而Apache Iceberg的方向非常堅定，宗旨就是要做一個通用化設計的Table Format。
它完美的解耦了計算引擎和底下的存儲系統，便於多樣化計算引擎和文件格式，很好的完成了數據湖架構中的Table Format
這一層的實現，因此也更容易 成為Table Format層的開源事實標准。
另一方面，Apache Iceberg也在朝着流批一體的數據存儲層發展，manifest和snapshot的設計，有效地隔離不同transaction
的變更 ，非常方便批處理和增量計算。並且，Apache Flink已經是一個流批一體的計算引擎，二都可以完美匹配，合力打造
流批一體的數據湖架構。
最后，Apache Iceberg這個項目背后的社區資源非常豐富。在國外，Netflix、Apple、Linkedin、Adobe等公司都有PB級別的
生產數據運行在Apache Iceberg上；在國內，騰訊這樣的巨頭也有非常龐大的數據跑在Apache Iceberg之上，最大的業務每天有
幾十T的增量數據寫入。社區成員同樣非常資源和多樣化，擁有來自其他項目的7位ApachePMC ， 1為VP。體現在代碼和設計
的review上，就變得非常苛刻，一個稍微大一點的PR涉及100+的comment很常見。這些都使得Apache Iceberg的設計+代碼質量比較高。
Apache Iceberg 0.10.0 版本的發布，已經拉開集成 Flink 和 Iceberg 的序幕。
基於以上，個人比較推薦選擇Apache Iceberg，並且建議和Apark Flink搭配。