为什么Paimon值得期待
ckckck2025年1月10日37 浏览以下文章来源于码上观世界，作者咬定青松。
码上观世界 提供大数据和AI技术咨询和订制服务，网站：https://www.mindtechassist.com，微信：373055922。
前段时间，Flink table store 更名为 Apache Paimon，并重新进入 Apache incubator。截止目前，incubator-paimon 项目已经在 GitHub 上收获了 600+ Star：https://github.com/apache/incubator-paimon。
之前虽然了解到 Flink table store，但没空去了解它。趁此机会，我也花了2天时间来专门对它探个究竟，看看到底值不值得研究。
Paimon 目前只进行到 0.4-SNAPSHOT 的开发，社区提的 Issue 也很少。太少的 Issue 并不一定说明系统足够稳定，倒是可能表明当前使用的太不广泛。
任何新生事物要得到广泛认可，都要经历这一冷启动阶段，除非它是像 GPT 那样。Anyway，我们先秉承客观立场，来分析下这款产品。官网很简洁，文档也少得可怜，但是基本功能和 Get-started 倒是介绍到了：
它定位是流数据湖平台（Streaming data lake platform），这点好像只有 HUDI 这么说自己是 platform 吧。比如：
- Iceberg is a high-performance format for huge analytic tables；
- Delta Lake is an open-source storage framework；
- Apache Hudi is a transactional data lake platform that brings database and data warehouse capabilities to the data lake.
看来 Paimon 野心不小啊。不过，对我们使用方倒是好事，但是要做好数据湖平台，基本的能力具备吗？至少拿 HUDI 的能力先来过一遍：
- Transaction 事务；
- row-level update/delete 行级更新；
- change stream 变更流。
然后，在此基础上实现以下能力：
- 数据摄取，支持批和流；
- 支持 Schema evolution；
- 支持 snapshot，time travel；
- 统一并支持不同的存储引擎，像 HDFS、S3、OSS 都不用说了；
- 对接不同的计算引擎，Hive、Spark、Flink、Trino，毕竟这些是数据湖产品的标配；
- 支持批查询、OLAP 查询；
- 支持增量查询。
如果能力足够，再支持一些能力，比如完善的 SQL 能力、changelog 流读流写能力、lookup 点查询能力就更好了。如果说上述能力都具备，那就要拿出来练一练，看看是不是吹的？毕竟，这额外的特色功能连 Iceberg 都不支持，Paimon 刚出茅庐，怎么敢口出狂言呢，而且我们被 Iceberg 坑了一次，这次得长长记性。
从 Paimon 的系统架构中，我们也能明白一二：
- Paimon 基于 HDFS、OSS、S3，提供了统一存储，提供统一存储的表格式也是情理之中，也是预料之中。
- Paimon 内部使用了 LSM。好家伙，看来 LSM 是 Paimon 的能力核心了，毕竟想提供 DB 级的体验，没有 LSM 怎么能行？至少极致的写入能力应该不用过于担心。LSM 无论是理论还是工程实现在业界都比较成熟，可供借鉴的系统不要太多。差别就是具体的实现差异，比如如何解决写放大问题？何时以及如何 compact？
- LSM 支持范围查询和点查询能力，所以它提到 Lookup join 也是没有大问题的，问题是它如何进一步提升其性能了。比如可以引入二级索引 bloomfilter 等。
- changelog 在官网中有提到，它支持将 changelog 写入本地文件或者发送到 kafka 供下游消费。
- 内核能力具备之后，外围的多模式数据导入与查询只是上层应用的事情，这块儿借助 Spark、Hive、Trino、Flink 就可以实现。最后就是 Schema Evolution 与文件组织方式了，这个在官网中也有介绍：
文件组织并没有亮点，直接借鉴（抄袭）Iceberg 前辈的思路就好了。Schema 保存在 snapshot，snapshot 由 manifest-list 组成，而 manifest-list 又由 manifest 组成，manifest 由 datafile 组成。最底层的 datafile 由 partition 和 bucket 决定（定位）。在 bucket 中维护了 LSM 结构。
最后就是多模读的能力了。具备 snapshot 能力，自然就具备了增量（流）读的能力。LSM 的支持，使得增量读和批量读的高效读取能力成为可能，因为 LSM 在写入后的合并阶段能够保证顺序。
关于 Paimon 的一些更多能力介绍，我从 Paimon PMC 22年9月份的演讲中寻得蛛丝马迹，他们对 Flink Table Store 设计提出了一些基本要求：
① 是一个流批统一的存储，提供一定的 OLAP 查询能力（基于列式存储），做到毫秒级别的实时流式读取，能够支持 Insert Overwrite。
这是早期设计跟 Flink 绑定时候的要求，从中，我们姑且相信借助 Flink，基于列式存储的 OLAP 查询能力是不难做到的，但是要做到极致的交互查询能力估计够呛，这是题外话，不能期待过高，暂时不表。但不意味着无法实现，要知道 Clickhouse 基于 LSM 能够提供极致的单机单表查询能力，在这方面，Paimon 要达到这种能力理论上也是可能的。
毫秒级别的实时流式读取能力针对 append Stream scan 应该是问题不大，但是读取需要合并的更新数据流就不一定了。
② 是最为完善的 Flink Connector，支持 Flink SQL 的全部概念，支持任意 Flink Job 的输出，支持所有数据类型。
Flink table store 全面支持 Flink SQL 语法，这个从字节火山引擎的使用反馈可以印证这一点，比如它在建表 ddl 的确支持分区、分桶、主键等能力。借助 Flink 实现批写入、流式写入也是没问题的。
③ 是最好用的 Flink Connector，能够结合 Flink SQL 提供 DB 级别的体验，并且支持大规模更新。
重点来了，DB 级别的体验需要支持上述事务、行级更新、批更新、lookup、change stream 等等，OLTP 的能力大家都懂的，再加上 OLAP 的能力，这会是个什么系统，一般人不敢说。
在演讲后面同时也提到了 Flink Table Store 后续规划的三个目标：
- 好用的流存储。比如多作业写同时写入、Compaction 分离，比如完整的 Streaming Data Warehouse API 设计，包括完整的 DDL、Update、Delete 语法、Time Travel API 支持。以上能力将与 Flink 社区一起在 1.17 版本中重点攻克。
- 准确的流存储。存储本身能够产生完整的 Changelog，下游的流计算易用性才能真正得到提高。
- 可连接的流存储。继续增强 Lookup Join，实现二级索引以更好地 Join，实现维表对齐能力，解决维表不确定性。
如果把基本要求看做理想的话，那后续规划的目标就是现实跟理想的差距。不管理想能否实现，从理想的动员能力来看，的确起到了效果：DB 级的体验多么令人向往，连我都有一种想去贡献代码的冲动了。以上就是外界获取的关于 Paimon 的设计与能力，截止目前，它又有了什么样的能力以及这些能力落地的程度还需要亲自去代码里检查了，下面我就从最重要的读写模块来从代码中梳理下：
这是实现的写入的基本流程，数据是先写内存缓存表，当缓存满的时候，再 flush 到磁盘 Level0 级，同时触发 LSM 合并。合并完成之后，再 commit 生成 snapshot。
Paimon 有多处涉及到读取过程，比如 lookup、scan 以及在 compact 的过程中也会涉及到读取。这里以 lookup 过程为例，它依次按照 Level 从高到低的顺序查询每个 level 是否命中记录。在查询每个 level 过程中，采用二分法定位目标记录所在的 datafile 元数据文件，然后通过 datafile 元数据文件找到物理存储文件，最后在物理文件中通过二级索引 bloomfilter 定位目标记录。
总结
从上述调研情况来看，Paimon 具备了 Iceberg 的几乎所有能力，同时引入 LSM 提升了使用 Iceberg 合并删除文件的检索能力。Paimon 通过 partition 和 bucket 中引入细粒度的 LSM 和二级索引，提供了分布式查询能力，提供了不依赖 Hbase 实现 lookup 的可能性。Paimon 支持主键、分区、分桶等的能力，以及底层存储引擎上面的列存、预排序，以及向量化查询能力，提供了不依赖 Clickhouse 实现极致简单查询能力的可能。Paimon 目前从跟 Flink 的深度绑定中解脱出来，支持了多引擎，同时 Paimon 支持的多流 join 能力，有助于将状态存储在存储层中实现，从而降低 Flink 本身的 State 压力，所以 Paimon 值得期待。
end