Apache Iceberg + Amoro 构建云原生湖仓实战

01 摘要

本文将系统的介绍云原生湖仓（cloud native lakehouse）的概念，阐述基于云平台构建云原生湖仓的优势和挑战。云原生湖仓可以更好地利用云平台本身的弹性扩缩容，低成本存储、以及运维成本低的特性。

Amoro 是构建在数据湖之上的开源湖仓管理系统，提供一系列可插拔组件的功能组件和自我管理的能力，提供开箱即用的湖仓体验，帮助数据平台或数据产品构建基础设施无关，流批融合的湖原生架构。

02 什么是湖仓一体

湖仓一体是一种结合了数据湖和数据仓库技术的新型的数据处理架构。数仓技术自诞生以来其主要处理的都是结构化数据，然而最近几年随着流计算，AI，机器学习等新兴业务的不断发展，催生了对与半结构化数据、非结构化数据以及具有高多样性的数据处理的需求，面对这些场景，传统数仓并不适用。在这种背景下，企业需要一种集中式的存储系统，用于保存、处理大量的结构化、半结构化和非结构化数据，这种集中式的存储系统以及相关的数据处理技术被称为数据湖（Data Lake）。

由于数据湖天然的开放性，以及低廉的存储价格，业界开始尝试基于数据湖构建面向结构化数据处理的方案，以实现在一个统一个存储系统上容纳不同分析产品和工作负载的数据，Hive 就是这种背景下的成果之一。然而数据湖对于一些关键特性的缺失，比如不支持事物，缺乏一致性/隔离性等导致其几乎无法同时处理读取和写入，批处理和流计算。为了满足不同业务的复杂的计算需求，一个解决方案是并行的使用多个系统，比如使用 Hive 处理批处理作业，使用 Kafka 和 Kudu 处理流作业等。过多的系统带来了不必要的复杂性、成本以及数据孤岛等问题。在这种背景下，业界急需新的技术方案以补齐数据湖缺失的特性，并构建面向流批统一的数仓。

在谈到湖仓一体时，往往会提到 Iceberg、Hudi、Dalta 等项目，这些数据湖表项目有着以下共同特性：

• 支持 ACID：对于 ACID 的支持使得不同的计算任务可以并发的处理数据，不同的计算任务可以自由的对数据进行读写而不用担心破坏数据的一致性。

• 支持结构演进：相比 Hive 中对于表定义的粗糙管理，新兴的湖表格可以安全的进行结构变更而不破坏数据的约束以及一致性。

• 高效的更新/删除能力：相比 Hive 只能支持追加写（Append）和分区覆盖（Overwrite），新兴的数据湖表可以高效的对部分数据进行修改，这极大的提高了业务对于数据处理的灵活性。

• 更好的支持流：相比 Hive 几乎只能应用了批场景下，数据湖表对流计算的支持更加完善，流计算目前在企业数据处理中占据着非常重要的地位，对流计算的支持消除了需要构建单独的系统以用于实时数据处理的需求，有助于数据孤岛的消除。

• OLAP 查询的支持：对于 Hive 来说，数据的查询效率极大的依赖于数据是如何写入的，面对灵活且复杂的 OLAP 查询显得力不从心，因此在有 OLAP 或者 BI 需求的场景下，往往需要将 Hive 数据引入别的系统来提供给数据应用。数据湖表提供了 File Sikp 能力极大优化在复杂查询条件下的性能，对 OLAP 查询的支持同样有助于消除数据孤岛。

• 数据回溯：数据回溯功能提供了访问历史版本数据的能力，这对于数据回滚，AI 训练等场景十分重要.

从计算层面来看，这些数据湖表似乎已经解决了在数据湖上高效的处理结构化数据的需求，并在一定程度上实现了流批融合，但是只依靠数据湖表，生产可用的流批统一的湖上数仓还有一定的距离。相比一个生产可以的湖上数仓，数据湖表还缺失一些特性：

• 元数据目录（Catalog）：传统的数仓均提供了统一的表的元数据管理能力，通过一个中心化的服务，可以轻易的管理大量的表。而目前数据湖表技术缺乏这种能力，通常这些湖表需要依赖其他的元数据服务（比如 Hive）来进行统一的元数据管理。

