流批一体数据湖的云原生挑战

摘要：回溯至 2022-2023 年间，数据湖尚属前沿技术概念；而时至 2025 年，历经行业的快速迭代与实践沉淀，数据湖已完成从技术创新到主流应用的蜕变。当前，无论是大型企业集团还是初创型企业，均在积极推进数据湖的落地应用，只是各公司的落地进程存在差异，部分头部企

导读本文将分享实时数据湖的重要性、云下环境与#云原生技术的融合，以及实时处理和#流批一体的融合体验。

主要包括以下几大部分：

1. 数据湖落地实践

2. 云上#数据湖挑战

3. 云原生湖产品化

4. 总结

5. Q&A

分享嘉宾｜李劲松阿里云数据湖平台负责人

编辑整理｜王文海

内容校对｜李瑶

出品社区｜DataFun

数据湖落地实践

回溯至 2022-2023 年间，数据湖尚属前沿技术概念；而时至 2025 年，历经行业的快速迭代与实践沉淀，数据湖已完成从技术创新到主流应用的蜕变。当前，无论是大型企业集团还是初创型企业，均在积极推进数据湖的落地应用，只是各公司的落地进程存在差异，部分头部企业已实现全域数据湖化转型。

在 2025 年的数字化转型浪潮中，数据湖已从企业技术选型的“可选项”跃升为“必答题”。其核心价值首要体现于实时数据库功能，相较于传统数据库，数据湖能够达成更实时的效果，通过流批一体架构，无缝融合实时流处理与批量处理能力。

传统架构下，企业往往并行部署独立的离线数仓系统与基于 Flink+Kafka 的实时处理体系，两者在数据处理链路与技术栈上相互割裂，难以融合。而数据湖依托 Iceberg、Hudi 等湖格式的原生技术特性，打破了离线批处理与实时流处理的边界，通过统一存储层与计算引擎的协同，实现了流批一体的融合处理范式。随着湖格式能力的不断完善，数据湖在数据治理、事务支持、查询优化等维度逐步向成熟数仓靠拢，有力推动了湖仓一体架构的持续发展。当下，围绕湖仓一体已涌现出众多技术体系，众多企业已成功构建了高性能的湖仓融合架构。

数据湖能够助力企业更好地实现上云。云具备一些显著特质：

其一为存储弹性：在云环境中，企业可选用 OSS 进行存储，这种存储方式近乎拥有无限制的存储空间；其二是计算弹性：可使用 ECS 来实现计算功能，ECS 具有很强的弹性。与在本地环境中管理集群时需操心机器数量增减、集群规模大小不同，在云上企业能轻松享受存储与计算所带来的弹性优势；其三是数据湖元数据：去年被认为是数据湖元数据的元年。在此之前，提及元数据，大家往往会想到 Hive Metastore Service（HMS）等。然而去年，诸如 DataBricks 开源的 Unity Catalog 以及 Snowflake 开源的 Polaris Catalog 等，这些 Catalog 与 Hive Metastore 完全无关，它们是专门针对湖格式设计的元数据方案，能够真正释放湖格式的潜力，让湖格式相关应用得以更好开展，而不再依赖以往相对陈旧的 Hive Metastore 等方式。其四是数据湖赋能 AI：最初提及数据湖与 AI 的关联时，很多人并不清楚二者究竟如何相关。到了 2025 年，湖格式、数据及元数据切实展现出诸多能力，能够为 AI 大模型训练提供支持。例如，元数据系统可管理非结构化文件，赋予结构化数据使用权限，并通过统一的元数据管理实现特定权限设置与版本化管理。这些举措让整个 AI 训练过程变得更加规范、体系化，使数据湖能够在 AI 领域发挥重要的赋能作用。

