湖仓表“每天数据都写成功”，不代表它运行健康。流式任务持续产生小文件，快照和 manifest 逐渐膨胀，失败作业留下未引用文件。查询开始变慢、Catalog 元数据增大时，团队才临时跑一次全表 compaction。

这种做法把表维护当清洁脚本，实际上它和写入、查询一样是持续服务。维护延迟会积累运行负债，维护过猛又会抢资源、制造提交冲突甚至误删在途文件。它需要自己的 SLI、SLO、容量和变更治理。

Iceberg 表能被 Spark 和 Flink 正常读写，只能证明接入完成，不能证明可以长期运行。流式任务每天产生几百个 snapshots，小批写入不断增加 data files，失败任务留下 orphan files，time travel 保留策略又阻止旧文件回收。三个月后，表仍能查，但规划越来越慢，存储账单一直涨，维护脚本谁也不敢改。

我认为平台真正要补的是表级运维闭环：从 metadata tables 读取健康信号，按每张表的负载和 SLA 选择维护动作，记录提交与删除证据，再验证查询和成本是否改善。它不是几条全局 cron，而是和写入一样正式的生产链路。

很多团队第一次治理小文件，会加一个凌晨两点的 Spark 脚本：扫描昨天的分区，把文件合到 512 MB。刚上线时效果明显，过一阵又会遇到任务跑不完、与实时写入冲突、刚合完第二天又碎了，最后脚本变成一个没人敢停的定时黑盒。

我更愿意把 Compaction 看成表的持续维护服务。它不是“每天执行一次重写”，而是一条有输入指标、候选选择、预算、提交证据和效果验收的控制循环。表什么时候需要整理、整理哪部分、允许花多少资源、失败后如何继续，都应该可计算。