Amoro：高效管理湖仓的开源解决方案

01
背景2022年8月网易开源了 Arctic 项目，2023年8月 Arctic 项目更名为 Amoro，并发布了最新的 0.5.0 版本。本文我将带领大家从 Amoro 的定位、场景与价值、核心实现等多个方面深入了解这个开源项目。
02
项目定位

Amoro 是什么？

"Amoro is a Lakehouse management system built on open data lake formats. Working with compute engines including Flink, Spark, and Trino, Amoro brings pluggable and self-managed features for Lakehouse to provide out-of-the-box data warehouse experience, and helps data platforms or products easily build infra-decoupled, stream-and-batch-fused and lake-native architecture."

首先 Amoro 是湖仓管理系统，这里我们借鉴了数据库管理系统的叫法，可能很多同学乍一听会觉得管理系统会类似于实时计算、离线开发一类的工具平台，这里我稍稍做个澄清：工具的目标是帮助用户更高效、便利地执行某种流程，而Amoro 的目标是将一些流程向用户屏蔽，交给用户一个黑盒，他的定位更多是一个基础软件，所以 Amoro 的 MS 类似于 DBMS 中的 MS，我们经常讲一句话：build a box for lakehouse。

这里抛砖引玉一下，我们经常在数据库和传统数仓中看到一些面向 information_schema 的标准化指令，Amoro 希望可以做 Lakehouse 的 information_schema，后续我们会尝试带动社区推进这块功能的标准化。

其次 Amoro 不像数据库和传统数仓一样是个纯粹地黑盒，它开放的特性可以很好地契合由开源技术栈构建的各种大数据平台和产品，帮助这些平台快速上手 Iceberg 这类新型数据湖 format，体现湖原生数仓、湖仓一体的业务价值，所以它既可面向数仓用户，也可以面向平台开发者，在我们的社区实践中，后者的比例是占大头的。

03
场景与价值湖原生数仓
当我们使用数据库，或者如 TeraData、GP 一类的 MPP 数仓，大家习惯于把他们当做一个黑盒，用标准的 SQL 或工具来使用数据，当我们把技术栈切到数据湖，会发现大家似乎习惯于把工作拆成一个个模块：数据加工，ETL 用 Spark/Flink，数据分析用 Trino、Presto 和 Impala，相比传统数仓，数据湖开放的特性和生态给业务带来了超大规模的扩展性、伸缩性和相对可控的成本，但也丧失了传统数据库和数仓开箱即用的特性。对此我们的工程师可能会想很多办法，比如自己开发一个定时调度的数据优化平台，或者把数据 layout 优化的工作直接丢给用户，这个谁用谁知道，把原先数据库和数仓内部极其复杂的数据合并和优化规则交给业务平台去做，这基本是一项不可能做好的事情，尤其当你想用新的数据湖 format 统一实时和离线数仓，数据的优化规则可能需要翻天覆地的变化。在我们和业务共创的过程中，我们看到了大量这样的需求：业务希望用一套数据湖技术栈，同时做离线数仓和实时数仓，数据可能实时摄取，也可能离线写入。既想要数据湖的低成本，高弹性，可以使用成套的数据湖工具（大数据平台），也可以有传统数据库和数仓黑盒使用的体验，业务只管使用数据：我们将这种场景命名为湖原生数仓，湖是新型的数据湖 format，能够为业务带来 ACID，流批统一等特性，数仓强调开箱即用，自管理和自优化的能力，我们希望通过 Amoro 结合数据湖 format 实现湖原生数仓的愿景。湖原生数仓本质上是 Lakehouse（虽然这个概念足够通用，但不得不承认，当我跟另一位同学讲 Lakehouse 的时候，很难说他想到的东西和我一样） 在数仓方向上的精准抽象，当我们说湖仓一体时，绝大多数场景讲的就是湖原生数仓。流式 pipeline对实时业务，过去大部分实践是从数据源到数仓定义一个独立的 ETL 任务，随着业务对数据时效性越来越重视，大家开始研究实时数仓和实时计算的体系化研发、数据分层、资产复用和数据治理。2018 年 Databricks 就提出用 Delta 架构实现流批架构的统一，即所谓的流批一体，而在流批一体之前，首先要做好流式的 pipeline，再将批的选择权交给用户：流式 pipeline 需要用的技术有 Incremental query、CDC、基于湖的维表 join，基于湖的多流 join等。CDC 和增量读是相对成熟的功能，但基于湖做多表关联，解决引擎大状态问题，这是个湖与引擎高度耦合的功能，我们认为整个行业在这块的成熟度还有所不足，尤其在超大规模数据的场景下，需要 case by case 地解决问题。对流式 pipeline 的场景，Amoro 提供了一套 Mixed format，可以更好地应对 CDC，毫秒级 pipeline 的需求，同时在 Self-optimizing 和 Merge-on-read 方面提供了基于 bucket 的性能优化，其中 Mixed Hive 能够额外提供 Hive 原生读写的功能，感兴趣的同学可以参阅：https://amoro.netease.com/docs/latest/formats-overview/未来 Amoro 希望通过对接不同数据湖 format 来探索这个场景的更多可能性，比如目前社区已经在推进和 Paimon 的集成，我们有理由相信 Paimon 在流式场景下可以给用户带来更多惊喜。云原生数仓
数据湖 format 技术在国内讨论更多的是 CDC，流批一体这样的场景，立项之初这也是 Amoro 主要关注的点。但熟悉 Iceberg 的同学可能知道，Iceberg 诞生的重要背景之一，是面向 AWS S3 构建数仓的需求，Hive 在对象存储之上有诸多不足，在 Iceberg 之上都有得到妥善解决，技术点这里不多做讨论。云原生数仓可以认为是纯粹面向对象存储的数仓方案，业务往往会选择一个全新的技术栈，比如用 Iceberg 代替 Hive，用 AWS Glue 代替 HMS，而 Amoro 提供的 AMS 实现了 Iceberg 的 Restful catalog 接口；提供了数据自管理和优化的特性；提供了时效性、性能、成本的度量和管理功能，能够在云原生数仓的场景下作为 Iceberg 的最佳伴侣来使用。

