1.Append Scalable Table
a) 定义
在表属性中配置 ‘bucket’ = ‘-1’,将进入 “unaware-bucket mode”,在此模式下不再有桶的概念,也不保证流任务读取数据的顺序,可以将此表视为批量离线表,所有记录都将进入一个目录(为了兼容性,把它们放在bucket-0中),不再保持有序同时不再按bucket shuffle将加快数据的插入速度。
使用这个模式,可以替换Hive table为lake table。
b) Compaction
在 “unaware-bucket mode” 下,不在writer中进行compaction,而是使用Compact Coordinator去浏览小文件提交compaction任务到Compact Worker中。
在流模式下,如果在flink中运行insert sql,拓扑将如下:
Compact Worker将尽最大努力压缩小文件,但当一个分区中只有一个小文件,并且没有向分区添加新文件时,Compact Coordinator
会将其从内存中删除,以减少内存使用量。
重新启动作业后,它将扫描小文件并再次将其添加到内存中,如果将write-only
设置为true,Compact Coordinator
和Compact Worker
将在拓扑中删除。
自动压缩仅在Flink引擎流模式下支持,可以通过paimon中的flink操作在flink中启动压缩作业,并通过设置write-only
禁用其它压缩。
c) Sort Compact
如果每个分区的数据是无序的,那么查询速度将变慢,然而聚合又将会影响插入性能,因此对于只inserting的job,可以设置write-only,当分区的数据插入完毕后,再触发一次分区的 Sort Compact
。
d) Streaming Source
在 “unaware-bucket mode” 下,append table支持流读写,但不再保证顺序,不能把它看成一个queue,而是一个lake。
每个commit都会生成一个新的record,通过读取新的record来读取增量数据,但读取它们可能是无序的。
e)Streaming Multiple Partitions Write
Paimon-sink处理的写入任务数量是:写入数据的分区数量*每个分区的桶数量。
需要控制每个paimon-sink任务的write tasks数量,如果每个sink任务处理太多的write tasks,不仅会导致太多小文件问题,还可能导致内存不足。
而且写入失败会引入孤儿文件,增加了维护paimon的成本。
对于启用auto-merge的flink-jobs,建议遵循以下公式来调整paimon-sink的并行度:
(N*B)/P < 100N(写入数据的分区数)B(桶数量)P(paimon-sink任务的并行度)100(这是一个经验推导的阈值,对于禁用auto-merge的flink-jobs,此值可以降低。)
将write-buffer-spillable
设置为true,writer可以将record溢写到磁盘,可以减少小文件数量;要使用此选项,需要为flink集群设置一定大小的本地磁盘。
为append-table设置write-buffer-for-append
选项,将此参数设置为true,writer将使用Segment Pool缓存records,以避免OOM。
CREATE TABLE MyTable (product_id BIGINT,price DOUBLE,sales BIGINT) WITH ('bucket' = '-1');