數(shù)據(jù)湖作為新一代大數(shù)據(jù)基礎(chǔ)設(shè)施，近年來(lái)持續(xù)火熱，許多前線的同學(xué)都在討論數(shù)據(jù)湖應(yīng)該怎么建，許多企業(yè)也都在構(gòu)建或者計(jì)劃構(gòu)建自己的數(shù)據(jù)湖?；诖?，自然引發(fā)了許多關(guān)于數(shù)據(jù)湖選型的討論和探究。但是經(jīng)過(guò)搜索之后我們發(fā)現(xiàn)，網(wǎng)上現(xiàn)存的很多內(nèi)容都是基于較早之前的開(kāi)源信息做出的結(jié)論，在企業(yè)調(diào)研初期容易造成不準(zhǔn)確的印象和理解。

因此帶著這樣的問(wèn)題，我們計(jì)劃推出數(shù)據(jù)湖選型系列文章，基于最新的開(kāi)源信息，從升級(jí)數(shù)據(jù)湖架構(gòu)的幾個(gè)重要緯度幫助大家進(jìn)行深度對(duì)比。希望能拋磚引玉，引起大家一些思考和共鳴，歡迎同學(xué)們一起探討。

實(shí)踐過(guò)程中我們發(fā)現(xiàn)，在計(jì)劃升級(jí)數(shù)據(jù)湖架構(gòu)的客戶中，支持?jǐn)?shù)據(jù)的事務(wù)更新通常是大家的第一基礎(chǔ)訴求。因此，該系列的第一篇內(nèi)容我們將從需求的誕生背景，以及不同數(shù)據(jù)湖架構(gòu)在數(shù)據(jù)事務(wù)上的能力對(duì)比，兩個(gè)方面幫助大家在數(shù)據(jù)湖選型之路上做出更好的決定。

需求背景

在傳統(tǒng)的 Hive 離線數(shù)倉(cāng)架構(gòu)下，數(shù)據(jù)更新的成本是非常大的，更新一條數(shù)據(jù)需要重寫(xiě)整個(gè)分區(qū)甚至整張表。因此在真實(shí)業(yè)務(wù)場(chǎng)景中，出于開(kāi)發(fā)成本、數(shù)據(jù)風(fēng)險(xiǎn)等方面的考慮，大家都不會(huì)在 Hive 數(shù)倉(cāng)中更新數(shù)據(jù)。

不過(guò)隨著 Hive 3.0 的推出，Hive 表在事務(wù)能力上也向前邁了一大步，官方在推出 3.0 時(shí)也重點(diǎn)宣傳了它的事務(wù)能力。不過(guò)在實(shí)際應(yīng)用中仍然存在非常大的限制，真實(shí)投產(chǎn)的用戶寥寥無(wú)幾。（僅支持ORC事務(wù)內(nèi)表，這意味著像Spark這類計(jì)算引擎，無(wú)法直接在Hive事務(wù)表上進(jìn)行ETL/ELT開(kāi)發(fā)，包括像CDH、袋鼠云公司都在Spark兼容上做過(guò)投入，但是效果不佳，遠(yuǎn)達(dá)不到生產(chǎn)級(jí)的應(yīng)用預(yù)期）

因此，在數(shù)據(jù)湖選型過(guò)程中，高效的并發(fā)更新能力就顯得尤為重要。它能夠改變我們?cè)?Hive 數(shù)倉(cāng)中遇到的數(shù)據(jù)更新成本高的問(wèn)題，支持對(duì)海量的離線數(shù)據(jù)做更新刪除。

數(shù)據(jù)更新實(shí)現(xiàn)的選型

目前市面上核心的數(shù)據(jù)湖開(kāi)源產(chǎn)品大致有這么幾個(gè)：Apache Iceberg、Apache Hudi和 Delta。

本文將為大家重點(diǎn)介紹 Hudi 和 Iceberg 在數(shù)據(jù)更新實(shí)現(xiàn)方面的表現(xiàn)。

Hudi 的數(shù)據(jù)更新實(shí)現(xiàn)

Hudi（Hadoop Update Delete Incremental），從這個(gè)名稱可以看出，它的誕生就是為了解決 Hadoop 體系內(nèi)數(shù)據(jù)更新和增量查詢的問(wèn)題。要想弄明白 Hudi 是如何在 HDFS 這類文件系統(tǒng)上實(shí)現(xiàn)快速 update 操作的，我們需要先了解 Hudi 的幾個(gè)特性：

· Hudi 表的文件組織形式：在每個(gè)分區(qū)（Partition）內(nèi)，數(shù)據(jù)文件被切分組織成一個(gè)個(gè)文件組（FileGroup），每個(gè)文件組都已 FileID 進(jìn)行唯一標(biāo)識(shí)。

· Hudi 表是有主鍵設(shè)計(jì)的，每條數(shù)據(jù)都已主鍵進(jìn)行唯一標(biāo)識(shí)。

· Hudi 表是有索引設(shè)計(jì)的。

結(jié)合上面的三個(gè)特性可以得出，Hudi 表的索引可以幫助我們快速地定位到某一條數(shù)據(jù)存在于某個(gè)分區(qū)的某個(gè)文件組中，然后對(duì)其進(jìn)行 Update 操作，即重寫(xiě)這部分文件組。

Iceberg 的數(shù)據(jù)更新實(shí)現(xiàn)

