Paimon Apache 实时湖仓存储底座

一、实时湖仓

这是一个十分经常出现的图，展现了数据架构的时效性演进。

目前在企业中典型的数据架构大抵分为两种，一种是批式数仓，传统的 Hive 表加上 Hive 或 Spark 的计算，而后或许前面再对接一些 OLAP 引擎，包含 Doris 或 StarRocks。这套架构的关键疑问在于时效性。这里的时效性分为两个含意：

近年来，Flink 在中国的实时数据仓库畛域获取了宽泛运行，其架构包含 Flink 流计算、Kafka 作为两边数据流转，以及将结果表间接存储到 OLAP 系统中，这种纯流式的架构在许多企业中获取了推行。其 ETL 的时效性可以到达秒级，当然，这也取决于整个处置链路的不同，有些或许还是分钟级。查问的时效性可以更快，比如当数据最终存储到 ADS 层时，假设是 MySQL，可以提供毫秒级的查问；假设存储到 OLAP 系统，也可以提供毫秒级或秒级的查问。这两种架构在各个企业中都很经常出现。

作为一个早期从事流计算的研发人员，我不时在思索如何让实时数据处置在更宽泛的范围内推行，让更多的数据能够进入实时处置畛域，而不是一切数据都必定等到ETL（提取、转换、加载）的次日才干被检查。

随着近年来的推行，简直一切企业都树立了实时架构和实时数据仓库架构，尤其是 Flink 架构。但是，在企业中，大局部数据依然存储在批处置系统中。实践上，人们只是将大概 10% 的数据转换到实时数据仓库中，以成功秒级的事务和操作（ETL）。

因此，咱们启动了许多尝试，比如第一个尝试是驳回 Kappa 架构，将一切数据都导入实时数据仓库。但这样做全体的复杂性十分高，开发一条实时链路并不容易，两边结果无法查问，开发环节也很复杂。此外，最外围的疑问是老本十分高，与传统的批式数据仓库相比，老本或许高出十倍、几十倍甚至上百倍。

第二个尝试是流批一体的架构。应用 Flink 的流计算才干，在满足实时数据流计算的同时，也应用 Flink 批式 ETL 的才干，至少在周期性计算层，让数据仓库开发人员能够编写一套周期性上班，这套上班可以在两种架构中通用。但随着这几年的推行，咱们发事成功这一目的的难度十分大。一方面，Flink 的批处置配置还不够成熟。另一方面，还有一个十分内围的疑问，即两套架构的存储形式不同。一边是 Kafka 或许 OLAP 系统如 Doris 和 StarRocks，另一边是 Hive 这种表存储的格局，它们的操作形式齐全不同。假设只是用一套计算引擎的SQL 来一致它们，会发如今业务上基本无法经常使用。

因此近年来聚焦于实时湖仓的架构。咱们剖析了之前架构的疑问，关键是两种架构太过火离，只要实时链路，即实时数据仓库这条链路，才干成功数据时效性的优化。

批处置架构最大的疑问在于存储才干无余。比如经常使用 Hive 存储，仅仅是将文件搁置在一个文件夹中，至于文件如何组织、如何处置，它一律不担任，只能经过写一个大的 insert overwrite 语句来更新分区，因此其才干极端有限。而湖格局的才干在于治理每一个文件，能够成功 ACID（原子性、分歧性、隔离性、耐久性）操作，甚至能够成功流式读取和流式写入，成功分钟级的更新。这就能够优化数据的时效性，或许使表向流式处置和实时处置方向开展。

这样咱们就得出了这样一套架构——实时湖仓。它不再局限于批处置计算，而是既能启动批处置计算也能启动流计算，各种计算都可以在下面启动，存储是齐全一致的。基于这种一致的计算，联合湖格局和 OLAP，能够到达分钟级的时效性。这样一套时效性的优化都是在原有的批式数据湖仓架构中成功的。

因此，实时湖仓是批式数据仓库的原地更新，它并不是一个代替相关，而是批式数据仓库的间接更新。在原有的批式数据仓库的时效性为 T+1 的状况下，经过流计算和实时更新技术，能够将时效性优化到分钟级。在原有读写操作十分粗粒度的状况下，能够成功流式更新、批式更新能够成功流式读取，甚至能够成功对查问文件的过滤，以成功高性能查问的成果。

简而言之，实时湖仓解锁了完整的大数据全生态，在一套存储架构上，能够成功流批一体的计算，也能成功典型的 OLAP 查问。

原有的批式数据仓库可以被以为是经典的绿皮车，运转缓慢，但吞吐量大，老本低。而实时数据仓库则像是飞机，十分快，但老本很高，也容易出疑问，就像下雨天经常有飞机正点。而实时湖仓想要到达的成果是传统火车的更新版，依然在地上，依然是传统火车的老本，但可以变得更快，像高铁一样。

二、Apache Paimon

引见完实时湖仓是什么之后，在引见 Paimon 之前，须要先谈谈 Iceberg。Apache Iceberg 在国外经常使用相当宽泛，在最近一次性峰会中，其开创人示意，Iceberg 是 Shared>

