Paimon 1.0: Unified Lake Format for Data + AI

摘要：本文整理自阿里云智能开源湖存储负责人李劲松在 Flink Forward Asia 2024 上海站主论坛上的演讲。演讲中提到，Apache Paimon 于今年 3 月份成功毕业成为 Apache 顶级项目，下一步计划发布 1.0 版本，期望达到 Unified Lake Format for Data + AI，解决数据处理与 AI 应用中的多个关键问题。Paimon 结合 Flink 打造 Streaming Lakehouse 解决方案，该方案已在阿里巴巴集团及多个行业中得到广泛应用。此外，来自淘天集团、抖音集团和 vivo 的嘉宾也参与了交流讨论，共同分享了基于 Paimon + Flink 技术栈实现的数据湖实时处理与分析的实践案例。本文内容主要分为以下四个部分：

一、大数据从业者工作中的痛点分析

二、基于痛点的解决方案

三、Paimon 的发展历程

四、大厂嘉宾分享交流经验

一、大数据从业者在工作中面临的问题有哪些？

第一个问题——实时性与成本控制的矛盾：随着业务对数据实时性的要求越来越高，如从天级响应时间缩短至秒级甚至毫秒级，企业通过采用诸如 Flink 等技术来构建实时数据处理链路。然而，在当前强调成本效益的大环境下，老板不仅希望进一步提升数据处理的速度，同时还期望减少相应的开支。这就给团队带来了既要提高效率又要降低成本的双重挑战。

第二个问题——技术栈复杂度增加导致的成本上升：近年来，多种新型大数据框架不断涌现，虽然为解决特定问题提供了更多选择，但也使得整个数据生态系统变得更加复杂。频繁的数据迁移、开发难度大以及高昂的维护费用等问题接踵而至，形成了所谓的“数据沼泽”。这种情况下，不仅增加了项目的实施难度，还大幅提高了总体运营成本。

第三个问题——如何有效结合 AI 技术：面对当下生成式人工智能领域的快速发展，咱们从事大数据工作者如何将自身领域与 AI 技术相结合，融入 AI 基础设施当中。

二、如何解决以上这三个问题？

李劲松（阿里云智能开源湖存储负责人）提出用 Paimon 来构建统一数据湖存储架构解决这些问题

**第一，**通过 Flink + Paimon 构建的流式湖仓，在保证较低运营成本的同时，还能有效加速离线数据处理的速度。这种方式既满足了对成本控制的需求，也达到了提高数据处理效率的目的。

**第二，**Paimon 作为一个支持流处理、批处理及 OLAP（在线分析处理）的统一存储解决方案，能够将所有类型的数据集中存放在一个“数据湖”中，这样的设计使得不同类型的计算引擎可以直接访问同一份数据源进行各自的应用场景开发，从而避免了因数据迁移而产生的额外开销或延迟问题。

**第三，**数据湖比较适合与 AI 相结合，特别是当涉及到非结构化数据时，Paimon 提供了 Python API 和 Object Table 来更好地管理和利用这类数据，从而为 AI 模型训练提供坚实的基础支撑。

三、为什么选择 Paimon ？

Paimon 在过去一年里经历了显著的发展，成为中文社区中最受欢迎的湖格式存储系统。它被广泛应用于各企业中，尤其是与上万个 Flink 流作业结合使用，以提高业务处理的时效性。此外，新增了数百家企业开始采用 Paimon 技术，技术持续创新增加了 100 多项新功能，并吸引了超过 200 位贡献者参与到开源项目中来，共同推动 Paimon 的进步。至今为止，Paimon 已收到超过 3000 份 PR，显示出极高的社区活跃度。当前仅剩下 20 多个未解决的 PR，可以表明项目的维护和发展效率是非常高的。

Paimon 作为一个开源项目，得到了来自多个知名企业和组织的工程师们的积极贡献。从去年的 2000 多个提交增长到今年的 3500 多个提交，新增了超过 1500 个 Commit。这些贡献主要来自于携程、阿里云、vivo、字节、抖音、蚂蚁、阿里巴巴、唯品会、小米、知乎、Shoppe 等公司的工程师们。在此，非常感谢大家对 Paimon 社区的贡献！

Paimon 是一个为实时数据处理而设计的存储系统，具备高性能和灵活的数据管理能力。其主要特性包括：

• 表类型：分为两种类型的表 - 主键表和非主键表。

