流式数据湖 Paimon 0.7 的研发进展

Paimon 概述

首先介绍一下 Paimon 是什么。

Paimon 是一个 Lake Format，是一个实时湖仓架构，与 Flink 和 Spark 的集成都非常好，提供了流批一体的数据湖操作。Paimon 创新性地结合了 Lake Format 和 LSM（Log- structured merge-tree）结构。其中 LSM 与时间线 LSM 不同，Paimon 的 LSM 是作用于数据之上的，将实时流更新带入到数据湖中。

02

1. 基本概念

接下来介绍 Paimon 现有的主要能力。Paimon 提供了三个基本概念：主键表、日志表和湖管控。

主键表是 Paimon 的强项之一。可以定义一个主键，然后 Flink Streaming 作业会来写这个主键，即可进行 Upsert 操作。核心点是有主键，带更新的。

日志表则没有主键，可以用来流写流读，也可以把它当 Queue 来用，更多是用来取代传统的 Hive 存储，类似于 Iceberg 这种大规模批处理的数据湖处理。

目前数据湖仍存在各种问题，并没有一个成熟的数仓那样好用，所以数据湖在湖格式方面做了很多 Feature，让数据湖看起来更像数仓，用起来更加方便，这里我称之为湖管控。

2. Paimon 主键表

接下来介绍 Paimon 主键表，包括主键表的入湖和更新两方面。

主键表一个非常重要的应用场景就是 CDC 数据入湖，可以使用 Flink SQL、Spark SQL 或 Spark 以 Upsert 的方式来写入 Paimon 表，甚至可以通过 Flink Streaming Execute Sql 的方式将数据写入 Paimon 中。但是这样会产生一个问题，即需要提前建好这张 Paimon 表，并定义好主键和字段。在生产环境中，上游数据库可能会发生一些 Schema Change，此时事情就会变得麻烦，可能需要停止 Flink Streaming 作业，去做例如 Alter Table、Add column 等一些更改 Schema 的操作，然后再启动新的 Flink SQL。由于 SQL 本质上要求 Schema 是固定的，所以无论是增加字段还是修改 Schema 时，都需要编写新的 Flink Streaming SQL，同时还需要负责找到 Source 的点位，这是一件非常麻烦的事情。因此，Paimon 社区做了大量工作，实现了 CDC 全自动入湖。

Paimon 提供了一些结合 Flink Data Streaming 的 API，用于编写 Schema Evolution 的入湖。除此之外，由于 Flink SQL 本质上一次只能同步一张表，在生产环境中往往有大量的小表，此时每个小表都需要一个同步链路，这样会导致资源消耗巨大，甚至比数据库的资源消耗还多，这是不可接受的。因此，Paimon 在全自动入湖时，也处理了整库同步和自动加表的功能，使得入湖变得全自动且完全无感知，无论是加列还是加表。

如上图所示，Paimon 最开始对接了 MySQL CDC，之后对接了 MongoDB CDC，再后来又对接了 PostgreSQL CDC 以及 Pulsar 和 Kafka。因为如果 Pulsar 和 Kafka 中的数据是 Canal Json、Debezium Json、Maxwell 或者 OGG Format，很多情况下是有字段信息的，即字段以及字段对应的值。所以在有这种源信息时，就可以结合 Pulsar 和 Kafka 做 Schema Evolution 的数据入湖。以上就是入湖相关的内容，Paimon 社区也对接了大量好用的入湖工具。

接下来介绍 Paimon 主键表的更新，前文介绍的主键表入湖，即首先 Create table 并且定义 Primary Key，之后就可以在这张表上进行流写更新以及 CDC 数据更新。更新支持的能力包括定义 Bucket 策略、定义压缩策略、更新方式，以及是否流读变更日志四个方面。

• Bucket 策略：在 Paimon 上定义的 Bucket 策略分为固定 Bucket 和动态Bucket，其中动态 Bucket 可能会占更多内存，但是可以保证 Bucket 的数量会根据数据量自动 Scale Down 或 Scale Up。同时 Paimon 也支持跨分区更新，在某些数据集上测试跨分区数据更新，其整体性能非常不错。

• 压缩策略：Paimon 默认是一种半异步、偏同步的压缩，可以开启全异步压缩，从而不会阻塞写操作，但可能会产生大量的增量数据，读取时需要更多的 Merge 操作，这样读取速度会变慢，但写操作永远不会阻塞。