Paimon 则是站在 Iceberg 这个凡人的肩膀上做了全新的设计。Paimon 外围的翻新点就是原生允许了在一张表上对它定义组件，定义组件之后就可以关于这张表启动流式的更新。举个例子，针对 MySQL，定义主键之后，可以对它启动一些 update 的更新，同一个主键不用先去删再去增，间接去写 insert 即可。这样就解锁了流式处置的才干。可以在 Flink 中挂载一个 Sink，间接启动流式更新这张表，而后基于它的组件启动一次性更新。在更新的环节中，也可以像 MySQL 一样发生对应的 changlog，让流处置愈加繁难。

那么 Paimon 是如何启动主键更新的呢？主键更新的底层外围结构是 LSM，也就是 Log-Structured Merge-Tree。这种结构曾经获取了宽泛验证，更适宜更新或偏实时的畛域。Paimon 在这方面的翻新是将 LSM 结构引入湖格局中，将实时更新、实时消费带入了湖格局。

实践上 LSM 结构很繁难，它是一个排好序的档次结构。它给湖格局更新带来的最大好处是，在启动紧缩(compaction)时，不须要所有重写一遍。从图中可以看到，它实践上是一个三角形，越底层的数据量越大。LSM 结构只要要保养几层数据，这象征着新来的数据只要要与最下层的数据启动兼并（merge），启动小规模的紧缩（minor compaction），这样全体的写磁盘（write amplification）就十分小，因此紧缩的效率要高得多。至于读取操作，LSM 结构也是排好序的，可以启动读取时兼并（merge on read），对每一层曾经排好序的数据启动兼并读取，其老本也不会太大。

上图展现了 Paimon 从过去到如今再到未来的开展历程和方向。Paimon 最后作为 Flink 的一个子名目在 Flink 社区中开展，最后的名字叫做 Flink Table Store。随着咱们的开展，随着一些业务的落地，咱们发事实践上大家须要的是一个共享的湖格局，而不是一个繁难的 Flink 组件。Spark 和 OLAP 引擎等都须要读取 Paimon 的数据，并宿愿与 Paimon 启动更深档次的集成。因此，咱们选择将 Paimon 从 Flink 社区中独立进去，成为一个全新的名目。经过一年的孵化期，颁布了通用可用（GA）版本，并且许多企业都在不时优化这个打算，直到 2024 年 3 月，Paimon 正式毕业，成为 Apache 的一个顶级名目。

这次毕业实践上也标记着 Paimon 不再是 Flink 的一个子名目，它不只与 Flink，还与 Spark 和其余引擎，包含 Doris、StarRocks 等 OLAP 引擎都有了十分好的集成。估量在 2024 年下半年会正式颁布 1.0 版本，这象征着 Paimon 在整个大数据引擎中的 OLAP 畛域，曾经成功了十分好的集成。

三、运行场景

第一个场景是 Paimon 最后开局运行的场景，2023 年的干流运行是这样的繁难场景：数据库 CDC 入湖，Paimon 可以使 CDC 入湖变得更繁难、更高效、更智能化，链路也更繁复。你可以间接启动一个 Flink 作业写入 Paimon，而后用 Spark 来查问，其它的清算、compaction（紧缩）等上班都为你智能成功。

在这个基础上，Paimon 社区也提供了一套工具，可以协助你启动 schema evolution，将 MySQL 的数据，甚至 Kafka 的数据同步到 Paimon 中。抢先加出列，Paimon 也会跟着加出列。还有一些整库同步的配置，经过一个 Paimon 作业就可以同步成千盈百张这样的小表。

这里分享一张阿里智能引擎通常的示例图。智能引擎的外围疑问是下游有各种各样的需求来读取业务库的表，或许须要将业务库的表发送到 Kafka 中，或许并行读取的需求，许多恳求间接打到业务的备库上，或许造成业务库在很多时刻不够稳固，全体的并发也遭到限度。因此，业务库偶然有挂掉的危险，而且只能布置在早晨处置，白昼间接处置或许会造成系统解体。

这里启动的一个扭转就是经过 Paimon，将 Paimon 作为整个业务数据库的一致镜像表。Paimon 相比 Hive 的长处在于，可以经过 schema 离线地将 MySQL 表同步到 Paimon 中。Paimon 的下游可以允许分钟级的流计算，可以启动流式读取，也可以批量查问 Paimon 表，批量查问的时效性是分钟级的。因此，其外围是将流和批处置都一致到了 Paimon 这张表上，一切下游业务都经过 Paimon 的一致入口来消费业务库的数据。因此，全体的吞吐量没有下限，由于妇孺皆知，Paimon 是树立在文件系统上的，全天 24 小时都可以启动数据拉取，对业务库的压力小了很多。

在这个场景中，Paimon 提供了很多更新的才干，不只仅是更新，保管最后一条记载，也可以在更新时定义局部更新，还可以在 Paimon 上定义聚合引擎，在湖上成功一个智能聚合的才干，或是经过 Paimon 的 change log producer 来实时发生 change log 给下游消费。因此可以基于 Flink 加 Paimon 构建出完整的一套流的这样一个 ETL，这条链路当中简直没有 state 的存在，一切的数据都是基于分钟级的批量更新，因此老本很低。查问可以经过 Doris、StarRocks 来查问。