• · 主键表：结合了 LSM（Log-Structured Merge Tree）树结构，支持高效的数据更新与计算，并通过 Merge Engines 自定义数据合并逻辑。此外，还利用 Deletion Vectors 加速查询过程，并且具有自动压缩功能及 Changelog Producer 机制。

• · 非主键表：创新性地实现了流式读写与小文件合并技术、Zorder & Minmax 索引跳过策略、以及 BF (Bloom Filter) 和 Bitmap 等文件索引方式来优化性能；同时也支持 Bucketed Join 以提高 join 操作效率。

• 基础设施：

• · 原生支持高效的流式读写操作，其中流读时可通过 Consumer ID 确保文件的安全状态；同时提供 Changelog Decouple 功能减少文件数量，减轻文件系统负担。

• · 提供全面的运维工具集，如系统表、Procedures 等。

• · 生态方面，Paimon 1.0 版本已经引入了 View 和 Format Table 的支持，以便更好地兼容旧有的表格格式。

• 底层架构：

• · 包括 Tag 和 Branch 的设计，使得数据架构能够实现分支管理，便于解决复杂的数据管理问题。

• · 底层还包括权限控制系统和丰富的 Metrics 监控体系，保障系统的安全性与可观察性。

Paimon 是一个支持多种安全引擎的数据湖存储系统，它不仅拥有丰富的上下游 CDC 集成能力，还支持通过 Flink CDC 进行数据同步。除了 CDC 和 SQL 查询功能外，Paimon 也提供了 Python API 的支持，在新版本中进一步增强了与 Python 生态系统的兼容性。为了更好地融入全球范围内的不同计算环境，比如北美地区的 Snowflake、AWS Athena、BigQuery 等平台，Paimon 1.0 版本引入了生成 Iceberg 快照的功能，使得这些外部计算引擎能够通过 Iceberg 协议访问 Paimon 表，从而促进了更广泛的生态系统间的互操作性和数据共享。

Paimon 最初是作为 Flink Table Store 项目而诞生的，旨在提供一种高效的数据存储解决方案。2022 年 3 月，Flink 社区决定将 Paimon 捐赠给 Apache 软件基金会，以促进其更广泛地被采用和发展。到了 2023 年 12 月，Paimon 发布了首个正式可用版本，标志着该项目达到了一个重要的里程碑。紧接着，在 2024 年的 3 月份，Paimon 成功从孵化状态毕业，晋升为 Apache 顶级项目之一，这反映了它在技术和社区建设方面取得了显著成就。再到计划于 12 月发布的 Paimon 1.0 版本，该版本将进一步强化其作为统一湖格式（Unified Lake Format）的地位，为用户提供更加完善的功能支持和服务。

四、大厂嘉宾分享交流

**徐昱（vivo 互联网大数据专家）：**今天非常荣幸有这么好的机会来跟大家进行行业交流，我叫徐昱，是 vivo 互联网的一名大数据专家，同时也是 Apache Paimon 项目的 Committer。主要负责湖仓一体数据平台的建设与完善，我们当前建设的湖仓系统每天接入数据量达到万亿级、支持 PB 级体量数据高效入湖，可以为我们各种数据业务，包括 AI、数据集成各种业务进行正向的赋能，可以很好地完成企业交付给我们平台地增效降本相关诉求。

**李劲松（阿里云智能开源湖存储负责人）：**感谢徐昱老师，可否进一步分享下在贵公司的实际应用场景中，大概有哪些数据处理链路迁移到了 Paimon 的湖仓一体架构上？

**徐昱（vivo 互联网大数据专家）：**在 vivo，尤其在互联网整个链路中受益比较大的场景主要包含三个：

1. 离线加速场景。大家应该都不陌生，在企业里面有各种各样的实践，最典型的就是 Spark+Hive 这种架构，这是比较稳定的一种架构，但是因为自身数据时效性包括整个数据写入不能够实时去重、聚合等，导致我们在实际生产当中不能满足更好的诉求，于是我们也是基于 Flink+Paimon 地湖仓架构来满足我们在 ODS 的实时写入，包括 DW/DA 实时聚合，最终更快的为下游数据服务提供数据产出，这是在离线加速场景我们受益比较大的一个方面。

2. 数据链路合并。比如说在我们企业里面是针对 Lambda 链路合并，可以将 Lambda 链路原先的资源冗余或者是数据口径不一致的问题，通过 Paimon+Flink 这种数据架构得到完善，能够减去不必要冗余的计算和存储资源成本。同时在更新的场景，我们也包含了数据拼接这种业务场景，主要是在数据的采集、合并这块，Flink 任务稳定性带来的风险可以避免掉，这是在我们数据合并链路比较突出的一个湖仓应用。

