架构评审会上，最容易出现一句没法反驳的话。
“Iceberg 是趋势，我们迟早要迁。”
这句话大概率没错。它的问题是，对下周要不要动那张交易明细表没有帮助。
一张表值不值得先迁，不取决于技术名字够不够新，而取决于三个更具体的问题：旧问题有多贵，新方案能省多少，出问题时能不能退回来。
我见过不少迁移方案，前两部分写得很厚：架构图、组件版本、目标状态。到了回滚，只剩四个字：“必要时回退。”
必要是什么时候？回到哪里？期间的新数据怎么办？没人写。
所以这篇文章不再介绍 Iceberg 是什么。我们直接做一张迁移决策表。
第一部分：旧问题到底花了多少钱
先别写“当前架构存在性能瓶颈”。这种句子放进任何方案都成立，也因此几乎没有信息。
把候选表最近 7–30 天的现状填成数字。
1. 文件与元数据
记录：
- 文件总数；
- 每日新增文件数；
- 文件大小中位数与 P90；
- 分区数量与每日新增分区数；
- 查询规划时间中位数与 P95；
- 元数据服务超时、锁等待次数。
为什么同时看中位数和 P90？因为一张表可能大部分文件还算正常，少数分区却碎得像饼干渣。平均值会把这件事抹平。
2. 计算与存储请求
记录：
- 日均扫描数据量；
- 日均查询次数；
- 典型查询执行时间；
- 对象存储 LIST、GET、PUT 请求量与费用；
- 合并小文件任务使用的计算资源；
- 因规划过慢造成的队列等待。
这里的关键不是算出一笔绝对精确的财务账，而是让迁移前后能用同一把尺子比较。
3. 人工维护
再记一组最容易被漏掉的数据：
- 每月人工补分区次数；
- 文件与元数据不一致的修复次数；
- 更新、删除、回溯所需的临时任务数量；
- 因这张表产生的工单和群聊次数；
- 熟悉它的关键人员数量。
最后一项很重要。如果只有一个人知道怎么修，这张表的风险不是“维护麻烦”，而是“周末能不能联系上他”。
