Data Lake 三劍客—Delta、Hudi、Iceberg 對比分析

本文來源於雲棲社區：https://yq.aliyun.com/article...
做者：xy_xin

共同點

定性上講，三者均爲 Data Lake 的數據存儲中間層，其數據管理的功能均是基於一系列的 meta 文件。meta 文件的角色相似於數據庫的 catalog/wal，起到 schema 管理、事務管理和數據管理的功能。與數據庫不一樣的是，這些 meta 文件是與數據文件一塊兒存放在存儲引擎中的，用戶能夠直接看到。這種作法直接繼承了大數據分析中數據對用戶可見的傳統，可是無形中也增長了數據被不當心破壞的風險。一旦某個用戶不當心刪了 meta 目錄，表就被破壞了，想要恢復難度很是大。

Meta 文件包含有表的 schema 信息。所以系統能夠本身掌握 Schema 的變更，提供 Schema 演化的支持。Meta 文件也有 transaction log 的功能（須要文件系統有原子性和一致性的支持）。全部對錶的變動都會生成一份新的 meta 文件，因而系統就有了 ACID 和多版本的支持，同時能夠提供訪問歷史的功能。在這些方面，三者是相同的。

下面來談一下三者的不一樣。

Hudi

先說 Hudi。Hudi 的設計目標正如其名，Hadoop Upserts Deletes and Incrementals（原爲 Hadoop Upserts anD Incrementals），強調了其主要支持 Upserts、Deletes 和 Incremental 數據處理，其主要提供的寫入工具是 Spark HudiDataSource API 和自身提供的 DeltaStreamer，均支持三種數據寫入方式：UPSERT，INSERT 和 BULK_INSERT。其對 Delete 的支持也是經過寫入時指定必定的選項支持的，並不支持純粹的 delete 接口。

其典型用法是將上游數據經過 Kafka 或者 Sqoop，經由 DeltaStreamer 寫入 Hudi。DeltaStreamer 是一個常駐服務，不斷地從上游拉取數據，並寫入 hudi。寫入是分批次的，而且能夠設置批次之間的調度間隔。默認間隔爲 0，相似於 Spark Streaming 的 As-soon-as-possible 策略。隨着數據不斷寫入，會有小文件產生。對於這些小文件，DeltaStreamer 能夠自動地觸發小文件合併的任務。

在查詢方面，Hudi 支持 Hive、Spark、Presto。

在性能方面，Hudi 設計了 HoodieKey，一個相似於主鍵的東西。HoodieKey有 Min/Max 統計，BloomFilter，用於快速定位 Record 所在的文件。在具體作 Upserts 時，若是 HoodieKey 不存在於 BloomFilter，則執行插入，不然，確認 HoodieKey 是否真正存在，若是真正存在，則執行 update。這種基於 HoodieKey + BloomFilter 的 upserts 方法是比較高效的，不然，須要作全表的 Join 才能實現 upserts。對於查詢性能，通常需求是根據查詢謂詞生成過濾條件下推至 datasource。Hudi 這方面沒怎麼作工做，其性能徹底基於引擎自帶的謂詞下推和 partition prune 功能。

Hudi 的另外一大特點是支持 Copy On Write 和 Merge On Read。前者在寫入時作數據的 merge，寫入性能略差，可是讀性能更高一些。後者讀的時候作 merge，讀性能查，可是寫入數據會比較及時，於是後者能夠提供近實時的數據分析能力。

最後，Hudi 提供了一個名爲 run_sync_tool 的腳本同步數據的 schema 到 Hive 表。Hudi 還提供了一個命令行工具用於管理 Hudi 表。

hudiimage

Iceberg

Iceberg 沒有相似的 HoodieKey 設計，其不強調主鍵。上文已經說到，沒有主鍵，作 update/delete/merge 等操做就要經過 Join 來實現，而 Join 須要有一個 相似 SQL 的執行引擎。Iceberg 並不綁定某個引擎，也沒有本身的引擎，因此 Iceberg 並不支持 update/delete/merge。若是用戶須要 update 數據，最好的方法就是找出哪些 partition 須要更新，而後經過 overwrite 的方式重寫數據。Iceberg 官網提供的 quickstart 以及 Spark 的接口均只是提到了使用 Spark dataframe API 向 Iceberg 寫數據的方式，沒有說起別的數據攝入方法。至於使用 Spark Streaming 寫入，代碼中是實現了相應的 StreamWriteSupport，應該是支持流式寫入，可是貌似官網並未明確說起這一點。支持流式寫入意味着有小文件問題，對於怎麼合併小文件，官網也未說起。我懷疑對於流式寫入和小文件合併，可能 Iceberg 尚未很好的生產 ready，於是沒有說起（純屬我的猜想）。