• 如何更新：默认的更新方式是去重，即定义主键后，默认保留最后一条。另外也可以在表上定义 'merge-engine' = 'partial-update'，可以实现部分列更新。同时还可以定义聚合更新 'merge-engine' = 'aggregation'，即定义每个字段是如何聚合的，在某些场景下，可以低成本进行 AGG 计算。最后通过指定 'merge-engine' = 'first-row'，可以保留同一主键的第一条，该 Engine 在日志数据去重方面有着独特的作用，因为对于日志数据而言，只需要第一条就够了，这样整体性能也会更好。

• 是否流读变更日志：变更日志可以使流作业更加准确，但同时也会带来较大的开销，所以默认情况下是不会产生变更日志的，只是更新操作的话开销会小很多。如果确实需要产生变更日志，例如来自 CDC 的数据，可以选择输入即变更。如果变更要求时效性在一分钟左右，可以通过 Lookup 产生变更，即通过指定 'changelog-producer' = 'lookup'。如果时效性要求是十分钟以上，就可以选择 Full  压缩，即通过指定 'changelog-producer' = 'full-compaction'。

以上是主键表更新的整体情况，在此基础上可以通过 Flink 或者 Spark 完成更新操作，之后可以用各种生态的引擎进行查询，例如 Flink、Trino（原 PrestoSQL）、Spark、StarRocks、Hive、Doris、Presto 等，目前也在持续推进这些引擎的查询性能。

3. Paimon 日志表

接下来介绍 Paimon 日志表，即没有定义 PK 的表。会介绍日志表适用于哪些场景，以及一些性能的提升。

去年上半年的时候，还没有推出日志表这个模式，从去年下半年到今年越来越多的公司开始使用 Paimon 日志表去做一些例如纯批读批写的场景，包括 Hive、Spark 读取，还有一些公司像汽车之家会优化对 HDFS NameNode 的访问压力，相对 Hive 的存储能减少 NameNode 的访问压力。

Paimon 日志表也可以用于流写流读的场景，能起到 Queue 的作用，如果可以接受分钟级的延迟，完全可以代替昂贵的 Queue，并且可以把数据沉淀下来，当然这些功能目前没有非常稳定。更稳定可靠的功能是在日志表上完成 Z-order 排序，再对接高性能 OLAP 系统，例如在阿里的业务中，会利用日志表的 Z-order 排序，提高压缩率的同时后续也能进行高性能查询。在阿里内部对接了 StarRocks，进行查询的时候根据其 Filter 以及文件的 Z-order 排序，能够达到非常好的 Data Skipping。

Data Skipping 技术是利用列统计数据对所需要的数据文件做 file pruning（文件裁剪），常见的列统计数据包括取最大值、最小值、数量、大小等。Data Skipping 的作用就是通过这些统计数据来排除掉不需要读的文件，这样可以极大地提高查询速度。在数百 TB 的数据上可以完成非常高效的秒级查询，因此面向很多 OLAP 的场景性能会非常好。

4. Paimon 管控

接下来介绍 Paimon 管控方面的内容，主要包括 Snapshot+Tag、系统表、Procedures 以及 Metrics 四方面内容。

Paimon 的一个基本概念是 Snapshot 版本管理，在 Flink Checkpoint 时 Paimon 会产生 1～2 个 Snapshot，这取决于 Paimon 在这个过程中是否有进行过 Compaction，但至少会产生一个 Snapshot 来作为新的数据版本，通过定义Checkpoint Interval 来控制 Snapshot 的生成，也可以定义Snapshot 的 Expired Time。在某些 Snapshot 上面可以打 Tag，防止删除该 Snapshot 中的数据，也可以通过 Time Travel 随时读取该 Tag 的数据。通过 Tag 技术可以取代 Hive 全量分区表的功能。基于 Tag 和 Snapshot，再加上基于主键表的 LSM 特性，有些企业基于 Tag 来提供视图的方式，最大化地复用文件，减少存储。

Paimon 提供了非常丰富的系统表，可以查看内部结构，可以通过 Flink、Spark、Trino、Presto 查询这些系统表。

（3）Procedures

Flink 和 Spark 都提供了大量丰富的 Procedure，可以手动管理 Paimon 表。

（4）Metrics

在较新的版本中，Paimon 提供了大量的 Metrics，包括读、写、Compaction 等，通过这些 Metrics 可以监控作业的健康情况并用于性能优化。

以上大致回顾了 Paimon 去年完成的一些工作，以及基本概念和现有能力。接下来介绍 Paimon 后续规划的一些功能，其中大多数已经落地或已经完成了大部分工作，将可以在未来的版本中体验到。

