資料湖作為新一代大資料基礎設施，近年來持續火熱，許多前線的同學都在讨論資料湖應該怎麼建，許多企業也都在建構或者計劃建構自己的資料湖。基于此，自然引發了許多關于資料湖選型的讨論和探究。但是經過搜尋之後我們發現，網上現存的很多内容都是基于較早之前的開源資訊做出的結論，在企業調研初期容易造成不準确的印象和了解。
是以帶着這樣的問題，我們計劃推出資料湖選型系列文章，基于最新的開源資訊，從更新資料湖架構的幾個重要緯度幫助大家進行深度對比。希望能抛磚引玉，引起大家一些思考和共鳴，歡迎同學們一起探讨。
實踐過程中我們發現，在計劃更新資料湖架構的客戶中，支援資料的事務更新通常是大家的第一基礎訴求。是以，該系列的第一篇内容我們将從需求的誕生背景，以及不同資料湖架構在資料事務上的能力對比，兩個方面幫助大家在資料湖選型之路上做出更好的決定。
需求背景
在傳統的 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 管理、查詢加速、批流一體等更多緯度的對比内容。歡迎大家和我們一起探讨交流。
同時，袋鼠雲也有自己的資料湖倉一體化建構平台 EasyLake，提供面向湖倉一體的資料湖管理分析服務，基于統一的中繼資料抽象建構一緻性的資料通路，提供海量資料的存儲管理和實時分析處理能力。
《資料治理行業實踐白皮書》下載下傳位址：https://fs80.cn/380a4b
想了解或咨詢更多有關袋鼠雲大資料産品、行業解決方案、客戶案例的朋友，浏覽袋鼠雲官網：https://www.dtstack.com/?src=sztth
開源項目位址：https://github.com/DTStack