另一个要分享的是蚂蚁的一个运行通常。须要说明的一点是，这里讲的并不是要代替实时链路，而是许多离线链路宿愿变得愈加实时，但由于实时处置的老本太高，所以很难迁徙上来。

在蚂蚁计算 UV 目的的例子中，之前是经常使用 Flink 的全形态链路来成功的，但起初发现少量业务难以迁徙到这种形式，因此将其交流为 Paimon。应用 Paimon 的 upsert（更新或拔出）更新机制来启动去重，并且应用 Paimon 的轻量级日志 changlog 来消费数据，为下游提供实时的 PV（Page View，页面阅读量）和 UV 计算。

在全体资源消耗方面，Paimon 打算使得全体 CPU 经常使用率降低了 60%，同时 checkpoint 的稳固性也获取了清楚优化。此外，由于 Paimon 允许 point-to-point（端到端）写入，义务的回滚和重置期间也大幅缩小。全体架构由于变得愈加繁难，因此在业务研发老本上也成功了降低。

接上去分享的是倾向 OLAP（在线剖析处置）的运行场景。首先，Spark 与 Paimon 的集成十分好，不逊于 Spark 的内表。经过 Spark 或 Flink 启动一些 ETL（提取、转换、加载）操作，将数据写入 Paimon 中。基于 Paimon 启动 z-order 排序、聚簇，甚至构建文件级索引，而后经过 Doris 或 StarRocks 启动 OLAP 查问，这样就可以到达全链路 OLAP 的成果。

外部对阿里旗下的饿了么启动了评测。当然也可以将一切数据写入 OLAP 类型的表，但 OLAP 系统的疑问关键是其存储是基于 SSD 的，它与计算严密联合，为了到达 OLAP 性能，其老本十分高，造成少量数据无法实时化。

而将数据间接写入 Paimon，由于 Paimon 面前是 OSS 这类对象存储，其全体老本十分低，但时效性只要 1 到 5 分钟，所以这里须要掂量，关于某些对时效性要求不高的数据，可以间接写入 Paimon，经过 Paimon 的一些排序或数据聚簇手腕，使数据更利于 OLAP 查问。而后经常使用 StarRocks 或 Doris 间接启动 OLAP 查问，其查问提前在大少数时刻与 OLAP 内表相差不大。但其成天性降到间接进入 OLAP 系统老本的 1/10，这样做的成果可以减速更多更少量的业务数据。

四、Paimon 前沿技术

最起初分享一下 Paimon 相关的一些前沿技术。

在数据湖格局中，大家听得最多的或许是 merge on read 或 copy on write。Merge on read 即在更新时保管少量 Delta 数据，查问时会比拟慢。Copy on write 即在更新时间接对数据启动重写，写入老本十分大，但读取数据十分高效。所以 merge on read 和 copy on write 是两个极端。Merge on write 想做的是，比如在上图的主键表定义一个主键，定义一个 deletion vectors 形式。它要做的是在写入时，流式生成对原有数据的 deletion vectors，这样不是只写增量，而是先删除之前的数据再写增量，读取时只要读取之前的文件，再基于 deleting vector 间接启动高效的 OLAP 查问。所以大家把这种形式定义为 merge on write，即在写入时启动必定 merge，带来的成果是写入慢一些，但读取快很多，因此这是一个更新和加快查问兼得的打算。

Paimon 在最新版本中齐全允许了标签（tag）和分支（branch）的配置。不只允许标签，最新版本还允许了标签的智能 TTL（Time-To-Live，生定期间）治理。当你将标签和分支联合起来经常使用，会感觉整个 Paimon 的数据操作可以像 Git 一样。这在很多状况下十分有用，比如启开工程验证或测试时，经常使用这些分支和标签会十分繁难。

另外，咱们外部目前正在启动的一件事是基于 branch 才干来成功完整的流批一体的概念。比如，有一个分支是用于流处置，正在启动流式读取和写入，还有另一个 branch 是批处置的，我可以同时启动批处置的写操作。这样，基于同一张表，从业务角度来看，它能够成功流和批齐全隔离的流批一体成果。

关于通用索引的允许，正如刚才提到的 OLAP 场景，deletion vector 形式也是一种面向 OLAP 的技术手腕，通用索引的允许也是向低劣的 OLAP 引擎看齐的一种手腕。例如，像 Doris、StarRocks 这样的 OLAP 引擎，它们不只允许 Min/Max 索引，还有 bitmap、Bloom Filter、倒排索引等才干。湖格局（Lake Format）也可以领有这样丰盛的索引才干，并且可以在昂贵的对象存储基础上，成功十分高效的基于过滤条件的数据跳过（data skipping），到达高效的 OLAP 查问才干。所以 Paimon 的最新版本也在研发 bitmap 索引，后续也会探求倒排索引的成功。大家都知道，一旦命中 bloomfilter，或许会有 10 到 100 倍的性能优化，命中 bitmap 索引也或许有数倍的性能优化。