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 CoordinatorCompact 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');