Paimon生产环境问题小总结

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

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

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

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

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

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

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

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

  1. Checkpoint interval:推荐在1-2min比较合适(这是很多公司的场景给出的推荐参数,但是根据个人实践情况来看,这个频率有些高,实际上3-5min或者更长一点时间更为合理);

  2. WriteBuffer大小:推荐使用默认值,如果你的数据规模比较大,那么可以适当增加增加write-buffer-size或开启write-buffer-spillable选项,这样溢写到HDFS上生成的文件更大。

  3. 业务数据量:根据业务数据量调节Bucket数,调整依据为单个Bucket大小在1G左右合适(可以稍高一点);

  4. Key的设置:根据实际的业务Key特点设置合适的Bucket-key、Partition,防止热Key倾斜问题;

  5. 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了。

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

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

更多Paimon相关文章:Paimon博客园 | 巨人肩膀

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值