點選上方藍字關註我們，了解更多內容

Amoro 是一個構建在 Apache Iceberg 等開放數據湖表格之上的湖倉管理系統，提供了一套可插拔的數據自最佳化機制和管理服務，旨在為使用者帶來開箱即用的湖倉使用體驗。

01 作者簡介

喻誌強 ，浙江電信大數據中心平台組負責人，擁有超10年電信行業資料倉儲和大數 據建設實施經驗。資深商業化 MPP 資料庫 Vertica 以及開源 MPP 資料庫 StarRocks-DBA。目前主要參與基於 Apache Iceberg 的湖倉一體方向架構以及開源 MPP 產品數據套用集市的建設實施。

02 Apache Iceberg 在浙江電信

為什麽選擇 Iceberg

浙江電信大數據中心主要負責電信的業務數據匯聚和數倉生產以及部份數據套用。 大數據架構革新到目前為止大體歷經三個階段 。

階段一：數倉改造 Hive 探索

隨著大數據體系的叠代我們開始構建以 Hive 為基礎的即時經分大數據系統，同步探索數倉改造至 Hive 的可行性，但在轉向 Hive 後我們遇到了以下問題：

基於以上因素，數倉暫停了改造 Hive 的過程，轉回尋找更加物美價廉的商業化 MPP 產品了（主要從原 MPP 行式儲存瓶頸著手，引入基於 x86 架構的列式儲存 MPP 資料庫）。已構建完成的大數據集群同步基於 Hive 探索承接部份時效性要求不高的數據套用任務。數據寫入 Hive 流程如下：

這裏導數工具主要由本地采集團隊透過 java 開發，定期透過存取 Oracle 從庫抽取生成格式化的文字檔案後寫入 Hive。從而完成業務數據到數倉數據的同步。該方式的一大基礎是 Oracle 從庫的讀取效能保證並且不影響業務系統庫的使用，但同時定期觸發的方式也註定了 Hive 中的數據時效性是比較差的。

階段二：業務系統上雲引起後端數倉以及套用系統的架構調整

後續隨著浙江電信開啟系統上雲任務，業務系統庫逐步從 Oracle 轉為 TeleDB （電信基於 MySQL 自研關系型資料庫），傳統的直接讀業務庫數據寫入數倉體系的數據流轉鏈路會對 TeleDB 業務庫造成很大的壓力。在這些問題的驅動下我們的數據鏈路也發生了變化。

在這裏導數工具主要采用了兩款產品，一款來自外部產品，其透過開源 Canal 技術進行封裝，後因該產品只做了 TeleDB 的適配，不滿足實際需求（生產後續引入了 TelePG（電信基於 postgresql 自研）資料庫），後又引入了電信自研的跨 IDC 同步工具，開啟了數倉 ODS 層從離線數據采集革新到即時數據采集，但經營分析大數據系統 Hive 數據時效性依然比較差。

階段三：重新思考大數據的方向，構建湖倉一體集群

生產系統上雲結束趨於穩定後，數倉和套用集市也開啟了系統上雲的步驟，我們重新思考大數據的定位和方向，將逐漸邊緣化的大數據集群考慮重構以支撐浙江電信全部業務系統數據即時匯聚、整合和數倉的重建。將原本使用的 CDH 集群進行了升級改造至電信自研的大數據底座版本。同步需要為湖倉的底座選擇可以支持數據即時寫入和即時讀取的一種 format。隨著現在數據湖技術的逐步成熟，也在集團鼓勵大數據團隊擁抱開源的背景下我們調研發現了數據湖產品可以很好的解決數據即時寫入讀取的問題。

透過對比 Hudi，Delta lake 和 Iceberg 後我們認為 Iceberg 在很好的支持 CDC 數據寫入的同時對流批引擎以及 MPP 資料庫的支持更豐富，可以根據不同業務分析場景選擇不同的引擎來滿足效能方面的需求，並且網易數據開發治理平台 EasyData（以下簡稱網易 EasyData）和有數 BI 對 Iceberg 也有很好的支持。最終我們選擇 Iceberg 作為我們新的 table format。

數據鏈路這裏也經歷了兩個階段 ：

Kafka 寫入 Iceberg 主要透過了網易 EasyData 即時開發 FlinkSQL 模組。但隨著原引入同步工具的保障性不足以及數據中台的引入，故而進行了數據鏈路的最佳化調整。

TeleDB 初期透過網易 EasyData 即時數據傳輸（基於 FlinkCDC）即時寫入 Iceberg，隨著上線任務量越來越大，發現了對電信自研資料庫 TeleDB 和 TelePG 適配的不完備問題，後期因計畫上線時間緊，我們團隊開啟了基於 FlinkCDC 能力自研數據入湖采集平台實作業務數據即時入湖，目前整體執行穩定，但資源最佳化和使用便捷性還需進一步開展研發。

業務實踐

我們團隊數據來源非常廣泛，包括了浙江電信 BMO 域以及其他系統的業務數據。在數據落入 ODS 層後進行 DWD 和 DWS 加工，後根據不同的業務分析場景需求（即時和離線報表）在有數平台生成各式各樣的報表，並且會將這些報表的內容嵌入到業務和分析人員日常使用的 Application 中供各營運節點使用。

報表的不同的使用場景決定了數據的響應速度，這也決定了我們需要使用不同的計算引擎。日常的自助分析我們透過 Spark 和 Trino 來支持對 Iceberg 報表的查詢，數倉生產層批次處理主要以離線為主，主要依賴 Spark，套用層對於響應速度要求較高的場景我們會采用 Doris 資料庫（catalog 直接存取 Iceberg 表），來支撐各類場景的需求。