03

1. Paimon 主键表：查询加速

首先来看 Paimon 主键表的查询，下图是大致的示意图。

Paimon 通过 Snapshot 来管理 Manifest，而 Manifest 管理下面的 Files，数据文件按分区（Partition）和桶（Bucket）分组。一个 Partition 中有多个 Bucket，每个 Bucket 都包含一个单独的 LSM Tree，Files 个数也不尽相同。

上面介绍的这个结构适合更新，不适合查询，因为 LSM 中有 Overlap 以及多层，需要合并，但是一个 LSM Tree 只能有一个单并发进行读取操作。所以在生产环境中如果 Paimon 的查询性能比较差，很可能是 Bucket 数量设定少了，读取并发比较低，这样会导致性能比较差。在之前的实践中，扩大了 Bucket 的个数，这样读取时并发就会增多，而真正花在 Merge 上的时间并不多，并发增加后，也就整体提升了读的性能。之前建议 Bucket 中的数据量应该在 1GB 至 10GB，现在建议是 400MB，以能够达到更高的读取性能。但这样会在更新时产生更多的小文件，相对对象存储而言，对 HDFS 中的 NameNode 压力会更大。其实影响主键表查询性能的根本原因在于增量和全量的合并，如下图所示：

如何在读取时不进行合并操作，上图所示的一种方案叫做 Deletion.Vectors，在做写操作或更新数据时，先查好哪些 File 的数据行被删除了，这样在读取时可以直接读 Deletion.Vectors，过滤相应的数据，从而避免多文件交互 Merge，每个文件即一个并发，使得读取操作效率最大化，类似前文提到的日志表的读取，没有并发限制。上图左半部分展示了在该模式下如何更新和删除数据，删除文件用于标记原始文件的删除。对于 Delete 和 Update 操作，老的数据被标记为已删除，上图所示是 pk=2 的数据，在 LSM 树中新的 L0 或者 L1 有最新的数据，而老数据已经被删除，所以不需要 Merge 操作。

整个流程如上图右下部分所示，即如何结合 LSM 和 Deletion.Vectors。LSM 树分为多层，新数据到来后，可能要做 Compaction，这个过程中会把老的文件删除，然后写新的文件，同时也会去查询 LSM 高层的数据，并删除高层数据所在的行，之后就会产生 Deletion.Vectors。其中的关键技术点在于结合 LSM，在写操作特别是流写的时候，需要非常高效的 Lookup 操作，Paimon 在 Lookup 方面也做了很多优化来保证高性能 Lookup。由于 LSM 这种特殊的结构，结合强大的 Lookup 能力，才可以找到哪些 Record 被删除，所以在流写的同时产生对应的 Deletion.Vectors。

按照这种方式，可以跟 OLAP 引擎（特别是向量化、SIMD 类的查询系统）做更深入的集成，例如 StarRocks、Doris 这样的引擎可以做原生对接，用 C++ 的方式来对接，所以性能会非常好。

关于 Deletion.Vectors 如何存储的问题，也进行过很多调研。Iceberg V2 有 Delete File 的方式，但是其组织结构是 Per Record 即删除一行，每新增一个 Record，这个 Record 就代表哪个 File 的哪一行被删除。在读取时会有比较大的问题，因为读取时需要查找到某个 File 对应的哪些行被删除，所以需要读取对应的 Delete Files，并过滤找出哪些行被删除了，这个过程比较复杂，需要比较深入的工程能力。Delta 采用了另外一种方式，即不存储哪些行被删除，而是直接存储某个文件的 Bitmap，这个 Bitmap 用于标明哪些行被删除，在查询时就无需查找 Data File 中哪些数据被删除了，直接去读取对应的 Bitmap 就可以了。在 Paimon 的设计中，也是采用了跟 Delta 比较类似的方式，来保证查询端的性能。

2. Paimon 主键表：流读 Changelog 分离

接下来介绍主键表的流读，阿里目前上线了非常多的偏向于 Streaming LakeHouse 的业务，其中要求 Lake Format 有很强的写能力以及流读能力，甚至在流读方面能够完全替代消息队列。

在数据湖中，无论是 Hudi 的 TimeLine 还是 Iceberg 和 Paimon 的Snapshot，以及 Delta 中的 DeltaLog，都有相关的版本管理机制，但是比较重，数据湖的 Snapshot 中不仅管理增量文件，同时也管理 Compaction 过程中的文件，如果需要保存长时间的 Change Log 和 Snapshot，存储量会变得很大。