• 表的持续优化能力：由于湖表提供了流批融合的能力，流计算任务持续写入的特性必然导致小文件和文件碎片问题，因此需要持续不断的对数据进行优化以满足最佳的查询性能。有些湖表格式（比如 Hudi）提供了在流式写入时优化的能力来解决这个问题，但是这种模式必然对写入性能产生影响。所以湖表基本都提供了通过触发批任务来对表进行优化的方案，然而由于湖表格式在设计上天然的去中心化，导致优化任务缺乏的统一管理。

• 统一的访问方式：不同格式的湖表在不同领域提供了不同的特性，在生产中可能需要联合不同格式的湖表以应对不同类型的问题，（比如 Iceberg 在批处理和 AI 学习的场景提供了丰富的支持，而 Hudi 则在 CDC 和有主键场景提供了比较好的支持）目前各种湖表均提供了独立的 connector 用于访问各自的表格式，如果想在一个任务中实现不同类型的湖表联邦，必须同时配置多个 Catalog，这对于数据的统一管理带来更多的挑战。

• 其他通用的功能：比如统一的权限管理，数据血缘等功能

因此，在构建湖仓一体时，除了要选择合适的数据湖表格式，还需要有合适的管理平台才能构建生产可用的湖仓一体。

03 湖仓一体与云

在构建湖仓一体的实践中，往往与云计算相结合，这是因为湖仓的很多关键特性与云计算的特性匹配。

• Lakehouse 构建在廉价且高可靠的存储上，而对象存储作为云计算的基础服务之一，天然就是廉价且高可靠的。

• Lakehouse 存算分离的架构使得业务可以根据需求扩展计算或存储资源，而弹性扩缩容是云计算的核心能力。

此外，云还极大的减少了运维部署成本，在云上，无论是机器采购、新服务部署、新机房部署，在时效性和运维成本上都是远远小于云下的。在构建湖仓一体的过程中，充分利用云的特性进行技术选型，面向云计算技术设计的湖仓一体架构被称为云原生湖仓（Cloude Native Lakehouse）。

虽然云原生湖仓在理论上十分美好，但是从传统的企业数仓转型到云原生湖仓却面临着很多挑战，这些挑战有些来自于构建湖仓一体本身，有些来自于云环境与非云环境的差异。

• 存储系统的不兼容：云上数据湖通常是基于对象存储服务构建的，而云下数据湖一般采用 HDFS，HDFS 的 API 模型是面向 POSIX 兼容的文件系统设计的，而对象存储的 API 更加类似一种 KV 存储，有些语义的 API（比如 Rename 或 list）对象存储服务并不提供或无法保证类似 HDFS 一致的语义。

• 云数据管理问题：在数据湖构建过程中，由于存量数据和业务的问题，往往使用 Hive 做元数据中心以兼容原来的 Hive 计算任务，如果重头构建新的湖仓一体，使用 Hive 做元数据中心显得有些多余，而且由于 Hive 是强依赖于 HDFS 的，导致的云上部署时必须提供 HDFS 的部署方案才可以部署 Hive。因此在上云的过程中，很多企业会选择云厂商提供的元数据服务以减少部署和运维的成本，不过选择云厂商的元数据服务固然省心，但是企业在上云过程中通常又不愿意和某一家云厂商绑定太深，谁也不能保证未来不会迁移到其他的云上。

• 多云、混合云的问题：在云上实践的过程中，多云或者混合云的场景是很多企业会遇到的情况。比如对于跨国业务，可能在不同的国家会选择不同的云厂商提供基础设施，或者在上云的过程中，需要云上云下的业务共存一段时间因而出现混合部署的情况。在这类场景下，原生 Hive 这种元数据中心的能力显得有些不足，导致往往需要部署多套 Hive 才能解决，这不仅带来额外的部署运维成本，也无法对元数据进行统一的管理。

04 Apache Iceberg 适合云原生湖仓的特性

在构建云原生湖仓时间，对于数据湖表格式的选择需要更关注其在面向云场景下的能力，综合对比下来，Iceberg 是非常适合构建云原生湖仓的表格式。

• Iceberg 在实现上并不强依赖于 Hadoop API，其对存储层的抽象比较彻底，可以直接访问对象存储而不用经过 Hadoop API，在云上部署时可以减少不必要的依赖。Iceberg 已经适配了多个云厂商的对象存储，包括 AWS 的 S3，阿里云 OSS，Dell 的 ECS 等。

• Iceberg Catalog 抽象的也比较彻底，天然容易适配各种不同的元数据服务，除了 Hive 还适配了 AWS 的 Glue Catalog。Iceber