資料湖倉比較：Apache Hudi、Delta Lake、Apache Iceberg

功能比較
首先讓我們看一個整體的功能比較。在您閱讀時，請注意 Hudi 社群如何在湖儲存格式之上投入巨資開發綜合平臺服務。雖然格式對於標準化和互操作性至關重要，但表/平臺服務為您提供了一個強大的工具包，可以輕鬆開發和管理您的資料湖部署。

比較表格點選標題見原文
或按這裡

功能亮點
當然，構建資料湖平臺不僅僅是功能可用性的核取方塊。讓我們選擇上面的一些差異化功能，用簡單的英語深入研究用例和真正的好處。

1、增量管道

​

今天的大多數資料工程師都覺得他們必須在流式處理和老式批處理 ETL 管道之間做出選擇。Apache Hudi 開創了一種稱為增量管道的新範例。開箱即用，Hudi 跟蹤所有更改（追加、更新、刪除）並將它們公開為更改流。使用記錄級索引，您可以更有效地利用這些更改流來避免重新計算資料並僅以增量方式處理更改。雖然其他資料湖平臺可能會提供一種增量消費更改的方式，但 Hudi 的設計初衷就是高效地實現增量化，從而以更低的延遲實現成本效益高的 ETL 管道。

Databricks 最近開發了一個類似的功能，他們稱之為Change Data Feed，他們一直持有該功能，直到最終在 Delta Lake 2.0 中開源。Iceberg 有增量讀取，但它只允許您讀取增量附加，沒有更新/刪除，這對於真正的變更資料捕獲和事務資料至關重要。

2、併發控制

​
ACID 事務和併發控制是 Lakehouse 的關鍵特徵，但與現實世界的工作負載相比，當前的設計實際上是如何疊加的？Hudi、Delta 和 Iceberg 都支援樂觀併發控制(OCC)。在樂觀併發控制中，編寫者檢查他們是否有重疊的檔案，如果存在衝突，他們就會使操作失敗並重試。以 Delta Lake 為例，這只是在單個 Apache Spark 驅動程式節點上持有的 JVM 級別鎖，這意味著您在單個叢集之外沒有 OCC，直到最近這個情況發生。

雖然這可能適用於僅附加的不可變資料集，但樂觀併發控制在現實世界場景中遇到困難，由於資料載入模式或重組資料以提高查詢效能，因此需要頻繁更新和刪除。通常，讓編寫器離線以進行表管理以確保表的健康和高效能是不切實際的。Apache Hudi 併發控制比其他資料湖平臺（檔案級別）更精細，並且針對多個小更新/刪除進行了最佳化的設計，在大多數現實世界的情況下，衝突的可能性可以大大降低到可以忽略不計。

3、合併閱讀
任何好的資料庫系統都支援寫入和查詢效能之間的不同權衡。Hudi 社群在為整個行業的資料湖儲存定義這些概念方面做出了一些開創性的貢獻。Hudi、Delta 和 Iceberg 都將資料寫入和儲存在 parquet 檔案中。發生更新時，這些 parquet 檔案會進行版本控制和重寫。這種寫模式模式就是業界現在所說的寫時複製 (CoW)。此模型非常適合最佳化查詢效能，但可能會限制寫入效能和資料新鮮度。

除了 CoW，Apache Hudi 還支援另一種表儲存佈局，稱為Merge On Read（鐵道部）。MoR 使用列式 parquet 檔案和基於行的 Avro 日誌檔案的組合來儲存資料。更新可以在日誌檔案中批次更新，以後可以同步或非同步壓縮到新的 parquet 檔案中，以平衡最大查詢效能和降低寫入放大。

​
因此，對於近乎實時的流式工作負載，Hudi 可以使用更高效的面向行的格式，而對於批處理工作負載，hudi 格式使用可向量化的面向列的格式，並在需要時無縫合並兩種格式。許多使用者轉向 Apache Hudi，因為它是唯一具有此功能的專案，可讓他們實現無與倫比的寫入效能和 E2E 資料管道延遲。

4、分割槽演變
Apache Iceberg 經常強調的一個特性是隱藏分割槽，它解鎖了所謂的分割槽演化。基本思想是當您的資料開始演變，或者您只是沒有從當前分割槽方案中獲得所需的效能價值時，分割槽演變允許您更新分割槽以獲取新資料而無需重寫資料。當你進化你的分割槽時，舊資料會留在舊的分割槽方案中，只有新資料會隨著你的進化而分割槽。如果使用者不知道演化歷史，則以多種方式分割槽的表會將複雜性推給使用者，並且無法保證一致的效能。