为了解决这个问题，Paimon 与蚂蚁合作，把 Change Log 跟 Snapshot 管理进行了分离，当 Snapshot 需要被删除时，将其中的 Change Log 文件单独存放到新的存储空间进行管理，这样就可以将 Change Log 文件跟 Snapshot 原本数据分离，从而使 Change Log 的时间线或者说生命周期得到延长，例如 Change Log 可以存 3 天或者 1 周，同时 Snapshot 还可以 1 小时后过期，这样可以低成本地实现跟消息队列完全一致的体验。

3. Paimon 日志表：查询加速

前文介绍了主键表的优化改进，接下来介绍日志表的一个核心功能即索引机制。

上图所示的 Snapshot、Manifest、Datafile 的管理结构中，在 DataFile 层面可以构建索引，例如 Bitmap、Bloomfilter、倒排索引。这些索引是 File 粒度的，其中记录了字段在 DataFile 的哪些 Group 中，如果是 ORC 格式，对应的是 Stripe，一个 DataFile 会分为很多 Block。索引可以根据相关 Filter 条件来决定是否要读取某个 DataFile，以及读取 DataFile 的哪些部分。

如果索引太小，会被自动放置到 Manifest 中，在 Scan 阶段，就可以对文件进行过滤，过滤分为两层，一是 Scan 即生成 Plan 的过程，另外一个是真正的 Read 过程，如果在生成 Plan 的过程中就可以过滤更多文件，效果会更好。在之前的版本中，Paimon 在 Manifest 文件中已经自带 Minmax 索引，但是很多情况下是不够用的，所以进行了扩展。另外，Paimon 也会内置支持嵌套字段的索引，类似 Map Key，可以定义基于哪个 Map Key 去做索引，从而可以自动做 Filter 的裁剪。

其实无论是主键表还是日志表都需要查询加速，特别是结合类似 StarRocks 和 Doris 这样强大的高速 OLAP 引擎时，需要湖格式进行更好的适配，来支持各种场景，可以认为湖格式需要达到分钟级时效性，结合 OLAP 系统，提供跟 OLAP 系统内部表相同的查询速度，但是存储成本更低。

4. Paimon 日志表：增删改查

日志表另外一个改进是增删改查。之前的非主键表不支持 Delete、Update 以及 Merge into 操作，所以在 Paimon 日志表中，需要支持批处理的增删改查，具体的实现有下图所示的两种方式：Copy On Write（COW）和 Merge On Read（MOR）。

首先是 COW，即命中哪些文件，就去重写这些文件。MOR 需要结合前文主键表中提出的 Deletion.Vectors 机制，查询到哪些文件被删除，再去更新，而不是重写文件，仅更新对应的 Deletion.Vectors。

5. Paimon 日志表：Spark 持续优化

接下来介绍日志表中 Spark 集成的相关内容，主键表更多是面向更新场景，与Flink 集成更多一些，而日志表虽然有流写流读功能，但是更多还是面向传统批处理场景，所以 Paimon 在日志表的基础上做了大量跟 Spark SQL 相关的优化。

首先看下优化效果，如下图所示，对比了 Spark Parquet 内表，也可以认为是 Hive 的 Parquet 内表，并没有对比其他的湖格式。优化之前，Paimon 在 Spark SQL 上的查询性能低于 Parquet 内表，差不多两倍的 TPC-DS 查询时间。经过一系列优化后，Paimon 的读取性能跟 Parquet 基本可以持平，设置了列统计信息后，Paimon 的读取性能也基本追平了 Parquet 内表。

以上是 TPC-DS 查询性能，未来几个月，也会结合 Paimon 日志表的增删改查，在 Spark 上进行完整的实现。由于 TPC-DS 是一个很复杂的过程，它要求明确数据的 Ingestion，包括数据的增删改查，在 Delete，Update 之后才是查询，所以后续 Paimon 实现了日志表的增删改查后，会结合 SparkSQL 再去做完整的 Paimon+Spark 在 TPC-DS 上的整体测试。

