“資料湖”、“湖倉一體”及“流批一體”等概念，是近年來大資料領域熱度最高的詞彙，在各大網際網路公司掀起了一波波的熱潮，各家公司紛紛推出了自己的技術方案，其中作為全鏈路數字化技術與服務提供商的袋鼠雲，在探索資料湖架構的早期，就調研並選用了Iceberg作為基礎框架，在落地過程中深度使用了Iceberg並進行了部分改造，在這個過程中，我們積累出了一些經驗和探索實踐，希望透過本篇文章與大家分享，也歡迎大家一起共同討論。
一、為什麼選擇Iceberg
Iceberg作為Apache基金會下的一個頂級專案，是業界公認的開源資料湖實現方案之一，考慮到任何概念的提出本質上是源於底層軟硬體技術或架構上取得了新的突破，我們首先站在技術演進的角度對Iceberg的出現契機和應用場景進行分析。
01大資料儲存技術現狀
2006年Hadoop框架橫空出世，改變了企業對資料的儲存、處理和分析的認知，加速了大資料的發展，形成了完善的生態圈。工程師們將龐雜的歷史資料存在分散式檔案系統HDFS中，透過Hive、Spark等進行加速計算處理。至今為止，HDFS已然成為廣泛應用的大資料基礎元件。
在這個大資料技術發展過程中，也面臨著一些問題。在Hive中，將表繫結為HDFS上的一個目錄，透過HiveMetaStore記錄其繫結的儲存位置，計算引擎查詢資料時請求主節點獲取檔案並讀取，這天然缺少事務保證：某個使用者寫入的檔案其他使用者立即可見，沒有隔離性；即便先寫入到隱藏檔案中，待事務提交後再全部改名可見，因為一批檔案的改名不是原子操作，這隻能保證分割槽級別的原子性。隨著物件儲存的廣泛應用，透過主節點去獲取全部檔案有比較大的效能損耗，因為物件儲存的“List”效能較差。
經過以上分析，我們發現Hive中這種設計的缺陷在於缺乏對錶資料檔案的管理維護：對於表中不同時刻包含的資料檔案，都要即時訪問HDFS主節點獲取，這樣子就造成了比較大的資源浪費。
而資料湖卻能很好的解決這一問題，資料湖是一個集中各種形式和來源資料的儲存區域，儲存內容雖然種類繁多卻管理有序，對資料檔案的組織維護能夠高效地幫助我們對接各類底層儲存和上層計算。
02 資料湖技術選型——Iceberg
我們知道問題的關鍵在於“對錶資料檔案的管理維護”，基於此就可以開展技術選型了。在2020年末，技術團隊做了眾多技術方案的調研，包括包括Delta Lake、Hudi、Iceberg，我們最終選用了Iceberg。
而選擇Iceberg的原因，正是基於袋鼠雲的技術棧的具體情況做了充足考慮：袋鼠雲中的離線計算、實時計算、智慧標籤等應用，在計算層需要依託Spark、Flink、Trino等多種引擎為客戶解決不同的業務訴求，在底層則可能需要對接客戶自建雲、公有云等混合儲存。這就要求所選擇的技術方案必須能滿足對接多種型別的需求。
Iceberg具備介面開放、易於拓展的優點，十分符合我們的選型要求。在儲存層HDFS上增加一箇中間層Iceberg以跟蹤資料檔案，不必改變其他層的架構設計，就可以享受到Iceberg對資料檔案管理帶來的極速體驗與美妙特性。下圖展示了袋鼠雲基於Iceberg框架的資料湖架構設計：
基於前述關鍵點，我們介紹下Iceberg的設計，參考下圖所示：
Iceberg在資料檔案的基礎上增加了檔案清單和檔案快照等索引，透過這些索引我們就能跟蹤到每張表在當前時刻有哪些資料檔案，這就解決了前文提到的Hive中的設計缺陷：某個使用者寫入的臨時檔案不會被其他使用者讀取到，因為這些檔案沒有被快照記錄；每個事務修改跟蹤的資料檔案時，需要向鎖服務進行申請，成功獲取到鎖許可之後可以更新快照內容，一次快照修改可以增加多個檔案，這樣就保證原子性；預先記錄好目錄下的每個資料檔案可以避免對HDFS主節點的多次訪問，對雲端儲存友好。
二、Iceberg在袋鼠雲中的應用實踐
01 行級更新
在Hive中想要對歷史資料進行訂正，需要用增量資料合併歷史資料後替換歷史資料，這種方式的代價是比較大的，即便是很少的更新也需要對全表或者整個分割槽進行掃描。
利用Iceberg這種合併和覆寫可以被推遲，如下圖所示：
在Iceberg中，可以寫入一份標記刪除的資料檔案並再寫入更新後的資料檔案，這樣的好處是訂正歷史資料時使用者在數棧平臺的操作等待時間會很短，在查詢的時候再對這個標記刪除檔案中的資料進行更新，準確查詢到更新之後的資料。而實際對資料檔案內容合併的耗時操作推遲在使用者休息的時候，保證了後續操作的效能。
02 查詢加速
在HDFS上，資料檔案通常採用Parquet、ORC等儲存格式，這些儲存格式中記錄了諸如列最大值/最小值/空值等詳細的元資料資訊，因此在進行查詢的過程中，Iceberg充分利用了儲存格式提供的元資料資訊進行檔案過濾。
使用者在數棧平臺寫入資料時，在檔案清單中彙總了每個檔案中儲存資料每一列的最大值/最小值/空值資訊。在查詢資料時，對查詢條件和彙總資訊進行交集判斷，對於沒有交集的檔案就不需要再去讀取了，這樣就能夠極大的減少需要讀取的檔案數量。
考慮到資料檔案的分佈是在寫入時決定的，在寫入資料順序不規律的情況下，檔案中的最大值/最小值範圍跨度會很大，這樣並集判斷過濾的效果就沒有那麼明顯了，這時候在數棧平臺上按照一定規則對資料進行重排列，使得具有相似特徵的資料落入到同一個資料檔案裡，這樣提取出來的最大值/最小值資訊就會在更接近的範圍裡，查詢過濾效能會有更大提升。
03 自動治理
在Iceberg的寫入過程中，為了支援快速寫入和資料跟蹤等功能，其代價是會在每次操作引入不同數量的小檔案，這些小檔案會隨著時間的前進而不斷拖延系統的效率，必須要透過合併操作進行刪除才能繼續保證系統的高效。
Iceberg本身提供了檔案合併、快照清理等工具，但這需要使用者手動去啟動任務才能觸發，對於使用者來說是額外心智負擔。
如上圖所示，袋鼠雲在產品設計上為使用者遮蔽了這種運維上的複雜度，使用者只需要對錶進行基本引數的設定就可以享受新框架最佳化後帶來的快速和便捷，而更復雜的檔案治理任務的啟動和資源配置都交由後臺程式監控完成。
三、袋鼠雲基於Iceberg的改造
除了對Iceberg本身提供的能力進行應用，袋鼠雲還根據生產場景的要求對Iceberg做了一定的改造。
01 列更新
在袋鼠雲標籤引擎中經常有需要根據原子指標生成派生指標的場景，在後臺程式中就是為一張大寬表增加新的欄位並且填入資料。在過去，我們依賴OverWrite操作在HDFS上重寫新的表資料，然而這種操作都需要將全部欄位資料進行寫入，非常消耗儲存和時間的（想象一下一張表有幾百個欄位，每次都需要重新寫入）。
基於Iceberg袋鼠雲設計了一種最佳化方案，如上圖所示：保留原來的資料檔案，列更新時將新的欄位資料和表的主鍵欄位資料一起寫入到新的資料檔案。這樣，在寫入過程中需要寫入的資料量就大大減少了，而在讀取過程中，再將新欄位和原有的欄位做一次合併，這樣就能夠保證資料的準確性。同時我們還會在查詢時只讀取包含查詢欄位的檔案以提高查詢效能。
當然，在多次新增新欄位之後，每次查詢中包含的合併操作就多了，效能就會隨之下降，這就需要結合前述的檔案合併功能，定時進行資料合併，這樣更新累計的副作用就可以消除了。
02 批流一體
批流一體在儲存上要解決的很重要的問題是：離線數倉依賴HDFS儲存，HDFS能夠提供大規模的儲存，成本低廉，然而其實時性比較差；實時數倉依賴Kafka儲存，Kafka能夠儲存的資料量有限，但是能夠提供非常好的實時性。兩條技術鏈路帶來了理解和使用上的困難，能否提供統一的儲存是批流一體架構落地的關鍵。
在袋鼠雲中，我們提出了一種基於Iceberg的遮蔽能力，構建的針對這兩種元件的統一儲存方案：底層儲存混合使用Iceberg和Kafka，但對使用者只暴露一張完整的資料表，在Iceberg中記錄Kafka的切換位點（偏移量），讀取時根據當前資料的時間資訊選擇讀取Kafka或者Iceberg資料來源。如下圖所示：
具體步驟有：
1）在建立表時，設定Iceberg儲存和Kafka儲存相關的元資料資訊。
2）寫入資料時，向兩種儲存介質一起寫入。在Iceberg每次生成新快照時，將最後一條資料對應的Kafka偏移量寫入快照資訊裡。使用者可以選擇性開始Kafka事務保證。
3）讀取資料時，在最近一段時間內的資料都透過Kafka進行消費，在讀取完Kafka的資料後根據偏移量切換到對Iceberg記錄的HDFS檔案進行訪問，讀取歷史資料。
這樣就能符合了袋鼠雲使用者使用不同處理速度去處理不同階段資料的需求。
四、寫在最後
以上就是袋鼠雲基於Iceberg在資料湖的一些探索和實踐，目前這種框架已應用於我們的資料湖產品DataLake——提供面向湖倉一體的資料湖管理分析服務。基於統一的元資料抽象構建一致性的資料訪問，提供海量資料的儲存管理和實時分析處理能力，可以幫助企業快速構建湖倉一體化平臺，完成數字化基礎建設。
未來我們還會對資料湖和湖倉一體架構做更多的探索和應用，敬請期待。
歡迎大家瞭解或諮詢更多有關資料湖產品的資訊
歡迎大家瞭解或諮詢更多有關資料湖產品的資訊 想了解或諮詢更多有關袋鼠雲大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網：https：//www。dtstack。com/？alt="Iceberg在袋鼠雲的探索及實踐" data-isLoading="0" src="/static/img/blank.gif" data-src=sztth
同時，歡迎對大資料開源專案有興趣的同學加入「袋鼠雲開源框架釘釘技術 qun」，交流最新開源技術資訊，qun 號碼：30537511，專案地址：https：//github。com/DTStack