​

Apache Hudi 採用不同的方法來解決隨著資料隨著叢集的發展而調整資料佈局的問題。您可以選擇粗粒度的分割槽策略，甚至不分割槽，並在每個分割槽內使用更細粒度的叢集策略。叢集可以同步或非同步執行，並且可以在不重寫任何資料的情況下進行演進。這種方法可以與Snowflake的微分割槽和叢集策略相媲美。

5、多schema索引

​

索引是資料庫和資料倉儲不可或缺的組成部分，但在資料湖中基本上不存在。在最近的版本中，Apache Hudi 為 Lakehouse 建立了首創的高效能索引子系統，我們稱之為Hudi 多模式索引。Apache Hudi 提供了一種非同步索引機制，允許您在不影響寫入延遲的情況下構建和更改索引。這種索引機制具有可擴充套件性和可擴充套件性，可以支援任何流行的索引技術，例如 Bloom、Hash、Bitmap、R-tree 等。

這些索引儲存在Hudi 後設資料表中，該表儲存在資料旁邊的雲端儲存中。在這個新版本中，後設資料以最佳化的索引檔案格式編寫，與 Delta 或 Iceberg 通用檔案格式相比，點查詢的效能提高了 10-100 倍。在測試真實世界的工作負載時，這個新的索引子系統可將整體查詢效能提高 10-30 倍。

6、攝取工具
資料平臺與資料格式的不同之處在於可用的運營服務。Apache Hudi 的一個與眾不同之處是名為DeltaStreamer的強大攝取實用程式。DeltaStreamer 經過實戰測試並在生產中使用，以構建當今地球上一些最大的資料湖。DeltaStreamer 是一個獨立的實用程式，它允許您從各種來源（如 DFS、Kafka、資料庫更改日誌、S3 事件、JDBC 等）增​​量攝取上游更改。

Iceberg 沒有託管攝取實用程式的解決方案，而 Delta Autoloader 仍然是 Databricks 的專有功能，僅支援 S3 等雲端儲存源。

用例 - 來自社群的示例
功能比較和基準測試可以幫助新手確定可用的技術選擇，但更重要的是評估您的個人用例和工作負載，以找到適合您的資料架構的合適方式。所有這三種技術，Hudi、Delta、Iceberg，對於某些用例都有不同的起源故事和優勢。Iceberg 誕生於 Netflix，旨在解決檔案列表等雲端儲存規模問題。Delta 誕生於 Databricks，它在使用 Databricks Spark 執行時具有深度整合和加速功能。Hudi 誕生於 Uber，旨在為近乎實時的 PB 級資料湖提供支援，並提供無痛的表管理。

經過多年在社群中參與現實世界的比較評估，當您擁有超越簡單的僅附加插入的成熟工作負載時，Apache Hudi 通常具有技術優勢。一旦您開始處理許多更新、開始新增真正的併發性或嘗試減少管道的 E2E 延遲，Apache Hudi 就會在效能和功能集方面成為行業領導者。

以下是來自社群的幾個示例和故事，他們獨立評估並決定使用 Apache Hudi：

亞馬遜包裹遞送系統-
“ATS 面臨的最大挑戰之一是處理 PB 級資料，需要以最小的時間延遲進行持續的插入、更新和刪除，這反映了真實的業務場景和資料包向下遊資料消費者的移動。”
“在這篇文章中，我們展示了我們如何以每小時數百 GB 的速度實時攝取資料，並使用使用 AWS Glue Spark 作業和其他方法載入的Apache Hudi表在 PB 級資料湖上執行插入、更新和刪除操作。 AWS 無伺服器服務，包括 AWS Lambda、Amazon Kinesis Data Firehose 和 Amazon DynamoDB”

位元組跳動/抖音
“在我們的場景中，效能挑戰是巨大的。單張表最大資料量達到400PB+，日增量為PB級，總資料量達到EB級。”
“吞吐量比較大。單表吞吐量超過100GB/s，單表需要PB級儲存。資料模式很複雜。資料是高維和稀疏的。表格列的數量範圍從 1,000 到 10,000+。而且有很多複雜的資料型別。”
“在決定引擎時，我們檢查了三個最流行的資料湖引擎，Hudi、Iceberg 和 DeltaLake。這三者在我們的場景中各有優缺點。最終選擇Hudi作為儲存引擎是基於Hudi對上下游生態的開放性、對全域性索引的支援，以及針對某些儲存邏輯的定製化開發介面。”

