Apache Paimon 文件管理

管理小文件

许多用户关注小文件问题，可能导致以下情况：

稳定性问题：HDFS 中如果存在太多小文件的话会导致 NameNode 压力过大
成本问题：在 HDFS 中，每个小文件都会占用至少一个数据块的大小，例如 128 MB
查询效率：查询过多小文件会影响查询效率

理解 Checkpoint

假设你正在使用 Flink Writer，每个 Checkpoint 会生成 1 ～ 2 个 snapshot，并且 Checkpoint 时会强制将文件生成在分布式文件系统（DFS）上，因此 Checkpoint 间隔越小，生成的小文件就越多。

1、所以先要增加 Checkpoint 间隔时间

默认情况下，不仅 Checkpoint 会生成文件，写入器（Writer）的内存（write-buffer-size）耗尽时也会将数据刷新到 DFS 并生成相应的文件。你可以启用 write-buffer-spillable 在写入器中生成溢出文件，以生成更大的文件在 DFS 上。

2、其次增加 write-buffer-size 或启用 write-buffer-spillable

理解 Snapshot

Paimon 维护文件的多个版本，文件的合并和删除是逻辑上的操作，并不实际删除文件。只有在 snapshot 过期时，文件才会真正被删除，所以减少文件的一种方法是缩短 snapshot 过期的时间。Flink Writer 会自动处理过期的 snapshot。

理解分区和 Buckets

Paimon 的文件以分层方式组织。下图展示了文件布局。从 snapshot 文件开始，Paimon 的读取器可以递归地访问表中的所有记录。

举个例子：

go 复制代码

CREATE TABLE MyTable (
    user_id BIGINT,
    item_id BIGINT,
    behavior STRING,
    dt STRING,
    hh STRING,
    PRIMARY KEY (dt, hh, user_id) NOT ENFORCED
) PARTITIONED BY (dt, hh) WITH (
    'bucket' = '10'
);

表数据会被物理分片到不同的分区，里面有不同的 Bucket ，所以如果整体数据量太小，单个 Bucket 中至少有一个文件，建议你配置较少的 Bucket 数量，否则会出现也有很多小文件。

理解 Primary Table 的 LSM

LSM 树将文件组织成多个 sorted run。一个 sorted run 由一个或多个数据文件组成，每个数据文件都属于且仅属于一个 sorted run。

默认情况下，sorted run 的数量取决于 num-sorted-run.compaction-trigger 参数，这意味着一个Bucket 中至少有 5 个文件。如果你想减少这个数量，可以保留较少的文件，但写入性能可能会受到影响。如果该值变得过大，在查询表时会需要更多的内存和 CPU，这是写入性能和查询性能之间的权衡。