在查詢方面，Iceberg 支持 Spark、Presto。

Iceberg 在查詢性能方面作了大量的工做。值得一提的是它的 hidden partition 功能。Hidden partition 意思是說，對於用戶輸入的數據，用戶能夠選取其中某些列作適當的變換（Transform）造成一個新的列做爲 partition 列。這個 partition 列僅僅爲了將數據進行分區，並不直接體如今表的 schema 中。例如，用戶有 timestamp 列，那麼能夠經過 hour(timestamp) 生成一個 timestamp_hour 的新分區列。timestamp_hour 對用戶不可見，僅僅用於組織數據。Partition 列有 partition 列的統計，如該 partition 包含的數據範圍。當用戶查詢時，能夠根據 partition 的統計信息作 partition prune。

除了 hidden partition，Iceberg 也對普通的 column 列作了信息收集。這些統計信息很是全，包括列的 size，列的 value count，null value count，以及列的最大最小值等等。這些信息均可以用來在查詢時過濾數據。

Iceberg 提供了建表的 API，用戶可使用該 API 指定代表、schema、partition 信息等，而後在 Hive catalog 中完成建表。

Delta

咱們最後來講 Delta。Delta 的定位是流批一體的 Data Lake 存儲層，支持 update/delete/merge。因爲出自 Databricks，spark 的全部數據寫入方式，包括基於 dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是支持的（開源的 SQL 寫暫不支持，EMR 作了支持）。與 Iceberg 相似，Delta 不強調主鍵，所以其 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。這樣的話爲什麼不都在 SparkSQL 裏搞定呢？這是一個很是蛋疼的設計。爲此，EMR 在這方面作了改進，支持了 DeltaInputFormat，用戶能夠直接使用 Presto 查詢 Delta 數據，而沒必要事先啓動一個 Spark 任務。

在查詢性能方面，開源的 Delta 幾乎沒有任何優化。Iceberg 的 hidden partition 且不說，普通的 column 的統計信息也沒有。Databricks 對他們引覺得傲的 Data Skipping 技術作了保留。不得不說這對於推廣 Delta 來講不是件好事。EMR 團隊在這方面正在作一些工做，但願能彌補這方面能力的缺失。

Delta 在數據 merge 方面性能不如 Hudi，在查詢方面性能不如 Iceberg，是否是意味着 Delta 一無可取了呢？其實否則。Delta 的一大優勢就是與 Spark 的整合能力（雖然目前仍不是很完善，但 Spark-3.0 以後會好不少），尤爲是其流批一體的設計，配合 multi-hop 的 data pipeline，能夠支持分析、Machine learning、CDC 等多種場景。使用靈活、場景支持完善是它相比 Hudi 和 Iceberg 的最大優勢。另外，Delta 號稱是 Lambda 架構、Kappa 架構的改進版，無需關心流批，無需關心架構。這一點上 Hudi 和 Iceberg 是力所不及的。

deltaimage

總結

經過上面的分析可以看到，三個引擎的初衷場景並不徹底相同，Hudi 爲了 incremental 的 upserts，Iceberg 定位於高性能的分析與可靠的數據管理，Delta 定位於流批一體的數據處理。這種場景的不一樣也形成了三者在設計上的差異。尤爲是 Hudi，其設計與另外兩個相比差異更爲明顯。隨着時間的發展，三者都在不斷補齊本身缺失的能力，可能在未來會彼此趨同，互相侵入對方的領地。固然也有可能各自關注本身專長的場景，築起本身的優點壁壘，所以最終誰贏誰輸仍是未知之數。

關注個人公衆號，後臺回覆【JAVAPDF】獲取200頁面試題！
5萬人關注的大數據成神之路，不來了解一下嗎？
5萬人關注的大數據成神之路，真的不來了解一下嗎？
5萬人關注的大數據成神之路，肯定真的不來了解一下嗎？

歡迎您關注《大數據成神之路》