流式数据湖落地实践最普遍的场景就是流式日志入湖。以 Paimon 的无主键表为例，它支持流批一体，通过小文件合并机制，可将传统批处理链路改造为流式链路。这一改造过程中整体变化不大，却能显著提升数据处理的时效性。资源使用方面，若批处理任务运行 1 小时需 100CU 的资源，采用流式处理后，即便一天常驻运行，在资源优化配置的情况下，整体资源消耗与批处理模式基本持平，却能实现数据的实时流转与即时分析。

第二大场景是流式更新，这是 Paimon 的一个核心特性。例如，可以声明一个 Paimon 主键表，它支持流式更新，能将数据变更捕获（CDC）的数据写入其中，具备异步压缩（compaction）功能，还支持来自数据库、Kafka 的模式演进或整库同步的写入方式。

第三种实践方式是全链路流计算，这种方式更为激进，是在整个数据湖上进行全链路的流计算。Paimon 提供了丰富的存储引擎，结合变更日志生成器（Changelog-producer）产生变更日志，使数据能够在链路中逐级流动起来。这是 Paimon 最为核心且独特的机制。

总体而言，在流式数据湖领域，大家所采用的方案旨在构建一个实时、低成本且具备流批一体功能的统一架构数据湖。

如今，流式日志入湖基本已成为企业的标配，已在众多企业中落地实施。流式更新同样也在大部分企业中实现了落地应用，例如不少企业将 CDC 数据，或将 CDC 数据传输到 Kafka 后，写入数据湖。而全链路流计算，目前在少部分企业中实现了较好的落地。

接下来分享一些流式更新入湖方案。

第一种方案是创建一个 ODS（操作数据存储）镜像表。可以使用 Flink、CDC 工具，或者 Flink CDC 相关组件，通过合适的方式来进行数据同步。也可以使用 Flink 的相关功能，或者利用 DataStream API，将数据库或 Kafka中的数据，同步到预先声明的 Paimon 主键表中。

这是一个主键表，需要声明一个主键字段，并根据数据量设定合适的桶（bucket）数量，之后直接将数据写入即可。为了结合之前的批处理链路，可以在每天晚上调度 Spark 进行批处理到批处理的数据写入操作。具体来说，就是读取该主键表的当前状态，进行临时调度，然后通过 ETL（抽取、转换、加载）操作，将数据写入下游的非分区主页面，比如存储到 Paimon 或者 Hive 中。这种创建 ODS 镜像表的模式是流式更新中最简单且最常见的方式。

第二种流式更新方案与传统离线数仓相关。通常在离线数仓中存在分区，若希望查看数据库中某张表昨天及前天的状态，可以借助 Paimon 的标签（tag）能力。在流式更新过程中，定义 tag 的自动创建功能，或者自行编写脚本，每天凌晨生成一个 tag。这些 tag 类似于之前离线数仓的分区。随后，可以使用 Spark 以批处理的方式读取 tag，并依据读取到的 tag 数据进行下一步的 ETL 处理操作。此外，若有数据重刷的需求，也可以通过读取昨天、前天的 tag，来执行相应的逻辑处理。

第三种方案是采用明细表的形式。前两种方式存在一定局限性，会丢失一些明细数据。例如，若想要对数据库的每一条变更日志 change log 都进行相应计算，而通常一张 Paimon 主键表会对这些明细进行聚合处理，同一个主键只能呈现最后的状态，无法满足部分表对明细数据的需求。

针对这种情况，可以通过声明一张没有主键的 Paimon 分区表来解决。在这张分区表中声明几个关键字段，如 Operation time（操作时间）、Operation DT（操作数据时间）等，用于描述分区、更改内容和更改时间。接着声明一张 Paimon 追加（append）类型的桶（bucket）表，它类似起到队列的效果，并且能够将历史数据存储在各个分区中。

在下游处理时，每天完成一天的数据处理后，可启动 Spark 读取 Paimon 分区表中每天的增量数据，以进行下游的数据加工。也可以使用 Flink 对流式读取这张明细表，并将数据写入下游构建的类似进项表中。这种方式较为稳妥，能完整保存数据库 CDC 的所有明细，不会造成数据丢失。

