Apache Paimon 统一大数据湖存储底座

2024-06-19资讯

摘要：本文整理自 Apache Paimon PMC Chair 李劲松（之信）老师在 5月16日 Streaming Lakehouse Meetup · Online 上的分享，主要分享 Apache Paimon 相关的演进、目标及应用。内容主要分为以下四个部分：

从孵化到毕业，Paimon 的发展与场景
统一存储底座，Paimon 与流、批、OLAP
完整生态集成，Paimon 的计算引擎推荐
阿里巴巴实践，Paimon 数据湖战役

Tips： 点击 「阅读原文」 跳转阿里云实时计算 Flink～

从孵化到毕业，Paimon 的发展与场景

Paimon 最初在Flink社区中以 Flink Table Store 的名称出现，开始在 Flink 社区内孵化。直到 2023 年，Paimon 发展成为一个公共的、与具体引擎无关的湖式（Lakehouse）架构，从 Flink 社区独立出来，转变成一个 Apache 项目。到了 2024 年 4 月，Paimon 正式完成了在 Apache 的孵化过程，成为了一个顶级项目。

1.1 数据架构的演进：流批一体的 Lakehouse

在为什么要做 Paimon 之前,必然会谈及数据架构的演进，即为什么最后会做出实时数据库 Apache Paimon。

业界最开始的架构基本上是 Warehouse 架构，比如传统的 Hive 数仓，是一个天级的ETL分析，不管是 LOG 还是 CDC 数据都是通过 Batch 的方式流入数仓，ETL 再进行加工，最终导入业务库。以上方式的好处是流程非常简单，坏处是其数据时效性永远是 T+1 的。

此时，Flink 出现了，Flink 主打流式计算，能将传统离线数仓的时效性从 T+1（天级/小时级）加速至秒级。所有的数据通过秒级流动的方式流入数仓，称为实时数仓（Streaming Warehouse），数据最终落入最底层的 ADS、OLAP 等系统提供秒级的查询。整条链路非常实时，这是近年总体的发展方向，但成本很大，开发复杂度较高。所以可以迁移部分价值较高的业务至实时流式数仓，但是往往迁移不了全部业务，故上述两种方式在业界并存。

不仅是实时数仓，离线数仓也在往更好的方向发展，出现了 Lake house，它不只是一个纯离线架构，还能带来一定的Streaming 处理。它在原来离线数仓上做更好的操作，因为底下的 Data Lake Format 有更细粒度的保证。在此基础上，天级的刷新带来了更好的时效性保障。但此时，Warehouse、Lakehouse、Streaming Warehouse 还是比较割裂的状态，中间仍缺乏让两种技术融合在一起的部分。

Paimon 的出发点是想通过底层格式的提升来实现 Streaming Warehouse 的分钟级数据更新，以此促进 Lakehouse 的数据全链路流动。Paimon 把整套架构连在一起，数据以离线的方式或更低成本的方式来 Work，当离线的方式不够，需要更高的时效性时，就可以用 Streaming 的方式使之流动。这离不开两个技术，一个是 Flink，目前主流的流计算引擎，另一个是更好能力的格式支撑。

1.2 Paimon前身FTS诞生的特点与优势

为什么做 Paimon 这样全新的湖格式，有以下三点缘由（优势）。

（1）实时数据湖，以低成本的方式支持湖上更新，且在此基础上还有开放的格式、数据、计算。

（2）流式数据湖，深度集成 Flink 流式计算，完整的流读流写与融合状态计算的方式。

（3）国人主导的社区，目前可看到来自阿里、字节等国内各种公司，Paimon 社区/ Flink Table Store 的存在确保了针对国内企业问题解决时的沟通更为直接，响应更加迅速。

我们认为以上三点是别的技术无法取代或根本解决的，所以研发了 Flink Table Store。

1.3 Paimon社区的发展

从 Flink Table Store 到 Paimon 孵化再到成功毕业这两年来，Paimon 社区的发展非常迅速。从 2022 年到 2024 年， Contributors、Commits、Stars 都有巨大提升，这离不开国内各大公司的支持。

1.4 Paimon 的核心场景

目前 Paimon 的核心场景主要有以下三点。

（1）CDC 入湖

Paimon 对此做了相当多的优化，来保证更简化的架构、更好的性能与实时性。具体有：一键整库入湖，大幅简化架构；也可达到实时更新、极速查询的场景，且在此基础上成本不高；可以灵活更新，定义部分列更新、多种聚合更新。

（2）构建流式链路

即可以用 Paimon 来构建完整的 Streaming 链路，有以下几个支撑的场景：第一，可生成变更日志，在流读时就能拿到已更新好的全行的 Record 数据，这非常有利于 Streaming 链路的构建；第二，Paimon 也朝着变成真正的队列的方式向前发展，有消费者机制，在最新版本当中，有变更日志单独生命周期管理，可像 Kafka 一样定义更长的变更日志的生命周期，比如 Kafka 保存一天以上或者三天；在此基础上，构成了轻状态低成本的流式链路。

（3）极速 OLAP 查询

前二者使整条链路流起来了，但流起来之后，数据需要沉淀，所以 Paimon 也做了很多东西，使在这条链路沉淀下来的数据中能达到极速的OLAP查询。第三点就是实现 Z-Order + 索引结合计算极速分析；分析引擎在 Paimon 上蓬勃发展，形成平权发展的引擎生态，包括 Flink, Spark, StarRocks, Trino 都能很好的查询。

统一存储底座，Paimon 与流、批、OLAP

接下来简单分析一下，Paimon如何做统一存储底座，如何赋能流、批，OLAP更好的查询。

