Uber把16000个数据集"分家",省出1PB存储还不停机

Uber最近干了一件事：把自家Hive数据仓库拆了。16000多个数据集、超过10PB的数据，从“大杂院”搬进了“独门独院”。

这事听着像搬家，实则不然。以前Uber所有配送业务的数据全挤在一个Hive实例里，同一个命名空间下塞得满满当当。坏处很明显：一处故障可能拖垮全局，资源争抢像早高峰地铁，治理权限更是“一刀切”——改个配置要层层审批，等批下来业务早凉了。

联邦化：不动数据，只改指针

他们的解法叫“联邦化”，核心就一招：不动数据，只改指针。

具体来说，工程师在Hive Metastore里给每个数据集换了个“门牌号”，指向新的HDFS路径。数据本身只复制一次到目标位置，随后更新指针，整个过程查询照常跑。用Uber工程师Vijayant Soni的话说：“HMS里改指针是瞬时操作，核心工作负载不会感知到迁移正在发生。”

四大组件协同保障迁移平稳

这套方案靠四个组件配合：

• 引导迁移器负责初次搬运，用Spark分布式作业加校验和保数据完整；
• 实时同步器和批量同步器维持两端元数据一致，支持双向更新，团队该读写读写；
• 恢复编排器则盯着指针备份，发现不对能一键回滚；
• 人机协同验证加自动化检查，让迁移像换轮胎时车还在开。

去中心化带来的实际收益

去中心化后，“吵闹邻居”问题没了——各团队不再抢同一池资源。ACL权限收紧到领域级别，谁碰了哪张表一目了然。工程师还能在仪表盘上看迁移进度、数据集状态、同步指标，透明度上去了，操作也敢放手做了。

最终成果：700多万次HMS同步，数千数据集完成迁移，清理旧数据回收超1PB存储。新数据集接入流程简化，合规审计自动留痕。最重要的是，中央运营团队不用再当“救火队长”，各业务方自己对自己负责，反馈周期短了，系统弹性反而强了。

有个细节挺有意思。迁移期间，依赖Hive的分析任务和机器学习管道全程零停机——对于一家靠实时调度吃饭的公司，这大概是比省出1PB存储更值得写进OKR的指标。