3. DB 数据同步，企业里面相信大家有很多场景，比如说 MySQL 数据需要导入到大数据集群当中进行生产分析，基于我们传统的链路包括 Flink+Hive，因为数据不能去重或者说整个数据在计算的时效上可能需要小时级或者天级，最后也不能很好的满足业务特定的场景特征。这块我们是基于 FlinkCDC 或者 Flink 直连这种方式，将数据实时入湖，打造一条分钟级的类似于 MySQL 这种事务语义的湖仓，在这种湖仓体系下面，用户可以更快的去分析他的数据，然后再结合上我们湖仓的语义可以以一份表，就不需要多个分区，可以灵活去调整我们数据的查询体验，这样也可以降低大量的存储成本，最终就是在我们数据上游可以通过 FlinkSQL 包括 SR 去做联邦即席查询，很好地将历史数据与我们已经入湖的 Paimon 湖仓数据进行联邦查询，可以用更低的成本、更高的时效来满足上游数据产出。

这整体是我们湖仓链路的一个落地实践。

**李劲松（阿里云智能开源湖存储负责人）：**这个链路还是很丰富的，具体有哪些场景可以给我们分享一下。

**徐昱（vivo 互联网大数据专家）：**其实我们的数据架构整体还是中规中矩的，跟大部分企业的数仓建模或者湖仓建模是非常接近的，从数据源的产生到 ODS 数据的原班处理到 DW/DM 的聚合计算，再到最后数据报表的产出，大部分企业都是非常类似的。具体的体验比如说在我们链路合并这种场景，我们将原先架构中的实时链路和离线链路合二为一，同时我们的 Paimon 能很好的去做补数，原先我们担心的场景就完全可以不用考虑了。在这种场景下，我们可以将具体生产的计算资源减少 30%以上，这是链路合并场景给我们带来的直接收益，另外还有离线加速场景，可以为更多需要高时效但是低资源成本的场景直接赋能，像这种场景我们可以将天级别或者小时级别的数据时延降低到分钟级，在我们具体的生产实践当中可以将一个千亿级的数据流转链路，将整体的时延控制在 10 分钟以内，也能很好的满足我们业务的诉求，这是我们在离线加速这个场景带来的收益。

另外还有一个收益场景可能是比较特殊的，就是消息组件平替场景，相信很多企业尤其是云上的用户面临一个问题就是实时资源贵，实时资源存储宝贵，他们可能临时面临大促或者是大量数据流量业务过来之后，可能会出现线上 Kafka 或者 Pulsar 集群不够用，这种情况也是常有发生的。在这种情况下，我们完全可以利用 Paimon 来做，以 NQ 这种形式高性能的存在我们生产的链路上面，可以将一些不需要秒级延迟的业务迁到 Paimon 当中，这样的话可以让整个链路控制在分钟级的数据流转，从而达成我们的业务诉求，据帐单统计，这个场景计算资源下降 50%。以及 CDC 场景，刚才也描述过了，主要体现在多个方面，一个是存储方面，在历史的一些 CDC 场景，我们可能需要每天定期做一个快照，通过 FlinkCDC+Paimon，通过定期生成 tag 的方式，我们就不需要去生成多个分区。像这种情况下，我们可以直接将存储资源平均下降 50%，有些场景可能会下降更多。另外带来一个收益是时效，从原先 T+1 做一次同步或者是小时级的，现在完全可以改成分钟级，这也是在我们具体企业实践当中，我刚才大致介绍一下我们 vivo 湖仓在具体落地过程当中得到了一些实际的收益。

**李劲松（阿里云智能开源湖存储负责人）：**再次感谢徐老师的分享，大家对内容感兴趣的话可以关注下分论坛徐昱老师的演讲。

**朱奥（淘天集团 Paimon 新架构升级负责人）：**大家好，我是朱奥，来自淘天集团，目前主要负责淘天集团 Paimon 新架构的升级。

**李劲松（阿里云智能开源湖存储负责人）：**朱奥老师要不来介绍一下现在淘天规模，基于 Paimon 湖仓数据链路大致的落地规模以及落了哪些？

