湖表合并任务的调度
湖表（Iceberg、Hudi、Paimon）的小文件与提交元数据要靠合并（compaction）维护。调度上按分区优先级安排：优先处理查询频繁、文件数集中的分区，同时配合快照过期与孤立文件清理控制元数据体积。只清理不合并，查询仍要扫描大量小文件，维护等于白做。
基本信息
| 维护目标 | 小文件数与元数据体积 |
|---|---|
| 优先级 | 按查询热度与文件数 |
| 执行窗口 | 业务低峰期 |
| 配套动作 | 快照过期、孤立文件清理 |
| 观察指标 | 分区文件数与平均文件大小 |
典型使用场景
- 首次接入湖表：对历史分区做一次重写，把累积的小文件收敛到目标大小
- 日常调度：当日分区文件数或平均大小越界时触发合并，冷分区低频处理
- 快照过期：按保留时长清理旧快照，控制元数据体积与列举开销
- 孤立文件清理：回收写入失败、回滚后遗留的无引用文件
- 排查查询变慢：先看分区文件数与平均文件大小，再确认合并任务是否在正常执行
Iceberg 维护动作
Iceberg 维护动作
-- 重写数据文件：按目标大小合并小文件
CALL demo.system.rewrite_data_files(
table => 'db.trade_order',
options => map('target-file-size-bytes', '134217728') -- 目标 128MB
);
-- 过期旧快照，控制元数据体积
CALL demo.system.expire_snapshots(
table => 'db.trade_order',
older_than => TIMESTAMP '2026-10-11 00:00:00.000',
retain_last => 10
);
-- 清理无引用文件，older_than 必须早于最长写入任务时长
CALL demo.system.remove_orphan_files(table => 'db.trade_order', older_than => TIMESTAMP '2026-10-11 00:00:00.000');维护动作与风险
| 动作 | 作用 | 风险点 |
|---|---|---|
| 合并小文件 | 降低文件数，提升扫描效率 | 占用 IO，需低峰执行 |
| 快照过期 | 控制元数据体积 | 过期过早失去时间旅行能力 |
| 孤立文件清理 | 释放无效存储 | 安全窗口过短会误删在写文件 |
| 按分区重写 | 提升过滤与裁剪效率 | 重写成本高，宜分批 |
孤立文件清理的安全时间窗必须大于最长写入任务的时长，否则会删掉仍在提交过程中的文件，导致提交失败甚至表状态异常。
合并效果要从元数据侧验证：跟踪分区文件数、平均文件大小与查询耗时的变化趋势，只看任务成功与否无法判断维护是否真的起作用。