上述优化的具体实现包括，动态分区裁剪，即根据 Filter 来做更好的动态分区裁剪，本质上是谓词下推的一种拓展；Exchange 复用，即 Sub-Plan 的复用，Exchange 是 Spark 物理计划中一个关键操作，对应逻辑计划中的 Shuffle，在执行阶段，Exchange 可以代表某个 SQL 中部分 Plan 输出的数据；动态调整 Scan 并发，Paimon 提供了基于当前作业的可用 core 数来动态调整数据源的数据分片能力，进而调整并发，从而提升查询效率；合并标量子查询，类似于 Exchange 复用，也是一种 Sub-Plan 的复用，合并标量子查询优化会遍历整个 SQL 逻辑执行计划，提取出标量子查询，尝试将多个标量子查询合并起来，使得仅执行一次子查询即可得到多个标量值；最后是 Cost-Based 优化。以上这些优化的具体实现可以参考 Paimon 代码或者相应 PR，都是在 Spark DataSourceV2 上实现的。

Spark 是一个非常开放、可自定义的引擎，可以在不同的 Data Source 上有足够多的空间来优化 Spark SQL 的执行，这些优化是在 Format 层面实现的，而不是 Spark SQL 内部。

6. Paimon 管控：Branch

最后介绍 Paimon 管控方面的改进，其中比较大的方面是字节正在推动的Branch。

之前按照正常的 Snapshot 机制，如上图所示的 S1、S2、S3、S4 这样一个顺序，如果做 Create Tag 操作即建立一个映射，如图所示映射到 S2，这样 S2 就不可以被删除，Tag（图中 T2）是不可变的，不可以做 Delete 和修改操作。所以在 Tag（T2）的基础上，扩展了 Paimon 的 Branch 能力，可以去 Create Branch，即基于 S2 的基础上 Create Branch，在 S2 的基础上继续修改，生成新的 S3、S4，这个跟主分支是完全独立的，可以使 Paimon 具备 Git 版本管理的能力，从主分支上创建其他分支。Branch 是可变可写的，可以非常方便地进行工程验证和测试。同时 Branch 在某些场景中也可以取代分区，因为分区的 Data File 是相互独立、无关的，Data File 可以被复用，从而达到分区可读可写。每个 Branch 会复用大量的文件，整体存储量也会降低，Branch 之间也支持 Merge 和 Replace 操作。

Branch 能力将会在 Paimon 0.8 版本进行基础发布，在后面 1.0 版本中会正式 GA。

以上是本次分享的全部内容。

04

Q1：Schema Evolution 时，如何做 Streaming Join 以及 AGG？

A1：如果用 FlinkSQL 的话，无法实现。因为 SQL 天然就是一个 Schema 固定的东西，无法通过 FlinkSQL 实现，解决方式有两种，一种是用 FlinkSQL  提供的版本升级能力，能在一些 AGG 和 Stream Join 中有这样一个添加字段的能力。当然另外一种方式，就是不要使用 FlinkSQL，自己写一个 Data Stream 作业。然后这个 Data Stream 作业里面的 Record 都是这种 Schema Evolution 的。可以参考 Paimon 的 CDC Record 这种方式来达到一个 Schema Evolution 动态的过程，可能比较难处理。所以这个问题的结论没有官方的 Schema Evolution 计算的支持，但是理论上是可以实现的。

Q2：Paimon 是否可以支持二进制文件直接入湖存储？

A2：如果是比较大的二进制文件，我的建议是不要入湖，不入湖格式。它本身就在湖上，把这个文件 Name 以及文件 Path 入湖即可。当然有些二进制文件，可以把整个 Binary 当成一个字段，能塞到这个湖格式当中也行，但是那种数据不建议太大。

Q3：Paimon CDC 是否计划和 Flink CDC3.X 整合？

A3：是的，这个整合已经在进行中了。Flink CDC 3.1 应该会推出 Paimon 的Sink。这个工作已经基本完成，现在只需要等待发布。

Q4：Paimon 0.6 升级到 0.7 有什么注意事项吗？

A4：目前了解到的注意事项是 Paimon 在 0.7 中关于 Flink Lookup Join 的优化，即不用去 Full Load 数据，可以直接基于 Paimon 的 LSM 来进行查询。这在性能上可能会有一些 TradeOff。如果觉得有性能差异，性能变差了，可以在群里面反馈，也可以通过 Option 把这个功能关闭，进行回退。另外 Paimon 对每个版本都是向前兼容的，在格式上不用做任何操作。

Q5：Paimon Metrics 监控有推荐的 Grafana 模板吗？

A5：暂时没有。这个还需要一个过程，但是这是个非常好的问题。我觉得后面当Metrics 大致固定之后，我们可以在社区提供这样一个 Grafana 模板。

Q6：StarRocks 在哪个版本当中查询 Paimon 性能最好？