**朱奥（淘天集团 Paimon 新架构升级负责人）：**今年以来不管是业务方还是 BI 的实时数据场景都增多了，还有基于实时数据做 OLAP 分析的场景也在增多，这对我们的开发效率提出了一个很大的挑战。基于此我们开始使用 Paimon 做流批存储的中间层，在我们今年的 618 大促、99 大促和双十一大促，都做了一个稳定性的验证，顺利通过了这些大促。目前公共层和应用层总共的数据存储大概是 80PB+，单任务基于压测和线上的数据，目前是 4000 万 RPS+。

**李劲松（阿里云智能开源湖存储负责人）：**是 80PB，不是 80TB，也挺大的。

**朱奥（淘天集团 Paimon 新架构升级负责人）：**并且下个季度我们还会继续上新的任务，数据量还会继续增多。

**李劲松（阿里云智能开源湖存储负责人）：**之前链路和现在链路大致的对比大概是什么样的？

朱奥（淘天集团 Paimon 新架构升级负责人）：

1. 之前的链路我们构建实时数仓池，主要是基于 Flink+TT，TT 就是对标业内的 Kafka，它是一个消息队列，它可以提供一个秒级的有状态的 ETL 处理，它有一些核心痛点，首先我们流批的存储是不统一的，比如说实时数据是存储在 TT 中，离线数据是存储在 HDFS；

2. 并且实时数据是不可见的，一条 TT 或者 Kafka 数据是一条字符串，如果说没有什么数据开发经验的 BI 如果想做数据分析，这个数据对他来讲是不可用的，当然他也可以找到离线去分析，但是离线分析的话，这个数据就变成小时级别的了；

3. 像 TT 和 Kafka 是不支持去重的，我们离线的 DWS 链路一直都是有的，但是因为实时的存储介质无法去重，支持的 DWS 一直没有建设。

痛点主要是这三个。基于这三个痛点，正好有了 Paimon 可以做流批一体存储的组件，我们今年就开始了一些实践，我们用了 Paimon 之后主要就是分钟级延迟，使用了之后，业务可以基于 Paimon 中间层的表做一些实时的分析，对于我们实时开发来讲，可以做一些流批一体的开发，对于我们流批一体开发的效率也是一个很大的提升。因为 Paimon 主要是可以一张表存实时数据和离线数据，实时数据是分钟级，离线数据是小时级或者天级，并且中间层的数据对于 BI 来讲它可见了，如果说业务 BI 给我们提的需求比较多，并且有一些需求比较简单的话，那对于这些比较简单的需求，他就可以不用数据开发来搭数据链路，业务 BI 直接查 Paimon 表，在数据产品上就可以直接做一些简单的分析，可以提高 BI 的查数效率，因为他给你提需求肯定比他自己查要慢，而且这个数据是分钟级的。我们基于 Paimon 可以做一个中间层的去重，业界的数仓在应用的时候公共层也是没有去重的，因为你没有一个好的存储组件，没法做公共层的去重，特别是对交易流来讲，交易流一般都是要做去重的，如果公共层我们一次去重，比如说我们有 100 个下游，100 个所有下游就都不需要去重了，而在 Flink 当中你如果做去重的话，它很费 state，你一次去重抵的上 100 次去重，可以节省很大的成本。

今年以来我们对于日志数据的要求也越来越高了，之前的日志数据都是没有去重的，我们目前在公共层也做了流量数据、日志数据的去重，以前流量任务如果实时任务重启，下游数据就会变多，基于 Paimon 做了去重之后，不管任务重启多少次，流量数据也是不会增多的，很精确。

**李劲松（阿里云智能开源湖存储负责人）：**是的，之前的链路如果遇到作业重启的话，重启会影响最后的报表数据，导致报表里面的指标一会儿上去一会儿下来，令查看报表的人员非常的困惑，难以解释这样的现象。

那接下来，Paimon 构建的新架构的整体情况请朱奥老师来分享一下。

**朱奥（淘天集团 Paimon 新架构升级负责人）：**我们在采集层采集到数据之后，然后数据会到 ODPS 层，实时的存到 TT 中，也就业界对标 Kafka，离线的话存到 HDFS 中，我们会起一个 Flink 任务，流任务流读 TT，批任务的话去读 HDFS，实时数据的话就写到 Paimon 表的实时分支当中，离线数据就写到 Paimon 表的离线分支当中，这样的话我们 DWD 层就完成了，完成之后我们会再起一个 Flink 流批一体任务，就消费 DWD 层的数据，然后建设我们实时和离线的 DWS 层。所以我们基于 Paimon，主要的应用是在公共层，我们把淘天的公共层用 Flink+Paimon 重新搭了一遍。今年以来和爱橙团队、之信 (李劲松) 老师这边的团队也有很多合作，我们也做了很多 Paimon 数据开放还有保障性相关的工作，大家可以看到右边比如说我们做了一些 Paimon 的 down 标、Paimon 和离线 OBPS 读取和写入的打通，开发数据上做了一些流批的开发，元数据的管理。Flink 这边做了一些开放存储的优化，可以提高批读的速度。还有一些运维的升级和集团稳定性的保障。

