出品社区｜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，或者国内其它云厂商的权限系统，提供统一的元数据和运维指令接口。