出品社區｜DataFun
分享嘉賓｜張永翔 網易數帆 資深平臺開發工程師

1.云原生湖倉背景與挑戰

湖倉一體的發展經歷了從數據倉庫到數據湖，最終到湖倉一體的過程。傳統的數倉針對的是結構化數據，面向特定的分析或者報表場景，提供標準的 SQL 與標準的服務。隨著業務規模的擴大，復雜性提升，對于半結構化、非結構化的數據存儲和處理的需求涌現，催生了數據湖技術的發展。數據湖是在廉價的存儲系統上，使用各種工具，滿足各種數據類型的業務需求。這種非標準化的處理帶來了管理成本和開發成本的上升。湖倉一體順應而生，它是基于數據服務技術開發的廉價的系統，同時能夠構建結構化數據的處理能力。

湖倉一體的主要特點滿足了人們對它的期望，可以歸納為四點：

• 低成本存儲。不僅可以降低數據存儲的成本，另一方面也可以消除數據孤島，比如同時滿足流式場景和非流的場景，能夠在一個沒有數據孤島的體系下使用不同的數倉來處理不同的業務。
• 結構化數據處理。需要提供如 schema 變更時的安全的結構定義和演進，并保障安全的數據讀寫與隔離。
• 開放式計算架構。原有的數據倉庫計算場景比較單一，主要是 MPP 計算架構，而現在需要支持如流式計算、圖計算等多樣的計算引擎來滿足不同類型的計算場景的需求。
• 標準化度量。一方面是數據的標準的訪問，可以像傳統數倉一樣通過 SQL 對數據進行標準化的訪問，同時也提供對 catalog、服務權限控制等標準化的數據管理。

基于云構建湖倉一體 的 主要優勢 有兩大方面：

• 一是 性價比，上云的目標是降本，云上提供了廉價且可靠的存儲服務，數據湖技術基于廉價的存儲系統，云上對象存儲服務是最適合構建數據湖的存儲系統。
• 二是 靈活性，彈性擴縮容 是云的核心特性，無需提前采購，根據需求靈活擴縮容是云上的常見用法，數據湖技術要求存算分離，業務計算任務根據需求可以靈活擴容，天然適合云原生架構。

構建湖倉一體也面臨著 諸多挑戰，比如：

• Hadoop 體系上云，存算合一架構資源利用率不高，DataNode 節點無法快速擴縮容；
• 對象存儲服務通常無法提供完整的 HDFS 語義，兼容 HDFS 協議可能需要引入額外組件帶來額外的運維成本；
• 云上計算集群更偏向 K8s 集群，從 Yarn 到 K8s 切換需要有一定實踐經驗；
• 元數據中心上云也面臨著挑戰，云廠商會提供自己的元數據中心，不一定與 Hive 兼容；
• 云廠商提供的部分服務為非標服務，可能存在與某個云廠家綁定的風險。

2.Apache Iceberg 、Amoro 與云原生

2.1 Apache Iceberg

Apache Iceberg 是數據湖上的 開放表格式，它具有以下特點：

Apache Iceberg 本身的特性貼合云原生。

首先，Apache Iceberg 使用去中心化的元數據組織。采用 Metadata file 索引數據文件，并且在元數據文件中記錄了數據文件的 Metric 信息，以提供高效的 File Skip。不同于傳統 Hive 采用一個中心化的方式來去處理這些元數據。Metadata 文件和數據文件一起存儲到數據湖中，這使得 Iceberg 可以輕松地彈性擴展。

其次，Iceberg 不依賴于 HDFS 的存儲層抽象。Iceberg 對于數據文件和 Metadata 文件的訪問進行了抽象，使其避免依賴于某種存儲系統（比如 Hadoop）的實現，這使得 Iceberg 可以輕松對接各種云商的對象存儲系統。

lceberg 定義了一套開放的 Catalog 接口。通過標準的 Catalog 接口對接外部的元數據，使得 Iceberg 可以輕易對接 Hive 以及各種云上的元數據服務。