以上就是目前流式更新主流落地方案。接下来探讨云上数据湖面临的一些挑战。

云上数据湖挑战

前文提到，去年是数据湖元数据的元年。在此之前是使用 Hive Metastore，当时存在诸多问题：

设计理念差异：Hive Metastore 是针对 Hive 设计的，与湖表理念存在很大差异。权限模型复杂：使用 Hive 时，权限模型几乎与软件绑定。尽管有 Ranger，但它非常复杂难用，很难对其进行修改以实现特殊的统一基于角色的访问控制（RBAC）权限模型，同时审计也较为麻烦。无法理解湖表概念：Hive Metastore 无法理解湖表相关概念，其对 Iceberg 等湖表的快照（snapshot）、分支（branch）等概念一无所知。Hive Metastore 的 100 个字段中，95 个是给 Hive 用的，仅有 5 个可与湖表共用，而这 95 个冗余代码的存在，使得优化和更改变得极为困难。难以扩展：Hive Metastore 的元数据很难扩展，例如难以满足湖与 AI 结合时对元数据的扩展需求。此外，Hive Metastore 系统已存在多年，Hive 社区大多还在使用 2.3 版本，部分升级到了 3.1 版本，而最新的 4.x 版本很少有人升级，基本处于停滞状态。

鉴于上述问题，去年 Snowflake 发布了专门针对 Iceberg 的 PolarisCatalog，Gravitino也有 Iceberg Catalog 的实现，Delta Lake 发布了 Unity Catalog。针对每个湖表的特性建立单独的元数据系统，已成为整个业界的发展趋势。

在使用 Paimon主键表、Iceberg 等技术时，面临着主键更新的难题，需要对成本与实时性进行权衡。以云上环境为例，对象存储存在请求费用和计算费用。同时，像 Paimon、Hudi、Iceberg 等都有桶（bucket）配置。例如 Paimon，若 bucket 数量配置过少，性能和吞吐量会跟不上；若配置过多，对象存储请求费用会大幅增加，成本高昂。此外，还有检查点（checkpoint）间隔的设置问题，对于业务而言，希望检查点间隔越小越好，成本也越低越好，因此如何配置合适的 bucket 个数就成为关键。

在主键表方面，数据压缩（compaction）也是一个问题。Paimon 结合 Flink Sink 有后台压缩功能，且可设置为纯异步，以尽量减少对写入的影响，但压缩仍可能导致数据更新不稳定。在线下非 K8S 环境中，由于没有 CPU 隔离，后台任务可能会争抢 CPU 资源；而在云上 K8S 环境中，CPU 使用受到限制，若内联压缩（inline compaction）消耗过多 CPU 资源，会对写入产生影响，若采用单独专用的压缩（dedicated compaction），则资源消耗大且难以调优，还需进行加锁等操作，过程较为繁琐。因此 compaction 成为了最大的拦路虎。

云原生湖产品化

当前，Paimon 社区正全力推进 REST API 的开发工作。其原理是将诸如获取表（get table）、加载（load）、创建表（create table）等所有操作，转化为 HTTP 协议，从官网示例来看使用较为简单。通过观察可以发现，Paimon的 REST API 有特定的前缀 URL，遵循 HTTP 定义的 REST 标准，其返回值具有明确规范。以“get table”操作为例，执行该操作时会直接返回 schema。对比之下，基于 Hive Metastore（HMS），“get table”操作后还需从文件系统获取 schema，这是因为 Hive Metastore 无法针对性地保存一些特殊内容。而 Paimon 的 REST API 是根据 Paimon 自身特点设计的，能返回 Paimon 所需的数据，从而进一步提升效率，优化服务使用方式。

此外，REST API 还有诸多优势：

