元数据管理：膨胀原理、垃圾回收与表优化

Iceberg 的元数据，说白了就是表的「操作日志」加「快照索引」。每次写入、删除、合并，都会生成新的元数据文件。时间一长，这些文件就会像滚雪球一样膨胀起来。

我刚开始用 Iceberg 时，就踩过这个坑。一张每天增量写入的表，跑了三个月，元数据目录里堆了上千个文件。查询倒是没慢多少，但 NameNode 的 RPC 压力直接飙升，因为每次打开表都要扫描一大堆元数据文件。

这一节，我们就来拆解元数据膨胀的根因，然后给出清理和优化的实操方案。

2.1 元数据膨胀原理

Iceberg 的元数据结构分三层：Catalog → Metadata File → Manifest List → Manifest File。每次提交（commit）都会产生一个新的 Metadata File，里面记录了当前快照的所有 Manifest 信息。

为什么会膨胀？三个核心原因：

• 快照堆积：每次写入、删除、合并都会生成新快照。默认情况下，Iceberg 不会自动清理历史快照。
• Manifest 碎片化：小文件写入频繁时，每个 Manifest 只记录少量数据文件，导致 Manifest 数量激增。
• Metadata 文件冗余：每个快照对应一个完整的 Metadata File，即使只改了一行数据，也会复制整个元数据树。

我见过最夸张的情况：一张表每天有 200 次小批量写入，一个月后元数据文件超过 6000 个。打开表需要扫描所有 Metadata File 来定位最新快照，耗时从毫秒级退化到秒级。

2.2 元数据垃圾回收

垃圾回收的核心目标：删除不再需要的 Metadata File 和 Manifest File。但要注意，不能删正在被查询引用的文件。

Iceberg 提供了两个内置机制：

机制	作用	触发方式
expireSnapshots	删除指定时间之前的旧快照及其关联的 Manifest 和数据文件	手动调用或定时任务
removeOrphanFiles	清理元数据中不再引用的孤立数据文件	手动调用或定时任务

实际操作中，我建议这样配置：

-- 保留最近 7 天的快照
CALL catalog.system.expire_snapshots(
  table => 'db.my_table',
  retain_last => 7
);

-- 清理超过 3 天的孤立文件
CALL catalog.system.remove_orphan_files(
  table => 'db.my_table',
  older_than => '2024-01-01 00:00:00'
);

我曾经在生产环境遇到过一个问题：执行 expireSnapshots 后，HDFS 空间没有释放，因为 Trash 目录里还保留着这些文件。后来我加了一步：在 expire 之后，手动清空 Trash，或者直接跳过 Trash 删除。

2.3 元数据表优化

除了清理垃圾，我们还需要主动优化元数据的结构。核心手段有两个：RewriteManifests 和 Compaction。

2.3.1 RewriteManifests

这个操作会把多个小 Manifest 合并成一个大 Manifest，减少元数据文件数量。同时，它会对 Manifest 内的条目进行排序，提升查询时的过滤效率。

CALL catalog.system.rewrite_manifests(
  table => 'db.my_table',
  options => map('rewrite-all', 'true')
);

参数说明：

参数	默认值	说明
rewrite-all	false	是否重写所有 Manifest，还是只重写小文件
min-input-files	5	触发重写的最小 Manifest 数量
target-file-size-bytes	67108864 (64MB)	合并后的目标 Manifest 大小

2.3.2 数据文件层面的 Compaction

元数据膨胀的根源，很多时候是数据文件太小、太多。所以，合并小文件是治本之策。

CALL catalog.system.rewrite_data_files(
  table => 'db.my_table',
  strategy => 'sort',
  sort_order => 'col1 ASC, col2 DESC',
  options => map(
    'min-input-files', '10',
    'target-file-size-bytes', '268435456'
  )
);

这个操作会把小文件合并成 256MB 左右的大文件，同时按指定列排序。好处很明显：

• 元数据文件数量减少：每个 Manifest 能记录更多数据文件
• 查询性能提升：排序后的数据在过滤时能跳过更多分区
• 存储效率提高：减少小文件带来的 HDFS 块浪费

2.4 元数据优化流程图

下面这张图总结了元数据优化的完整流程，从诊断到执行再到验证：

2.5 避坑指南与最佳实践

最后，分享几个我在实战中总结的经验：

• 不要一次性清理太多快照：我曾经一次性删除了 90 天的快照，结果导致正在运行的流式作业找不到历史状态，直接报错。建议每次保留至少 7 天的快照。
• 定时任务要加锁：如果多个任务同时执行 expireSnapshots 和 rewriteManifests，可能会产生冲突。我用 ZooKeeper 或数据库锁来保证同一时间只有一个优化任务在运行。
• 监控元数据增长趋势：在 Grafana 里加一个面板，每天记录元数据文件数量。一旦发现增长曲线变陡，就要排查写入频率是否异常。
• 小文件写入要尽早合并：如果业务允许，尽量在写入端做 batch，减少单次写入的数据量。实在不行，就缩短 rewriteDataFiles 的执行周期。