04
核心实现

Self-optimizing

为了满足湖原生数仓场景的需求，Amoro 引入了一套 self-optimizing 机制，目标是基于新型数据湖表格式打造像数据库，传统数仓一样开箱即用的流式湖仓服务，Self-optimizing 包含但不限于文件合并，去重，排序，孤儿文件和过期快照的清理。

Self-optimizing 的架构与工作机制如下：

AMS (Arctic Management Service) 是 Amoro 的中心管理服务，它负责规划所有表的 self-optimizing 任务，并将任务下发给下面的 Optimizer 执行。Optimizer 是 self-optimizing 的执行组件，收到优化任务后负责具体的任务执行过程，最后再将执行结果上报给 AMS 后进行提交。Amoro 通过 Optimizer Group 对 Optimizers 实现物理隔离。

Amoro 的 self-optimizing 的核心特性有：

• 自动、异步与透明：后台持续检测文件变化，异步分布式执行优化任务，对用户透明无感
• 资源隔离和共享：允许资源在表级隔离和共享，以及设置资源配额
• 灵活可扩展的部署方式：执行节点支持多种部署方式，便捷的扩缩容

然而频繁的对表里的文件进行优化会消耗过多的资源，而如果不及时进行文件优化又会造成表上查询性能的下降。为了权衡资源开销与查询性能，Amoro 将文件优化任务进行了进一步的细分。

Amoro 将表中的文件按照大小分为了两类：

• Fragment File：碎片文件，默认配置下小于 16 MB 的文件，此类文件需要及时得合并成更大的文件，以提升读取性能
• Segment File：默认配置下大于 16MB 的文件，此类文件已经具备一定的大小，但还不到理想的 128MB。

基于以上的文件分类，Amoro 将文件优化任务分为以下三类：

类型	定义	目标	任务大小	调度频率
Minor Optimizing	在 Fragment File 上的优化任务。	降低文件碎片，将写友好的文件转换为读友好的文件。	较小（比如 16MB）	非常频繁（比如每5分钟一次）
Major Optimizing	在 Segment File 上的优化任务。	将文件大小推进到目标大小，并减少冗余数据。	中等（比如128MB）	较频繁（比如每1小时一次）
Full Optimizing	表或者分区内所有文件上的优化任务。	将所有文件全局排序后重写。	取决于表或分区的大小	不频繁（比如每天一次）