其一，相关的软件开发工具包（SDK）完全开源、开放且标准化。在产品化过程中，可构建一个源（source）服务，即 REST 目录，并且能够依据 Paimon 官网标准，使用 REST SDK 在任何地方访问该服务，无需依赖其他复杂组件，将其真正当作一种服务来使用，避免了对繁琐且易变 API 的依赖，减少了访问限制。其二，REST API 天然具备更好的跨语言对接能力，无论是 C++ 还是 Python 等语言，都能通过 REST 轻松对接该目录。

如上图所示，在计算引擎端，通过 Paimon 开源开放的 REST API，以及 Paimon 提供的 FileIO SDK 来访问 REST Server。采用 REST HTTP 加 JSON 的方式，诸如提交表（commit table）、加载表（load tables）等操作都由 REST Server 负责管理。REST Server 中包含处理器（handler）和 RBAC 权限模型，其背后对应着 Metadata Database，可能是 MySQL 等数据库，这是专门为 REST Server 设计的一套元数据服务。整个计算集群和 REST Server 会对文件系统进行数据和元数据的读写操作。

这种架构带来的好处如下：

首先，利用 RBAC 实现了统一的权限模型，表提交由 REST Server 负责，它能自动解决冲突，避免了多线程导致的一致性问题。而且提交后，REST Server 能准确统计出所有信息，如当天快照（snapshot）的文件数量、数据条数、分区数量以及每个分区的数据条数等，这些信息都是最准确、实时的。其次，REST Server 自身具备管理分区、分支（branch）以及快照的功能。

在构建了这样一套专门的元数据服务后，能够实现数据与 AI 的统一管理，类似于 DataBricks 的 Unity Catalog，可以对 AI 相关的非结构化数据进行管理。从 Catalog 层次来看，REST Server 管理着数据库（database），数据库下又管理着表（table）以及文件目录等内容。同时，还支持视图（view），能够实现跨引擎、支持方言的视图函数，也支持模型（model）。

从本质上讲，大数据与 AI 的结合方式是将文件目录挂载到元数据中，提供一套类似文件系统的封装。这种虚拟的文件系统映射了真实的目录，在进行封装时，需要与元数据服务交互，进行权限设置、流量控制、血缘关系梳理等操作，从而使非结构化文件目录的操作也具备大数据中关于血缘和权限管理的能力，将对非结构化数据的使用统一整合到元数据服务中。

在此基础上，还可以进一步优化，比如在文件系统上进行版本化管理，这对于 AI 来说是非常必要的。总体而言，尽管大数据与 AI 的联系目前可能不是特别紧密，但元数据在其中能够为 AI 带来上述这些价值。

最后要分享的是自适应的数据压缩（compaction）管控。尽管之前提到数据压缩是个难题，但实际上它本身相对简单且可控，其操作主要只有读 Paimon 和写 Paimon 这两项，所以本质上是能够实现标准化和自动化的。

对于业务方而言，实际上不应该负责数据压缩的工作，而应将其直接托管给平台方或服务提供方。简单的业务操作留给自己，复杂的部分交给平台。业务方的需求很简单，即在固定的几分钟时间内，平台能用尽量少的资源完成数据压缩任务。

用户既不想关注数据压缩的稳定性，也不想操心桶（bucket）的配置。以 Paimon 为例，在其最新版本中提出了“Postpone Bucket”的概念。当桶的配置为 bucket = -2（因为-1已被占用）时，用户的流式作业数据会统一写入“Postpone Bucket”中。Paimon 及其背后的元数据产品后台服务会自动进行数据压缩和数据整合（rescale）操作，将“postpone bucket”中的临时数据写入最终真实分好桶的数据中。

自适应 compaction 管控使得用户不停止写入，后台自动进行 compaction和 rescale 操作，将临时数据写入最终分桶数据。用户下游仅看到分好桶的数据进行批读或流读，核心作业不受影响，仅可能有数据延迟。用户仅需关注数据时效性，而对作业管控不必关心。

