資料湖選型指南｜Hudi vs Iceberg 資料更新能力深度對比

作為新一代大資料基礎設施，近年來持續火熱，許多前線的同學都在討論資料湖應該怎麼建，許多企業也都在構建或者計劃構建自己的資料湖。基於此，自然引發了許多關於 的討論和探究。但是經過搜尋之後我們發現，網上現存的很多內容都是基於較早之前的開源資訊做出的結論，在企業調研初期容易造成不準確的印象和理解。

因此帶著這樣的問題，我們計劃推出資料湖選型系列文章，基於最新的開源資訊，從 的幾個重要緯度幫助大家進行深度對比。希望能拋磚引玉，引起大家一些思考和共鳴，歡迎同學們一起探討。

實踐過程中我們發現，在計劃升級資料湖架構的客戶中， 通常是大家的第一基礎訴求。因此，該系列的第一篇內容我們將從需求的誕生背景，以及不同資料湖架構在資料事務上的能力對比，兩個方面幫助大家在資料湖選型之路上做出更好的決定。

需求背景

在傳統的 Hive 離線數倉架構下，資料更新的成本是非常大的，更新一條資料需要重寫整個分割槽甚至整張表。因此在真實業務場景中，出於開發成本、資料風險等方面的考慮，大家都不會在 Hive 數倉中更新資料。

不過隨著 Hive 3.0 的推出，Hive 表在事務能力上也向前邁了一大步，官方在推出 3.0 時也重點宣傳了它的事務能力。不過在實際應用中仍然存在非常大的限制，真實投產的使用者寥寥無幾。（僅支援ORC事務內表，這意味著像Spark這類計算引擎，無法直接在Hive事務表上進行ETL/ELT開發，包括像CDH、袋鼠雲公司都在Spark相容上做過投入，但是效果不佳，遠達不到生產級的應用預期）

因此，在資料湖選型過程中， 就顯得尤為重要。它能夠改變我們在 Hive 數倉中遇到的資料更新成本高的問題，支援對海量的離線資料做更新刪除。

資料更新實現的選型

目前市面上核心的資料湖開源產品大致有這麼幾個：Apache Iceberg、Apache Hudi和 Delta。

本文將為大家重點介紹 Hudi 和 Iceberg 在資料更新實現方面的表現。

Hudi 的資料更新實現

Hudi（Hadoop Update Delete Incremental），從這個名稱可以看出，它的誕生就是為了解決 Hadoop 體系內資料更新和增量查詢的問題。要想弄明白 Hudi 是如何在 HDFS 這類檔案系統上實現快速 update 操作的，我們需要先了解 Hudi 的幾個特性：

· Hudi 表的檔案組織形式：在每個分割槽（Partition）內，資料檔案被切分組織成一個個檔案組（FileGroup），每個檔案組都已 FileID 進行唯 一標識。

· Hudi 表是有主鍵設計的，每條資料都已主鍵進行唯 一標識。

· Hudi 表是有 的。

結合上面的三個特性可以得出，Hudi 表的索引可以幫助我們快速地定位到某一條資料存在於某個分割槽的某個檔案組中，然後對其進行 Update 操作，即重寫這部分檔案組。

Iceberg 的資料更新實現

Iceberg 的官方定位是「 」。所以它沒有像 Hudi 一樣模擬業務資料庫的設計模式（主鍵+索引）來實現資料更新，而是設計了更強大的檔案組織形式來實現資料的 update 操作，詳見下圖：

• Snapshot：使用者的每次 commit 會產生一個新的 snapshot

• Manifest List：維護當前 snapshot 中所有的 manifest

• Manifest：維護當前 Manifest 下所有的 data files 和 delete files

• Data File：儲存資料的檔案

• Delete File：儲存「刪除的資料」的檔案

在上面的檔案組織基礎上，我們可以看出，Iceberg 實現 update 的大致邏輯是：

· 先將要刪除的資料寫入 Delete File；

· 然後將「Data File」 JOIN 「Delete File」進行資料比對，實現資料更新。

當然，實現這兩步有很多技術細節：比如利用 Sequence Number 保障事務順序；Delete File 根據刪除時的檔案狀態判斷是走 position delete 還是 equality delete 邏輯；引入 equality_ids 概念模擬主鍵等。

如何選擇

單純從資料更新能力這個角度來看：

· Hudi 憑藉檔案組+索引+主鍵的設計模式，能夠有效 ，提高資料更新效率。

· Iceberg 透過檔案組織設計也能達到資料更新效果，但是每一次的 commit 都會產生新的檔案，如果寫入/更新頻繁，小檔案問題會比較嚴重。（雖然官方也配套提供了小檔案治理能力，但是這部分的資源消耗、治理難度相對 Hudi 來說會比較大）

如何實踐應用

當我們確定了資料湖選型後，如何在生產環境中進行實踐應用就成為了下一個問題。

這裡就需要提前瞭解表型別這個概念，同一種 也有不同的型別區別，分別適用不同的場景：

• COW（Copy On Write）：寫時複製表。在資料寫入/更新時，立即重寫原有資料檔案，生成一份新的資料檔案。

• MOR（Merge On Read）：讀時合併表。在資料寫入/更新時，不修改原有檔案，寫入新的日誌/檔案，在之後資料被讀取到的時候，重寫資料檔案。

基於這兩種表型別的特性差異，我們給出如下建議：

· 如果你的湖表寫入/更新不頻繁，主要用於支撐資料查詢/分析場景，那建議使用 COW 表。

· 如果你的湖表寫入/更新頻繁（甚至是用於實時開發場景的寫入），那建議使用 MOR 表。

總結

沒有最好的技術架構，只有最適合當前業務的技術架構。

關於資料湖的選型當然也不能簡單從資料更新能力這一單一緯度做出判斷。後續我們將繼續推出不同資料湖架構在 Schema 管理、查詢加速、批流一體等更多緯度的對比內容。歡迎大家和我們一起探討交流。

同時，袋鼠雲也有自己的 ，提供面向湖倉一體的資料湖管理分析服務，基於統一的後設資料抽象構建一致性的資料訪問，提供海量資料的儲存管理和實時分析處理能力。

《資料治理行業實踐白皮書》下載地址：

想了解更多有關袋鼠雲大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網：https://www.dtstack.com/?src=szitpub