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 < 100
N(写入数据的分区数)
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'
);