A6：就是在 3.2.2 当中，也就是最新的版本当中。

Q7：使用 FlinkSQL 批写日志表时，无论设置多少并发，只有五个并行度在执行，可能是什么原因？

A7：我认为最大的原因可能是你的日志表 Bucket 应该等于 -1，你是不是设置了 Bucket 的个数。关于日志表，如果没有保序的需求，我们现在推荐最好只设 Bucket 等于 -1，在此模式下不再有桶的概念，也不保证流任务读取数据的顺序。其实 Bucket 的这个配置，在还没有发布的最新版本 0.8 中，Bucket 的值已经默认等于 -1 了。但是在老的版本当中，Bucket 默认值是 1，这就意味着一个分区只有一个 Writer 在干活。所以大概率原因就是 Bucket 值的问题，可以尝试设Bucket 等于 -1，或者升级到最新的 0.8 版本，并重新建一下表。

Q8：Change Log 可以快速恢复某个过期点的 Snapshot 吗？

A8：不可以。如果想恢复 Snapshot，需要 Roll Back to Snapshot，必须是一个Snapshot，不能是 Change Log。

Q9：请问拉出来的 Branch 怎么汇合呢，尤其是更新流？

A9：前面有提到，Merge Branch 和 Replace Branch 都要有。但是 Merge Branch 的语义难度可能会更大。比如说两边都更改了很多数据，如果有冲突，就无法 Merge。比如更改的文件跟这个 Branch 更改的文件完全不一样，这个时候才有 Merge 的可能，否则只能 Replace Branch 了。

Q10：Branch 中既然 S3 跟 S3` 是完全独立的，为什么它们的 DataFile 还是共享的？

A10：S3 和 S3` 都是对之前 Snapshot 的改动，S2 是完全共享的，但是 S3 这里可能增加了两个 File，删除了两个 File。S3` 可能也增加了另外的两个 File，删了其他的两个 File，但是它们的 base 文件还是复用的。

A11：刚刚也讲过了，Merge Branch 其实是一个非常复杂的过程，有冲突 Merge 是要失败的。

A12：确实是 SparkSQL 跟 Paimon 的结合会更好一些，比 ODPS 更好。因为Spark 尽可能开放了其优化规则到存储级别，可以自定义。

Q13：Paimon 后续会扩展更多类型的 Catalog 吗？

A13：会的，目前已经 Merge 进了 JDBC 的 Catalog，后续我们就会开启 Rest Catalog，去对接更多的 Catalog 的方式。

Q14：把 Paimon 的数据写到 StarRocks 再查询数据，比直接查 StarRocks 更快吗？

A14：那肯定是更快的，不管是 StarRocks 也好，还是 Doris 的内表也好，一般来说，内表在大部分情况下肯定比外表快。外表如果有大量索引也不一定，外表想要达到的效果是尽可能和内表类似的快，而且不用再导一遍数据到 StarRocks 中。此外，外表这种湖存储使用更便宜的存储介质，而内表会需要更贵的 SSD 存储。

Q15：集成 Hive 时增加表字段的功能已经有了吗？

A15：已经有了。

A16：其实无论 Streaming 还是实时更新，这些都是 Paimon 的特点。Paimon 不是跟 Flink 强相关的，Paimon 与 Flink 和 Spark 都有着比较好的集成，如果是流处理方面 Flink 肯定是更擅长的，如果是批处理，比较推荐用 Spark。

Q17：Flink 实现流写和批写同一个 Paimon 表时，需要注意什么？

A17：可以看一下 Paimon 的文档，两个作业同时写的话，如果写相同的分区，相同的数据，可能需要去起独立的 Compaction 作业，这样才能减少冲突。

Q18：Paimon 外键关联有计划支持吗？

A18：外键关联暂无计划。而且 Paimon 目前只支持主键打宽，不支持外键打宽。

Q19：Paimon 实时写推荐的批大小是多少？

A19：Checkpoint 的延迟推荐是 1 分钟以上。

Q20：数据可见性与 Queue 相比还有哪些差异？

A20：主要是时效性的差异。Queue 的话能达到毫秒级的时效性，而对于湖存储，一般来说 1 分钟或者 30 秒就是极限了。

Q21：支持对列加索引吗？是列式存储吗？

A21：是列式存储，对于日志表查询加速，DataFile 加索引就是针对列的。比如说要加一个 Bitmap 或 Bloomfilter 或者倒排索引，一定是对某一列加这个索引，Paimon 支持灵活加删索引。