沃爾瑪

​

從影片轉錄：
“好吧，是什麼讓我們為我們提供了支援，為什麼我們真的很喜歡在其他用例中解鎖了這一功能的Hudi功能？我們喜歡我們可以使用的樂觀併發或 mvcc 控制元件。我們圍繞非同步壓縮做了很多工作。我們正在考慮對讀取表的合併進行非同步壓縮而不是內聯壓縮。
我們還希望減少延遲，因此我們顯著利用了讀取表上的合併，因為這使我們能夠更快地追加資料。我們也喜歡對刪除的原生支援。這是我們為 ccpa 和 gdpr 之類的東西構建的自定義框架，有人會在其中放入服務檯票，我們必須構建一個自動化流程來從 hdfs 中刪除記錄，這對我們來說是開箱即用的。

行版本控制非常重要，顯然我們的很多管道都有亂序資料，我們需要顯示最新的記錄，因此我們提供版本金鑰作為我們框架的一部分，用於將所有 upsert 插入到hudi 表中。

客戶可以選擇要保留多少行版本，能夠提供快照查詢並獲得增量更新（例如過去五個小時內更新的內容），這一事實對很多使用者來說真的很強大”

羅賓漢
“Robinhood 確實需要保持資料湖的低資料新鮮度。許多過去在市場交易時間之後或之前以每日節奏執行的批處理管道必須以每小時或更高的頻率執行，以支援不斷髮展的用例。很明顯，我們需要更快的攝取管道將線上資料庫複製到資料湖。”
“我們正在使用Apache Hudi從 Kafka 增量攝取變更日誌，以建立資料湖表。Apache Hudi 是一個統一的資料湖平臺，用於在資料湖上執行批處理和流處理。Apache Hudi 帶有一個功能齊全的基於 Spark 的開箱即用的攝取系統，稱為 Deltastreamer，具有一流的 Kafka 整合和一次性寫入功能。與不可變資料不同，我們的 CDC 資料有相當大比例的更新和刪除。Hudi Deltastreamer 利用其可插入的記錄級索引在 Data Lake 表上執行快速高效的 upserts。”

Zendesk
“資料湖管道將 Zendesk 高度分散式資料庫中的資料整合到資料湖中進行分析。
Zendesk 使用 Amazon Database Migration Service (AWS DMS) 從 8 個 AWS 區域的 1,800 多個 Amazon Aurora MySQL 資料庫中捕獲變更資料 (CDC)。它使用 Amazon EMR 和Hudi檢測事務更改並將其應用到資料湖。
Zendesk 票證資料包含超過 100 億個事件和 PB 級資料。Amazon S3 中的資料湖檔案以Apache Hudi格式進行轉換和儲存，並在 AWS Glue 目錄中註冊，可用作資料湖表，用於透過 Amazon Athena 進行分析查詢和使用。”

GE航空
“在 AWS 中引入更無縫的Apache Hudi體驗對我們的團隊來說是一個巨大的勝利。我們一直忙於將 Hudi 整合到我們的 CDC 交易管道中，並且對結果感到非常興奮。我們能夠花更少的時間編寫程式碼來管理我們的資料儲存，而將更多的時間集中在我們系統的可靠性上。這對我們的擴充套件能力至關重要。隨著我們接近另一個主要的生產切換，我們的開發管道已超過 10,000 個表和 150 多個源系統。”

一個創新的社群
最後，鑑於 Lakehouse 技術的發展速度有多快，重要的是要考慮該領域的開源創新來自何處。以下是一些起源於 Hudi 的基本思想和功能，現在正在被其他專案採用。
‍
事實上，除了表後設資料（檔案列表、列統計資訊）支援之外，Hudi 社群還開創了構成當今湖屋的大多數其他關鍵功能。在過去的 4 年裡，該社群已經支援了 1500 多個使用者問題和 5500 多個 slack 支援執行緒，並且正在以雄心勃勃的願景迅速發展壯大。使用者可以將這種創新記錄視為未來的領先指標。

結論
在為您的 Lakehouse 選擇技術時，對您自己的個人用例進行評估非常重要。功能比較電子表格和基準測試不應該是最終的決定因素，因此我們希望這篇博文只是為您在決策過程中提供一個起點和參考。Apache Hudi 具有創新性，久經沙場，並且會一直存在。
‍