Iceberg 還定義了標準的 Rest Catalog API，提供了 Rest Catalog API 的服務可以零成本地接入 Iceberg。

2.2 Amoro 簡介

Amoro 定位為 基于開放湖表格式的湖倉一體管理系統。首先，它是基于開放的數據庫表格式，Amoro 本身并不是一種表格式，而是構建在 Iceberg 等數據湖格式之上的 管理系統。其次，Amoro 提供了很多可插拔的組件，如 元數據中心、調度管理系統、pipeline 優化 等。構建了與基礎設施無關的一種服務，底層也并不去綁定某種特定的技術或者云廠商。Amoro 是為了在云上提供一種與基礎設施無關的標準化的湖倉一體化管理系統。

Amoro 的 核心功能 是 Catalog Services。$0.5$ 版本里面提供了 internal Catalog 和 external Catalog 兩種類型。符合 Iceberg Rest Catalog API 接口的 Internal Catalog 服務，在云上部署時可以直接使用 Amoro 服務作為元數據中心。同時具有對接外部 catalog 服務的能力。如果業務有集成 EMR 的需求，業務根據需要將 Iceberg 表注冊到任意外部元數據中心，Amoro 均可與其對接，并進行 Iceberg 表的管理。

Amoro 另一個核心功能是 Self-Optimizing。流計算場景下，數據湖表的治理成為核心需求。隨著流式寫入，它必然帶來小文件問題，進而帶來查詢的性能問題，甚至有可能因為小文件或者 delete 文件太多，造成表不可用。Amoro 數據湖表提供了開箱即用的治理的能力。Amoro 會自動發現注冊在 Catalog 中的數據湖表，自動地持續地去監測數據服務表的小文件以及 data 文件的數量，然后對整個表中的文件數據量進行評估，自動根據優先級優化任務調度，達到開箱即用的對數據湖表的文件治理。

Self-Optimizing 的機制如下圖所示，依據 iceberg 表，將文件劃分為 fragment 區域和 segment 區域。Amoro 根據 target-size 和 fragment-ratio 將文件劃分為 fragment files 和 segment files。

當 target-size 為 $128mb$ 時，fragment-ratio 設置為 $8$，就認為是 $128mb$ 的 $1/8$，也就是 $16mb$。小于 $16mb$ 的文件，我們認為它是屬于 fragment file，而大于 $16mb$ 的則認為是 segment file。在流式寫入的場景中，頻繁寫入的文件通常都是比較小，需要頻繁的 commit，這些都屬于 fragment files。下面是兩種文件的特點：

• Fragment files
  • 新寫入的文件，碎片較小
  • 關聯了大量 eq-delete 文件
  • 對查詢性能影響大，需要優先合并
• Segement files
  • 初步合并后的文件，碎片化不嚴重
  • 通常只關聯 pos-delete 文件
  • 對查詢性能影響較小

Amoro 中，Self Optimizing 分成三種類型：Minor optimize，Major optimize 和 Full optimize。

• Minor optimize 是從 fragment file 到 segment file 的轉換，把碎片化的小文件轉換成非碎片化的文件，合并成大于 16mb 的文件，同時最重要的是做出了這種 eq-delete 操作，它會使 segment file 上面只關聯 pos-delete。大幅提升了 Iceberg 表的查詢效率。
• Major optimize 是做 segment file 內部的轉化，部分消除 pos-delete 文件，進一步去碎片化。
• Full optimize 是一種特殊的 optimize 類型，它根據用戶的配置，比如一天執行一次，會直接把表上的文件合并成期望的 target-size 設置的大小，最終會消除所有的 delete 文件，全部轉成 data file。

