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 的读取器可以递归地访问表中的所有记录。

举个例子：

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，这是写入性能和查询性能之间的权衡。

理解 Append-Only 表的文件

默认情况下 Append Only 表也会进行自动合并以减少小文件的数量。

然而，对于 Bucket 的 Append Only 表来说，它会出于顺序目的而只压缩 Bucket 内的文件，这可能会保留更多的小文件。

理解 Full Compaction

也许你认为 Primary Key 表中的 5 个文件还可以接受，但 Append Only 表（Bucket）可能在一个单独的 Bucket 中就会有 50 个小文件，这是很难接受的。更糟糕的是，不再活跃的分区也会保留这么多小文件。

建议你配置全量合并（Full-Compaction），通过设置 full-compaction.delta-commits参数，在Flink 写入过程中定期执行全量合并，这样可以确保在写入结束之前对分区进行完全合并。

Apache Paimon 相关文章：

Apache Paimon 介绍

Apache Paimon 基础概念

Apache Paimon 文件布局设计

Apache Paimon 文件操作

Flink Table Store ——从计算到存储提升流批统一端到端用户体验

​