本文主要总结一下过去使用Paimon的过程中遇到的一些问题，在这个过程中参考了官网、各大云平台的文档，以及参考了大量Gituhub和社区讨论的内容。

Paimon社区还在高速发展中，本文仅当成一个速查笔记，后续会持续更新。如果你需要可以收藏或者加一个星标。

以下是遇到的问题列表，以及常见的解决方案，针对不同的版本或者使用场景可能略有不同，大家可以自己尝试。

小文件问题导致的反压/阻塞

小文件问题基本是所有的大数据存储和计算框架都会遇到的问题，Paimon也不例外。

我们以Flink写Paimon举例，在小文件场景中，产生小文件主要有两方面导致，一是进行Checkpoint的时候会强制把当前的WriteBuffer的数据刷到磁盘上，二是WriteBuffer本身满了也会刷到磁盘上。

所以如果Checkpoint Interval过小，或是WriteBuffer容量设置的过小，数据就会更频繁的被刷到磁盘上，而产生过量的小文件。

此外Bucket key设置的不合理也会导致过多的小文件，根据阿里和字节分享的多篇实践文章来看，小文件参数设置：

Checkpoint interval：推荐在1-2min比较合适(这是很多公司的场景给出的推荐参数，但是根据个人实践情况来看，这个频率有些高，实际上3-5min或者更长一点时间更为合理);
WriteBuffer大小：推荐使用默认值，如果你的数据规模比较大，那么可以适当增加增加write-buffer-size或开启write-buffer-spillable选项，这样溢写到HDFS上生成的文件更大。
业务数据量：根据业务数据量调节Bucket数，调整依据为单个Bucket大小在1G左右合适(可以稍高一点)；
Key的设置：根据实际的业务Key特点设置合适的Bucket-key、Partition，防止热Key倾斜问题；
Compaction相关参数：优先使用默认值。这里有一个注意的点，生产环境是比较推荐开启异步Compaction的，可以通过下面三个参数开启：

'num-sorted-run.stop-trigger' = '2147483647',  -- 极大值，减少写入暂停'sort-spill-threshold' = '10',                  -- 防止内存溢出'changelog-producer.lookup-wait' = 'false'      -- 禁用同步等待，实现异步

写入性能不足，导致任务反压

Flink+Paimon的写优化是一个比较庞大的话题，涉及参数很多，可以优化的点非常多。

但是我们有一个大致的思路，除了解决小文件过程中的compaction优化。还可以从下面几个方面优化：

并行度设置上，Paimon的写入并行度与桶数量密切相关，所以sink的并行度最好等于bucket的数量；
开启本地合并（Local Merging），在数据按桶分区之前对输入记录进行缓冲和合并，可以从从64MB开始调整，逐步优化；
选择合适的文件编码和压缩格式。

内存不足OOM或者GC频繁

内存不足从日志表现上来看可能是：Caused by: java.lang.OutOfMemoryError: Java heap space 或者 GC overhead limit exceeded，解决办法就是增加TM的堆内存。

此外还有一种情况是，Paimon表的单个Bucket数据量过大，原因大概率是分桶键选择不合理，致大量数据集中在少数分桶中，引起OOM。

如果是分桶数量过少可以，重新增加分桶，并且对存量数据进行rescale。

File deletion conflicts detected! Give up committing.

快照或者文件冲突。

这是一个经典的多任务写同一张表的问题，这个问题机制比较复杂（感兴趣可以看github对应的issue），我们不做过多讨论，社区目前正在修复这个问题。

我们大致解释一下场景，在很多情况下，我们需要离线和实时任务写同一个Paimon表，这时候就出现一个问题，离线和实时任务同时会进行compaction+commit，然后就会出现文件冲突。

比较推荐的解决方案是，离线和实时任务同时开启write-only=true,单独启动一个任务只执行compaction。

维度表关联性能问题

Paimon的主键表是可以作为维度表进行look up关联的，但是在大流量场景也会成为瓶颈。

有几个常用的优化手段可以参考：

(异步)延迟重试

重试是一把双刃剑，可以根据实际情况酌情考虑；

动态分区

Paimon有max_pt函数可以只读最新分区数据，在性能上帮助有限；

缓存

Paimon给我们提供了部分缓存('lookup.cache'='auto')和全部缓存('lookup.cache'='full')两种策略。如果你的参数满足下面的条件

- 关联表为固定分桶模式的主键表- 关联表表的主键和Join Key一致

如果满足上面条件，Paimon会自动选择部分缓存（Partial Cache）模式。不满足会选择全部缓存(Full Cache)模式。当然full cache会带来冷启动问题。

此外，在很多云平台产品上都提供了Bucket Shuffle功能，原理是在开启Bucket Shuffle后，会根据Join Key进行Hash分组处理，每个分组中只要缓存对应Bucket 数据，可以极大减少内存用量，减少了缓存淘汰的概率，就可以支持更大规模的维表。

FileNotFoundException

在读取Paimon表的过程中经常出现的问题之一，原理是Paimon表的Snapshot、Changelog默认过期时间是1小时，如果下游流读的作业延迟超过1小时或者断流超过1 小时，则会有上述报错。可以通过修改snapshot.time-retained增大这个时间。

写入和查询性能trade off，性能问题

这是Paimon新版本中解决的一个问题。

在Paimon这个框架中(其实不只Paimon，很多框架都有这个问题)，提供了两种模式MOR和COW，MergeOnRead 模式下，更新速度很快，但查询速度较慢；而CopyOnWrite 模式下，更新速度较慢，但查询速度较快。

这时候问题就来了，如果用户期望写入更新速度快，查询速度也不慢。那该怎么做呢？

从Paimon的0.8版本开始，引入了Deletion Vectors。一句话总结就是MOR模式下通过写时标记老文件哪些行被删除，实现快速更新，且不影响查询性能。

如果你同时都写入和查询性能要求都比较高，那么就可以考虑Deletion Vectors了。

上面就是这次整理的线上问题小总结，当然生产环境中的问题千奇百怪，无法穷举，我们先整理这些，后续再持续更新。

文章内容来自公众号：大数据架构与技术