Self Optimizing 是自動的、異步的、長期存在的操作，必然會牽涉到資源的管理問題。Optimizing 資源管理是 基于 Group 的資源隔離和共享。Amoro 本身有一個角色 AMS（Amoro Management Service），會對 Optimizing 計算資源進行管理，Amoro 將 Optimizing 的計算資源通過 Optimizer group 劃分。通過設置表上 properties self-optimizing.group，每個 Iceberg 表均屬于某個 group。Group 間計算資源相互隔離，互不影響。Group 內部，通過 Quota 分配每個表可以占有的計算資源比例，達到計算資源在不同表之間的隔離或者共享。

Self Optimizing 定義了插件式的 Optimizer Container，輕松擴展各種類型的計算集群。它本身是一個抽象框架，內置實現了 Local Container 和 Flink Container。

• Local Container 是本地的基于 JVM 進程的一個 optimize 的進程。
• Flink Container 是以 Flink 任務的方式去提交，可以當作一個 Flink 集群來使用。
• Self Optimizing 實現了 Yarn 和 K8s 兩種最通用的計算集群。同時 Self Optimizing 還提供了 External Container，可以通過外部注冊的方式，向 AMS 直接注冊用戶自定義的計算集群類型。
• Optimizer 還支持彈性擴容，提交新的 optimizer 即可擴容 group 下的并發能力。

Amoro 提供了可視化的 Web 管理平臺，方便管理員輕松管理 Table、Resource 等資源和 Optimizing 任務。

最后，針對前文中提到的建設云原生湖倉的挑戰，總結出了 Amoro 和 Apache Iceberg 解決方案的優勢。

3.Apache Iceberg + Amoro 云原生實踐

3.1 云上湖倉案例一

下面介紹網易的一個實踐案例，它是網易內部的一個出海業務，出于合規性的要求，需要上 AWS。對原本基于 Hive 的湖倉體系進行改造上云。在改造前為典型的 Hadoop + Hive 架構，計算依賴于 Hive SQL，Yarn 作為整個平臺的計算集群，數據存儲在 HDFS 集群中，HMS 為元數據中心。

改造完成了原有 Hive SQL 任務到 Spark SQL 任務的遷移。將計算集群從 Yarn 遷移到了 AWS EKS 集群，通過 Spark 適配 K8s 集群，充分利用彈性計算資源，并在 S3 上搭建 Alluxio 集群適配 HDFS 接口。新接入業務使用了 Iceberg 表，并使用 HMS 充當元數據中心。同時，使用 Amoro 負責對 Iceberg 湖表進行持續優化，并通過 Flink Optimizer 適配 K8s 集群。

3.2 云上湖倉案例二

第二個案例為某外企，基于 AWS S3 + Iceberg 構建湖倉一體。原有架構是基于 Iceberg + S3 直接構建湖倉一體，采用 AWS Glue 為元數據中心，融合 AWS EMR 系統。AWS EKS 為計算集群，構建彈性計算集群。在這里使用 Amoro 的AMS 對湖表進行管理和持續優化，通過發揮 Iceberg 直接對接 S3 的優勢，減少了 Hadoop 體系的維護成本。

3.3 云上湖倉案例三

第三個案例使用 Amoro AMS 做元數據中心，采用 S3 + Iceberg 構建湖倉一體。在這個案例中通過 Iceberg Rest Catalog 與 Amoro AMS 對接。計算集群保持不變繼續使用 AWS EKS 構建彈性計算集群。Amoro 既作為湖倉的元數據中心，也實現了對 optimizer 的管理。

4.Amoro 未來發展規劃

最后，分享一下 Amoro 的未來規劃。

• 首先，將會支持更多的數據湖格式，如 Paimon、Hudi 等。
• 第二，是 提供動態的 optimize 調度的能力，除了當前的 Full optimizing 以外，未來還會支持基于 Order 的 optimizing，會提供以 batch 的方式去運行的能力。
• 第三，Amoro 將 提供標準的命令工具，在數據湖上提供標準的源數據訪問方式，可以對各種類型的數據圖表進行統一的查看和運維指令的接入。
• 最后，Amoro 計劃做 統一權限模型，會適配 Ranger 和 AWS，或者國內其它云廠商的權限系統，提供統一的元數據和運維指令接口。