2.1 流、批、OLAP 一体化架构

首先看 Streaming Lakehouse 架构，数据可以被 Streaming Ingestion 流入数据湖中。Paimon 可以架设在 OSS、HDFS 等系统上，然后在此之上把数据沉淀下来，通过 Flink 或 Spark 以Batch 的计算方式降低成本。也可以为了时效性，用 Streaming 的方式，如 Flink Streaming SQL 使整条链路流动起来。数据沉淀需要分析，为了进行深入分析和获取洞察，我们常常需要借助 OLAP。Trino 和 StarRocks 等技术都是进行 OLAP 分析的优秀选择。Paimon 社区希望能将这三者都做到极致，或业界领先的水准，所以这套架构能支撑完整的三种计算，也能支撑各种各样能力丰富的计算引擎。

2.2 Paimon 的统一存储发展

下图罗列了 Paimon 做了一些支撑。

（1）流

第一，作为统一存储发展，在流方向与 Flink 深度集成，共同往前发展；第二，Flink 与 Paimon 两个社区携手共进，整体继续提升更新能力，更新是流的基础；第三，Paimon 扩大流写流读的场景，分钟级覆盖所有 Streaming 场景。

（2）批

主要分为两个方向，一个方向是继续和 Flink 往前，打造流批一体架构，流批一体计算 + 流批一体存储；第二，目前业界常用的批处理引擎是 Spark，所以 Paimon 深度集成 Spark，打造了业界领先的批读批写性能，预计在不久的将来，阿里云也会使用 Spark 与 Paimon 来进行 TPC-DS 的标准测试。

（3）OLAP

第一，Paimon 深度集成 OLAP 引擎：StarRocks、Trino 等；第二，推出 Deletion Vectors 模式，能在湖存储上达到近实时更新，极速查询；第三，文件上加强 Z-Order 及丰富的索引，加速查询。

综上，在流、批、OLAP 中，Paimon 作为一个存储格式，低成本、分钟级覆盖主流大数据需求。

完整生态集成，Paimon 的计算引擎推荐

接下来分享完整生态集成以及 Paimon 的优势。

主要分为三个领域：流写流读、批写、批读/OLAP。在这三个方面，拥有全部能力的是 Flink，这并不意味着 Flink 所有的东西都非常好，它最好的地方在流写流读；批写批读的能力除了 Flink 就是 Spark，它是推荐的批引擎，也有部分流写流读能力，但弱于 Flink；查询侧则集成了较为丰富的生态，目前市面上主流的引擎都能查询 Paimon，目前有较强 OLAP 能力的是 StarRocks，当然 Trino、Doris 也提升了很多。

阿里巴巴实践，Paimon 数据湖战役

接下来简单介绍一下阿里巴巴实践，Paimon 数据湖战役，以及究竟哪些业务能用于数据湖。

4.1 阿里巴巴业务应用场景

下图是阿里内部业务的大致应用场景：Flink 流作业有 3 万+ Cu（不包括 Contributors、Stars 等计算）、300+ 作业、20+ 业务方，整体作业并不多，这和阿里降本增效有关，一个作业其实可能是十张甚至几十张表的计算，可以很好降低成本。

（1）业务

通过流式湖仓提升原有纯离线数据的时效性，但整体不会带来太大的成本增加；还有其他业务，如 CDC 入湖降低成本；经过 Z-Order 或索引构建，结合 StarRocks 这类 OLAP 引擎，能极大提升查询性能。

（2）进展

目前还仍处于初步阶段，后面最重要是继续整合内部计算系统和权限系统形成完整的数仓体验。

（ 3）收益

大幅降低实时化成本，达到流批一体化开发体验，也能解锁开放式的计算能力，能对接所有主流的计算引擎。

4.2 统一湖存储：打通阿里云所有计算引擎

在统一湖存储上，怎么打通阿里云内部主流的计算引擎：Serverless Flink、Serverless Spark、MaxCompute、Hologres、Serverless StarRocks，有以下三点。

所有计算引擎打通 Paimon 达成 State-Of-Art 的性能，使所有的计算引擎/OLAP查询性能达到业界领先的计算性能。

结合 Flink 构建流批一体的 Streaming Lakehouse。可以在一套架构中，有 Paimon 统一湖格式的存储，灵活按照自己的业务选择不同的计算引擎来赋能，这也是这几年来业界的趋势。

目前还没有一套计算引擎能满足所有需求，在计算上的能力非常多。不管哪个计算引擎需要补全所有的其他的能力，都非常难。所以 Paimon 在此假设基础上，目的是打造统一的、可贡献的存储：在计算引擎和存储的交互当中，做到业界领先的水准。但是存储又拥有开放、基于对象存储的低成本优势，这样能解锁很多业务，按照不同需求使用不同的计算引擎。

4.3 Paimon 与 Serverless Flink

最后，是 Paimon 与 Serverless Flink 在产品上的融合。

首先是元数据管理，以前 Flink 主流是基于 connector 的方式。但 Paimon 是面向 Catalog 的方式，这需要给 Flink 产品带来了使用上的优化。第二，查询脚本 Flink 产品+Paimon 着力提升了查询性能，以前是几十秒才返回，最新版本已优化到最小几秒返回查询。第三，CDC 入湖 Flink CDC 做了非常多的优化，在产品上有对应的方式。第四，包括作业运维，甚至除了流以外，Flink 产品都有一定的批处理能力。所以在 Flink 产品上也支持了工作流调度，支撑简单的数据回刷。长期来讲，Serverless Flink 和 Paimon往前发展，达到流批一体的开发与不断的构建。