最后就是横向能力，我们目前的压测工具已经支持 Paimon 了，可以基于这个压测工具来搭建 Paimon 的压测链路，这主要是大促的时候使用的，大促预案的准备还有 Paimon 资源的保障，这些都有在建设。

**李劲松（阿里云智能开源湖存储负责人）：**整体这条数据湖仓链路的实践收益和规划大概是怎样的？

**朱奥（淘天集团 Paimon 新架构升级负责人）：**首先是批链路，因为它的流量是最大的，数据量是最大的，产出时间每天提高了 40 到 60 分钟，因为我们现在已经是流批一体开发了，我们的开发效率和运维效率也都提高了 50%及以上，并且我们实时中间层数据可见，对于业务 BI 来讲他可以自己去分析，基于中间层数据自己去自定义分析，提高业务 BI 的分析效率。

基于 Paimon 我们做了去重，就可以减少很大去重的成本，主要是减少应用层任务去重的成本，最后因为 Paimon 使用的是廉价的 HDFS，所以它的存储成本也是在下降的，相对于传统的消息队列来讲。

**李劲松（阿里云智能开源湖存储负责人）：**整体后面的规划大概是怎样？

**朱奥（淘天集团 Paimon 新架构升级负责人）：**我们想用 Paimon 来解一些稳定性方面的问题，还有集团内部保障相关的继续去做。

第一，我们想借助 Paimon 的分 bucket 存储解决拉取 ODPS 大维表慢的问题，就像实时任务它在重启的时候会去拉去 ODPS 维表，如果这个维表太大的话，特别像 shuffle hash，比如说有 256 个并发，它会拉取 256 次，假如这个维表有 100MB，它会拉取 256 次，基于 Paimon 分 bucket 存储，我们在存储离线数据的时候就把数据分 bucket 存储，假如说我们的实时任务有 256 个并发，它去拉取 Paimon 数据的话，每个 bucket 只拉取一次，它对于离线的全量数据最后的结果是只拉取一次，这样的话我们实时任务的重启时间，就加载大维表的时间可以从分钟左右提高到秒级。

第二，我们希望借助 Paimon 的 partial update 解决双流 join 的问题，正在做了，也是一直在和 Paimon 团队沟通协作。

第三，我们希望借助主键表的 Roaring Bitmap 解决 ADS 层的开发效率、大 state 和成本高昂的问题。

第四，Paimon 在目前淘宝天猫 618、99 和双十一大促的表现也是得到了我们的认可，顺利通过了大促，所以未来我们会在集团内部像我们的直播业务、生意参谋业务还有自营业务，在集团内部大范围的推广。

**李劲松（阿里云智能开源湖存储负责人）：**非常感谢朱奥老师，整体在今年落地这么广，也离不开淘天集团的努力，包括爱橙集团和阿里云大家的努力，再次感谢来自淘天的分享。

**李明（抖音集团基础架构工程师）：**大家好，我来自抖音集团数据平台流计算团队的李明，目前在团队内主要做 Flink+ 数据湖相关的工作。

**李劲松（阿里云智能开源湖存储负责人）：**我们直接进入主题，李明老师可以分享一下整个抖音集团的架构。

**李明（抖音集团基础架构工程师）：**我们在抖音集团目前主要接入的核心业务有抖音、电商、生活服务以及广告这类数仓业务的团队，我们主要是和他们数仓 BP 业务的同学对接，因此面向的场景也是以构建实时数仓或者流式湖仓为主。

基于 Apache Paimon 去构建流式湖仓的时候，在数据建模上和传统的数仓模型是一致的，数仓同学不需要重新设计业务建模，我们目前对接的主要业务场景包括两大类，第一类是实时数仓，这一类我们主要是使用 Kafka + Apache Paimon 去共同建设，具体场景有实时大屏、实时特征。第二类是我们使用 Apache Paimon 独立构建流式湖仓，在这类场景中，业务不追求秒级的延迟，分钟级延迟即可，主要包括近实时数据分析、长周期指标聚合等。最下层的数据存储目前主要使用 HDFS 以及抖音集团内部自研的分布式对象存储 TOS。