具体来说，对于 Iceberg 格式的表，Minor optimizing 会将小于16MB的 insert File 合并到大于16MB，并将equality-delete file 转换为 position-delete file，转换过程中会为每个 insert file 生成对应的 position-delete file，并将已有的 position-delete file数据合并到新的 position-delete file内，具体过程如下：

而 Major optimizing 则会将那些已经积攒了较大的 position-delete file 的 insert file 与其对应的 delete file 进行合并而消除其冗余数据。Full optimizing 会将所有的文件进行重写，重写过程会消除掉多有的 delete file。具体过程如下：

Multiple formats

为了满足用户在不同场景下对数据湖的不同需求，Amoro 支持多种表格式，并在之上构建统一的管理能力。当前支持的表格式包括：

• Iceberg Format: 即 Apache Iceberg 原生表格式，用户可以把自己已有的 Iceberg 表导入 Amoro 集群，则可以利用 Amoro 自动管理和优化这些表，以提高表上的查询性能。同时表上已有的读写任务都不受影响。
• Mixed-Iceberg Format: 构建在 Iceberg 表格式之上的一种混合表格式，它在流式更新场景下做了诸多增强，包括 MOR 性能，流式读取，实时维表关联等。
• Mixed-Hive Format: 构建在 Iceberg 和 Hive 表格式之上的一种混合表格式，拥有和 Mixed-Iceberg 表一样的能力，同时支持直接从已有的 Hive 表升级而来，且兼容已有 Hive 表的读写任务。

以流式 Pipeline 场景为例，如果源端数据是来自像日志这样的 append-only 数据，使用 Iceberg Format 即可很好的满足需求。但是如果源端数据是来自数据库 CDC 这样带有更新和删除操作的数据，当前 Iceberg Format 还没法很好得满足这种场景下的实时 Pipeline 构建，而使用 Mixed-Iceberg Format 则可以较好得满足这种场景。Mixed-Iceberg Format 的结构如下：

Mixed-Iceberg Format 由3部分组成：

LogStore: 可选的实时数据的秒级缓冲层。一般为 Kafka 这类消息队列上的一个 topic，在实时 pipeline 构建中用来提秒级延迟数据的读取能力。

ChangeStore: 实时数据的存储层。为一张单独的 Iceberg 表，实时的 CDC 数据会以 append 的形式写入以提供最高效的写入能力。可以用来进行数据分析，同时也能为下游实时 pipleline 任务提供分钟级延迟的流式数据。

BaseStore: 存量数据的存储层。为一张单独的 Iceberg 表，ChangeStore 中的数据定期会通过 optimizing 任务去重后重写入 BaseStore。通常用来进行表上的数据分析。

Mixed-Hive Format 的结构与 Mixed-Iceberg Format 类似，只是 BaseStore 换成了已经存在的 Hive 表，这样就能帮助已有的 Hive 表快速升级成一张新型的数据湖表，提供更强大的流批统一的读写能力。

05
总结

Amoro 定位是建立在 Apache Iceberg 这类开源数据湖表格式上的湖仓管理系统，它通过 Self-optimizing、Multiple formats 等技术帮助用户基于数据湖快速构建出湖原生数仓、流式 pipeline 建设、云原生数仓等场景。

Amoro 社区成立一年以来，已有20+ 个来自不同企业的开发者参与贡献，产生了 10+ 个生产用户案例。如果你刚好需要 Amoro 提供的能力，或者想参与到一个湖仓项目的开源开发中来，或者只是单纯对数据湖、湖仓一体这个方向感兴趣，我们都非常欢迎你加入 Amoro 社区。

最后欢迎大家试用 Amoro 0.5.0，社区 Mentor 一对一解答试用过程中遇到的问题，我们还为每位参与试用的小伙伴准备了社区周边小礼品。

END

看到这里记得关注、点赞、转发 一键三连哦~

精彩回顾：
Amoro 0.5.0 版本发布，邀测开启试用有礼
从 Arctic 到 Amoro：我们的开源旅程和愿景Apache Iceberg + Arctic 构建云原生湖仓实战企查查基于 Apache Iceberg 与 Arctic 构建实时湖仓实践
关于 Amoro 的更多资讯可查看：官网：https://amoro.netease.com/源码：https://github.com/NetEase/amoro社群：后台回复【社群】或扫描下方二维码↓，邀你进群

点击下方【阅读原文】直达 Amoro 官网