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

举个例子:

1
2
3
4
5
6
7
8
9
10
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 写入过程中定期执行全量合并,这样可以确保在写入结束之前对分区进行完全合并。

×

纯属好玩

扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

文章目录
  1. 1. 管理小文件
  2. 2. 理解 Checkpoint
  3. 3. 理解 Snapshot
  4. 4. 理解 分区 和 Buckets
  5. 5. 理解 Primary Table 的 LSM
  6. 6. 理解 Append-Only 表的文件
  7. 7. 理解 Full Compaction