实现中的技术要点包括，表提交后的通知机制、合理的分区粒度 compact、资源自动伸缩、对小表整库 compact、完整的报警监控，以及 native 读写优化以保证效率。社区中以往如 Iceberg、Hive 等的 compaction 相对 Paimon 更简单，Paimon 是 LSM 式 compaction，类似 HBase 中的相关操作，资源消耗大，但计算模式简单，为平台实现全自动 compaction 提供了机会。

对于平台方或服务提供商（如阿里云），要让用户信任后台 compaction，Paimon 专家需不断打磨后台 compaction 作业，先通过人工方式调优，总结经验，最终结合大模型和 AI 训练，实现真正以技术手段完成全自动的、高效的 compaction。

总结

数据湖的发展呈现出实时化、云上化趋势，同时在元数据方面不断演进，并加强了与 AI 的融合。这些是数据湖领域目前较为显著的发展方向。

在云上数据湖的实践中，面临着诸多挑战，包括元数据管理方面的难题，例如传统元数据系统难以适应湖表特性等问题；以及 compaction 管理的困境，如成本与性能的权衡、操作对写入的影响等。

当前重点聚焦于云上服务的产品化，涉及元数据的革新，深入探索元数据与 AI 的结合方式。同时，致力于实现自适应的 compaction 管控，通过解决这一关键问题，助力业务能够快速、大规模且批量地在云上部署和开展，推动数据湖在企业中的广泛应用。

Q&A

Q1：Paimon 对于大数据量级的 compaction 效果好吗？

A1：Paimon 对于大数据量级的 compaction 效果是好的，阿里集团内业务能够上线就是证明。目前遇到的最大规模有上千并发写入，每天的增量数据量达到百 TB 级别。但也存在一些调优挑战，比如 bucket 数量以及写入 compaction 相关资源大小等方面。

Q2：自动 compaction 需要消耗什么资源?

A2：从技术角度讲，自动 compaction 消耗的资源主要有几个维度。一是 CPU 资源，因为在操作中会读取 Parquet 文件和写入文件，这一过程会消耗 CPU；二是网络 IO 资源，文件读写会带来网络方面的消耗；三是本地磁盘资源。在未来的设计中，期望后台有一个无限的资源池（基于云），采用按量付费的方式。

Q3：现在有开源的 Paimon REST Server 吗？支持不同任务同时写入表的不同部分字段吗？

A3：目前 Paimon 内部的 REST Server 还在发展中，计划在比较成熟后，于今年下半年将其贡献到 Paimon 社区。对于不同任务同时写入表的不同部分字段这一情况是支持的，Paimon 社区的 partial update 功能就是用于实现该操作的。

Q4：Paimon 为什么自研 catalog 而不使用 Gravitino 等技术？

A4：Paimon 并非不想使用相关技术，而是 Paimon 社区之前没有开发出 REST API。目前社区正在进行这方面的工作，计划在 1.1 版本中彻底固化并发布 REST API。同时，也期望相关社区能够一起将 REST Server 建立起来，未来希望相关社区在下个版本中集成 Paimon 的 REST API 。

Q5：Paimon 和 Iceberg 的优劣势分别是什么，中等体量公司对于这两个技术是可以并行使用，还是要选定一个？

A5：如果是在阿里云上，建议直接选择 Paimon，因为阿里云在 Paimon 技术上有深厚的资源、人员及后台技术积累。若不在阿里云上，比如在腾讯云、华为云等其他云平台上，中等体量公司可以将 Paimon 和 Iceberg 这两个技术一起使用。Paimon 是在 Iceberg 基础上发展而来的，且提供了 Iceberg 兼容能力。若公司已经在使用 Iceberg，可以引入 Paimon 及其 Iceberg 兼容能力，利用 Paimon 产生快照来兼容 Iceberg，融入其生态。

以上就是本次分享的内容，谢谢大家。