Iceberg 的官方定位是「面向海量數(shù)據(jù)分析場(chǎng)景的高效存儲(chǔ)格式」。所以它沒(méi)有像 Hudi 一樣模擬業(yè)務(wù)數(shù)據(jù)庫(kù)的設(shè)計(jì)模式（主鍵+索引）來(lái)實(shí)現(xiàn)數(shù)據(jù)更新，而是設(shè)計(jì)了更強(qiáng)大的文件組織形式來(lái)實(shí)現(xiàn)數(shù)據(jù)的 update 操作，詳見(jiàn)下圖：

? Snapshot：用戶的每次 commit 會(huì)產(chǎn)生一個(gè)新的 snapshot

? Manifest List：維護(hù)當(dāng)前 snapshot 中所有的 manifest

? Manifest：維護(hù)當(dāng)前 Manifest 下所有的 data files 和 delete files

? Data File：存儲(chǔ)數(shù)據(jù)的文件

? Delete File：存儲(chǔ)「刪除的數(shù)據(jù)」的文件

在上面的文件組織基礎(chǔ)上，我們可以看出，Iceberg 實(shí)現(xiàn) update 的大致邏輯是：

· 先將要?jiǎng)h除的數(shù)據(jù)寫(xiě)入 Delete File；

· 然后將「Data File」 JOIN 「Delete File」進(jìn)行數(shù)據(jù)比對(duì)，實(shí)現(xiàn)數(shù)據(jù)更新。

當(dāng)然，實(shí)現(xiàn)這兩步有很多技術(shù)細(xì)節(jié)：比如利用 Sequence Number 保障事務(wù)順序；Delete File 根據(jù)刪除時(shí)的文件狀態(tài)判斷是走 position delete 還是 equality delete 邏輯；引入 equality_ids 概念模擬主鍵等。

如何選擇

單純從數(shù)據(jù)更新能力這個(gè)角度來(lái)看：

· Hudi 憑借文件組+索引+主鍵的設(shè)計(jì)模式，能夠有效減少數(shù)據(jù)文件的冗余更新，提高數(shù)據(jù)更新效率。

· Iceberg 通過(guò)文件組織設(shè)計(jì)也能達(dá)到數(shù)據(jù)更新效果，但是每一次的 commit 都會(huì)產(chǎn)生新的文件，如果寫(xiě)入/更新頻繁，小文件問(wèn)題會(huì)比較嚴(yán)重。（雖然官方也配套提供了小文件治理能力，但是這部分的資源消耗、治理難度相對(duì) Hudi 來(lái)說(shuō)會(huì)比較大）

如何實(shí)踐應(yīng)用

當(dāng)我們確定了數(shù)據(jù)湖選型后，如何在生產(chǎn)環(huán)境中進(jìn)行實(shí)踐應(yīng)用就成為了下一個(gè)問(wèn)題。

這里就需要提前了解表類型這個(gè)概念，同一種數(shù)據(jù)湖表格式也有不同的類型區(qū)別，分別適用不同的場(chǎng)景：

? COW（Copy On Write）：寫(xiě)時(shí)復(fù)制表。在數(shù)據(jù)寫(xiě)入/更新時(shí)，立即重寫(xiě)原有數(shù)據(jù)文件，生成一份新的數(shù)據(jù)文件。

? MOR（Merge On Read）：讀時(shí)合并表。在數(shù)據(jù)寫(xiě)入/更新時(shí)，不修改原有文件，寫(xiě)入新的日志/文件，在之后數(shù)據(jù)被讀取到的時(shí)候，重寫(xiě)數(shù)據(jù)文件。

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

· 如果你的湖表寫(xiě)入/更新不頻繁，主要用于支撐數(shù)據(jù)查詢/分析場(chǎng)景，那建議使用 COW 表。

· 如果你的湖表寫(xiě)入/更新頻繁（甚至是用于實(shí)時(shí)開(kāi)發(fā)場(chǎng)景的寫(xiě)入），那建議使用 MOR 表。

總結(jié)

沒(méi)有最好的技術(shù)架構(gòu)，只有最適合當(dāng)前業(yè)務(wù)的技術(shù)架構(gòu)。

關(guān)于數(shù)據(jù)湖的選型當(dāng)然也不能簡(jiǎn)單從數(shù)據(jù)更新能力這一單一緯度做出判斷。后續(xù)我們將繼續(xù)推出不同數(shù)據(jù)湖架構(gòu)在 Schema 管理、查詢加速、批流一體等更多緯度的對(duì)比內(nèi)容。歡迎大家和我們一起探討交流。

同時(shí)，袋鼠云也有自己的數(shù)據(jù)湖倉(cāng)一體化構(gòu)建平臺(tái) EasyLake，提供面向湖倉(cāng)一體的數(shù)據(jù)湖管理分析服務(wù)，基于統(tǒng)一的元數(shù)據(jù)抽象構(gòu)建一致性的數(shù)據(jù)訪問(wèn)，提供海量數(shù)據(jù)的存儲(chǔ)管理和實(shí)時(shí)分析處理能力。

《數(shù)據(jù)治理行業(yè)實(shí)踐白皮書(shū)》下載地址：https://fs80.cn/l134d5?

想了解或咨詢更多有關(guān)袋鼠云大數(shù)據(jù)產(chǎn)品、行業(yè)解決方案、客戶案例的朋友，瀏覽袋鼠云官網(wǎng)：https://www.dtstack.com/?src=szbzhan

同時(shí)，歡迎對(duì)大數(shù)據(jù)開(kāi)源項(xiàng)目有興趣的同學(xué)加入「袋鼠云開(kāi)源框架釘釘技術(shù) qun」，交流最新開(kāi)源技術(shù)信息，qun 號(hào)碼：30537511，項(xiàng)目地址：https://github.com/DTStack