**李劲松（阿里云智能开源湖存储负责人）：**也分享一下当前基于 Paimon 的湖仓业务实践当前的进展、规模。

**李明（抖音集团基础架构工程师）：**我们目前在公司内推广 Paimon 的时间相对较短，Flink 湖仓的任务数大概在 300+左右，包括 Flink Streaming 和 Flink Batch。日新增数据量大概在 2000 亿条左右，主要来源于日志埋点、Binglog 以及加工后的聚合类数据。天级新增文件存储量级约 60TB 左右，主要的收益来源于列存的高效压缩。

**李劲松（阿里云智能开源湖存储负责人）：**任务不多，但是数据量巨大，这符合抖音集团的规模。接下来，可以分享下整体的实践收益。

**李明（抖音集团基础架构工程师）：**实践收益我们从三个方向来看：首先是开发提效，基于 Flink 流批一体计算引擎加上 Apache Paimon 流批一体的存储，在进行数仓建设时，流与批的数据口径天然就是统一的，对于业务开发人员来讲，不需要再像之前使用完全独立的流与批两套架构去进行开发，可以大幅减少用户的开发流程，简单来说就是批式开发，流式上线。第二个收益主要来源于存储层面，由于我们流批数据口径统一之后，可以进行复用，复用之后可以减少流与批之间的冗余存储。最后一部分是我们在一些复杂场景上的支持，比如说长周期指标聚合、多表打宽场景。之前这类场景一般是基于 Flink state 去实现，任务的 state 会随着时间周期的延长越来越大，整体计算资源以及后期的维护开销成本都会越来越高，这里得益于 Apache Paimon 提供的 Agg MergeEngine、PartialUpdate 等能力，可以把这部分状态外移到了存储层，从而简化了用户的开发逻辑，并且任务的稳定性也可以得到一个大幅度的提升。

**李劲松（阿里云智能开源湖存储负责人）：**整体收益还是非常明显的，我相信业务方对这个收益也是非常满意的。接下来，可以分享下未来的规划。

**李明（抖音集团基础架构工程师）：**首先我们希望去提升湖仓的使用体验，在传统离线数仓里面，数据血缘以及相关运维工具都是比较完善的，而在流式湖仓建设中，因为现在相对比较新，所以相关的工具还是比较欠缺的，我们希望进一步从工具的层面上去提升用户使用上的体验。其次是我们希望在近实时数仓的场景中进一步推广 Apache Paimon，首先 Apache Paimon 跟 Flink 结合是最紧密的，Flink 现在最新的特性 在 Apache Paimon 中都可以很快进行适配，因此在近时数仓上面去选择 Apache Paimon 作为流批一体存储是比较适合的。最后是我们希望去做一些性能上的优化，这主要在一些特定的场景下，比如千列大宽表以及 TB 级大维表的场景下，我们看到目前 Apache Paimon 是有一些性能瓶颈的，所以我们希望进一步去优化它，从而在更复杂的场景中去进行应用。

**李劲松（阿里云智能开源湖存储负责人）：**非常期待这些优化，非常感谢李明老师的分享。

大家听完这三个大企业的分享，大家有什么感触？我作为科代表总结一下来自企业的反馈。

整体我听到这些东西，最明显的就是时效性，Flink+paimon 是真正给企业带来时效性的提升加速很多离线作业，并且让这些离线表实时可见，实时可查询。

1. 业务分析直接查询最新实时的数据，不用再提需求为临时数据去构建昂贵的流式 ETL，包括 ODS 的流式入湖实时可见，也包括 DWD、DWS 的实时可见，这是第一点最大的好处。

2. 第二点是统一存储，各位老师都提到了流批一体，Paimon 是真正流批一体存储，流批链路完全的统一，整体的开发效率得到非常大的提升。

3. 最后就是降本增效，更快、更便宜，不但做到了时效性的提升，而且整体付出的钱更少了，成本还下降了。

这是我从前面嘉宾们分享得到三个最大的信息。本次的分享交流会就到这里，更多精彩请关注流式湖仓分论坛！

更多内容

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：新用户复制点击下方链接或者扫描二维码即可 0 元免费试用 Flink + Paimon实时计算 Flink 版（3000CU*小时，3 个月内）了解活动详情：https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc