周一早上，数据群里又有人发了一张报错截图。
一张按天分区的明细表，查询还没真正开始，执行计划已经等了很久。有人说 Hive Metastore 慢，有人说分区太多，还有人顺手贴了一篇 Iceberg 的文章：“要不我们也迁？”
这句话很常见。
技术团队遇到旧系统的麻烦时，很容易把问题变成一次架构表态：继续用 Hive，还是换 Iceberg；坚持旧栈，还是拥抱新表格式。
可真正让人加班的，通常不是技术立场，而是某几张表。
Grab 的迁移，先从具体麻烦开始
Grab 在 7 月 10 日公开了它采用 Apache Iceberg 的过程。
它原来的数据湖主要使用 Hive Parquet，通过目录和 Hive Metastore 管理。在 PB 级数据和数十亿个 S3 对象的规模下，几个问题逐渐变成日常负担：
- 元数据访问需要遍历大量分区，查询规划越来越慢；
- 部分机器学习数据集平均文件小于 1 MB；
- 工程师需要手工注册分区，更新和删除也要绕路；
- 存储被直接修改后，目录记录可能与真实文件状态不一致。
Iceberg 带来了表级元数据、事务能力和更有效的文件管理。但 Grab 没有把迁移写成“把开关从 Hive 切到 Iceberg”。
他们明确说，成熟数据湖的迁移不是一次开关切换。不同格式会长期共存，查询引擎和下游任务也不能一起停下来等新世界建好。
所以，他们优先迁移高价值表。
这个顺序，比“Iceberg 好不好”更值得普通团队抄作业。
第一张：文件多得像撒了一地芝麻
先找小文件最严重的表。
一张表每天产生几万个几十 KB、几百 KB 的文件，问题不只发生在扫描阶段。查询引擎要列举对象、读取元数据、打开文件，调度器要处理更多任务，存储 API 也按请求次数收钱。
真正落到数据开发身上，就是一些很琐碎的现象：
- 同样的数据量，昨天跑 20 分钟，今天跑 40 分钟；
- Spark UI 里任务很多，每个任务只读一点点；
- 合并小文件脚本越写越复杂，还经常和上游任务撞时间；
- 对象存储账单涨了，却很难指向某一条 SQL。
Grab 提到，部分机器学习数据集平均文件小于 1 MB。这个数字不是所有团队的统一红线，但它提醒我们：迁移候选表应该由文件分布决定，而不是由表名的重要程度决定。
先统计最近 7 天的文件数、中位文件大小、P90 文件大小和每日新增文件数量。不要只看平均值，平均值很会替坏消息化妆。
第二张：每个人都在查，查询却总卡在门口
再找访问频率高、规划时间长的表。
有些表数据量很大，但一个月才查一次。另一些表没那么大，却被数十个看板、临时报表和模型反复读取。后者每慢 10 秒，累积起来都是真实的等待。
Grab 的一个高流量导航数据集在采用 Z-ordering 等优化后，查询时间从约 70 秒降到 6 秒。另一张高频操作表的 S3 API 日成本最多下降约 95%。
这里不能直接把别人的收益乘到自己头上。你该抄的是衡量方式：
- 一天被多少任务访问；
- 查询规划和实际执行分别花多久；
- 对象存储 LIST、GET 请求花多少钱；
- 慢查询影响多少下游人和系统。
把这些数据摆出来以后，迁移优先级会比“这张表是核心表”诚实得多。
第三张：每周都要有人去补一下
最后找人工维护最多的表。
有些表性能还过得去，却像办公室里那台偶尔卡纸的打印机。每周总要有人去看一眼：补分区、修元数据、重跑合并任务、处理重复文件、解释为什么目录里有数据但查询不到。
这些工作单次可能只要十几分钟，因此很少进入架构评审。可它们会不断打断人。
你可以回看最近一个月的工单、群聊和运维记录，找出三类动作：
- 人工注册或修复分区；
- 因文件或元数据不一致而重跑；
- 为了更新、删除和回溯而维护的临时脚本。
如果一张表在这些记录里反复出现，它就是迁移候选。哪怕它不是数据量最大的表，也可能是最该先动的表。
先做三张表，不是保守，是为了得到自己的证据
架构迁移最怕两种开头。
一种是“行业都在用”；另一种是“我们一步到位”。
前者没有自己的问题，后者没有退路。
从三张表开始，可以让团队回答更实际的问题：现有 Spark、Trino 和调度任务是否兼容；时间类型和历史视图会不会出错；下游代码是否写死了目录；回滚需要保留什么；维护工作究竟减少了多少。
Grab 在迁移中也遇到了 Hive 锁、时间戳兼容和存储分层成本等问题。新格式不是魔法，只是把一些旧问题换成了更可管理的新问题。
所以，试点前先为每张表留一份基线：查询时间、规划时间、文件数量、存储请求、失败次数、人工维护时长。迁移后用同一组指标比较。
没有基线，所有人都只能凭印象说“好像快了”。而“好像”是架构会议里最昂贵的词之一。
明天就能做的第一步
不用先申请一个 Iceberg 项目。
明天上班，先从监控、Spark 历史记录和群聊里各拿一份数据：
- 文件最碎的 10 张表；
- 访问最频繁且规划最慢的 10 张表；
- 最近一个月人工维护次数最多的 10 张表。
取三个名单的交集。
如果一张表同时出现在两个甚至三个名单里，它大概率比“全湖迁移方案”更值得先讨论。
数据湖很大，人的时间很小。别先想着搬整个湖，先把每天硌脚的那三颗石子捡出来。
我叫石头，在数据行业里摸爬滚打了十几年，架构升级听过很多，真正有用的总是先把问题算清。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：Grab Engineering：Scaling Grab’s Data Lake — Our journey to Apache Iceberg adoption
