“資料湖”、“湖倉一體”及“流批一體”等概念，是近年來大資料領域熱度最高的詞匯，在各大互聯網公司掀起了一波波的熱潮，各家公司紛紛推出了自己的技術方案，其中作為全鏈路數字化技術與服務提供商的袋鼠云，在探索資料湖架構的早期，就調研并選用了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/?src=https://www.cnblogs.com/DTinsight/archive/2022/12/20/szbky
同時，歡迎對大資料開源專案有興趣的同學加入「袋鼠云開源框架釘釘技術qun」，交流最新開源技術資訊，qun號碼：30537511，專案地址：https://github.com/DTStack
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/540424.html
標籤：其他
下一篇：MySQL-執行計劃