數據湖作為新一代大數據基礎設施，近年來持續火熱，許多前線的同學都在討論數據湖應該怎麼建，許多企業也都在構建或者計劃構建自己的數據湖。基於此，自然引發了許多關於數據湖選型的討論和探究。但是經過搜索之後我們發現，網上現存的很多內容都是基於較早之前的開源信息做出的結論，在企業調研初期容易造成不准確的印象和 ...
數據湖作為新一代大數據基礎設施，近年來持續火熱，許多前線的同學都在討論數據湖應該怎麼建，許多企業也都在構建或者計劃構建自己的數據湖。基於此，自然引發了許多關於數據湖選型的討論和探究。但是經過搜索之後我們發現，網上現存的很多內容都是基於較早之前的開源信息做出的結論，在企業調研初期容易造成不准確的印象和理解。
因此帶著這樣的問題，我們計劃推出數據湖選型系列文章，基於最新的開源信息，從升級數據湖架構的幾個重要緯度幫助大家進行深度對比。希望能拋磚引玉，引起大家一些思考和共鳴，歡迎同學們一起探討。
實踐過程中我們發現，在計劃升級數據湖架構的客戶中，支持數據的事務更新通常是大家的第一基礎訴求。因此，該系列的第一篇內容我們將從需求的誕生背景，以及不同數據湖架構在數據事務上的能力對比，兩個方面幫助大家在數據湖選型之路上做出更好的決定。
需求背景
在傳統的 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=szbky
同時，歡迎對大數據開源項目有興趣的同學加入「袋鼠雲開源框架釘釘技術qun」，交流最新開源技術信息，qun號碼：30537511，項目地址：https://github.com/DTStack