使用情況

在確定了 Iceberg 作為數倉系統的 table format 後我們已將大部份 ODS 轉為 Iceberg，後續也會逐步將 DWD 和 DWS 轉為 Iceberg。

目前 Iceberg 表儲存總量1.1PB，預計所有數倉轉型完畢後預計會有10-15PB。其中即時寫入的 Iceberg CDC 表有近1萬張，預計初步轉變完成之後總共3-4萬張 Iceberg 表。

03 Amoro 在浙江電信

為什麽選擇 Amoro

即時寫入 Iceberg 表會產生大量小檔，尤其是為了保證數據的一致性，我們在很多場景中都開啟了 upsert 模式（該模式下每次寫入一條數據都會產生一條 insert 和一條 delete 數據），產生大量 equality-delete 檔，加劇了小檔的問題，也對查詢效能產生了較大影響，甚至引起引擎端 OOM。因此，及時監控並合並小檔、減少 equality-delete 檔，對保障 Iceberg 表的可用性十分重要。

進行 Iceberg 的檔合並時，我們主要遇到以下難點 ：

1. equality-delete 檔的合並效果不理想

我們使用了 Iceberg 社群提供的合並方式，周期性排程 Flink Spark 任務進行檔合並，這種透過重寫進行檔合並的方式，開銷比較大，幾百 G 數據的合並每次需要消耗幾小時甚至更久，而且合並完成後仍然可能出現 equality-delete 檔沒有被立即刪除的問題。

2. 大量積壓的 equality-delete 檔導致合並失敗

一旦沒有及時檢測到表的檔情況，或因為合並失敗導致 equality-delete 積壓，檔合並的 plan、記憶體消耗、讀寫開銷都很大，往往會因為 OOM、執行時間過久等問題，最終導致合並無法完成，只能重建表來恢復，大大增加了維護成本。

基於以上問題我們希望有一個成熟的系統可以幫助我們及時發現碎片檔多的表並且及時地去 optimize 這些表。透過調研我們發現 Amoro 可以很好的解決這個場景，並且 Amoro 提供了多種能力幫助我們更好的管理表的 optimizing ：

使用情況

我們在部署了 Amoro 後很快接入了所有 Iceberg 表，初期我們在部署偵錯階段做了大量的測試和驗證，同步最佳化 iceberg table 的建表方式（如分區的使用等），也非常感謝社群的大力支持。目前根據表的體量和業務我們一共切分了2個 optimizer group，總共資源使用78 core 776GB memory（相對更耗記憶體資源），已能穩定高效進行小檔管理和合並。

使用效果

Amoro 提供了高效穩定的合並

Amoro 提供了一種輕量的 Minor Optimizing 的方式，在合並小檔、避免重寫大檔的同時，將 equality-delete 檔轉化成查詢效能更高的 pos-delete 檔。這種合並方式相比 Iceberg 社群的檔合並方式，開銷更小，因此可以更加頻繁地執行，執行周期在分鐘級別，從而有效避免了小檔的積壓。

使用 Amoro 前，CDC 高頻寫入的 Iceberg表 equality-delete 檔數量經常保持在1000以上，單個 datafile 關聯的 equality-delete file 大小在5GB 以上。

使用 Amoro 後 Iceberg 表 equality-delete 和小檔數量保持在50以下。

Amoro 處理積壓的 equality-delete 檔

我們為所有 Iceberg 的表都開起了 upsert 配置後帶來的問題是 Iceberg 表中有大量的 equality-delete 檔，一旦出現 equality-delete 積壓的情況，很容易導致合並任務的 OOM。 這是因 為 ， 在 Iceberg plan task 機制中，datafi le 會關聯所有 sequence number 比自身大 的 equality-delet e file （ fil e 的 sequence number 預設情況下與 snapshot 的 sequence number 相等，snapshot 的 sequence number 會自增 ） 。 所以對於歷史快照送出的檔會參照很 多的 equality-delete file ，這些 equality-delete file 在 Iceberg MOR、以及文 件合並時都需要被讀取到記憶體中用於刪除關聯到的 datafile 中的數據，從而消耗大量記憶體。

針對以上問題， Amoro 社群在 optimizing 方面做出了最佳化 。在 upsert 場景中 datafile 關聯到的 equality-delete file 中的數據很多是和當前 datafile 沒有相關性的，所以其實讀到記憶體中的 equality-delete 中有大量無效內容，但他們卻占用了大量記憶體。另外 Amoro 在規劃 self-optimizing task 時可以透過配置 self-optimizing.max-task-size-bytes 配置來限制每個 task 中 datafile 檔大小，所以每個 task 的 datafile 大小是可以預期的，但是 equality-delete file 大小是不可預期的。那麽我們就可以使用 task 中 datafile 的內容來過濾掉不需要被緩存在記憶體中的 equality-delete records。

具體的實作方式是我們透過 task 中 datafile 的 equality field records 構建了一個 BloomFilter，透過這個 BloomFilter 篩選出與參與 self-optimizing datafile 相關聯的眾多 equality-delete 檔中 equality field data 與 datafile 有交叉的數據並載入到記憶體參與 MOR，顯著的減少了記憶體的使用，從而避免了 upsert 場景 equality-delete file 檔較多時導致 optimizer OOM。

04 未來規劃

最後再次感謝 Amoro 社群給予的大力支持，祝願 Amoro 社群越來越好。