从自建EMR迁到云平台，有哪些坑？
先说结论
云迁移的核心思路是：灰度方案 + 双写对账 + 分批切流。不是“一夜之间切过去”，而是“新旧并行运行一段时间，确认没问题再切流”。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这是我在出海硬件公司亲手做过的项目：把整个数据平台仏AWS EMR迁移到Databricks。历时3个月，零故障完成。这个经验在面试里非常有价值，今天把三个核心坑和我的解决方案讲清楚。
坑一：SQL方言差异
Hive SQL和Databricks SQL看起来差不多，但细节差异很多。我们迁移了100+个作业，约20%的SQL需要微调。
常见差异：
① 日期函数：Hive的datediff返回天数，Databricks返回整数，但参数顺序不同
② 类型转换：Hive的隐式转换更宽松，Databricks更严格，某些场景会报错
③ NULL处理：Hive和Databricks对NULL的排序默认行为不同（Hive默认NULL最大，Databricks默认NULL最小）
解决方案： 建了一个“SQL兼容性检查清单”，每个作业迁移前按清单检查一遍。多数问题可以在迁移前发现。
坑二：数据对账
迁移后必须逐表对账，确保新旧平台结果一致。我们用“双写双读”的灰度方案：
① 同一个ETL逻辑同时在EMR和Databricks上跑
② 比较两个平台的输出结果（行数、核心指标、抽样数据对比）
③ 连续3天结果一致后，才将下游切到新平台
这个方案的好处是：即使新平台有问题，也可以秒级回滚到老平台。风险可控。
坑三：元数据迁移
Hive MetaStore里的表定义、分区信息需要迁移到新平台的Catalog。这个过程比想象的复杂：
① 表结构（DDL）迁移：基本可以自动化，但要处理文件格式转换（ORC→Parquet）
② 分区信息：历史分区可能有数千个，要确保全部迁移
③ 权限信息：旧平台的权限配置要在新平台重新配置
总结
云迁移的核心是“灰度方案 + 双写对账 + 分批切流”。三个坑：SQL方言差异、数据对账、元数据迁移。这个项目是展示工程能力的绝佳案例，面试时用STAR法则讲。
最后一篇是最重要的综合题：请描述一个你做过的Hive数仓项目。这道题把前靂19篇的知识点串起来。
你们做过云迁移吗？遇到什么坑？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长