我干了十几年数据仓库，大大小小的迁移项目见过几十个，有的顺风顺水，有的直接翻车。每次迁移前，团队都信誓旦旦说要“平滑过渡”，结果总有几个坑让人摔得鼻青脸肿。今天不聊理论，就说说我亲眼见过、亲手踩过的五个大坑，避开它们，成功率至少翻一倍。
第一个坑：忽略数据血缘，迁移完才发现上下游全断。很多人做迁移，只盯着源库和目标库的对应关系，觉得把表结构、字段类型对齐就完事了。但数据仓库最怕的是“断了线”——上游系统改了，下游报表查不到数据，业务方直接打电话骂人。我见过一个项目，迁移前没梳理清楚血缘关系，结果 ETL 跑完，销售、财务、人力三套系统全崩了，花了整整两周才把断点接上。正确的做法是：迁移前必须画出完整的数据流向图，标明每个表的输入、输出、依赖关系和触发条件。别偷懒，这一步省下来的时间，后面会加倍还给你。
第二个坑：测试数据太干净，上线后现实打脸。很多团队做迁移测试，用的是生产库的样本数据或自己造的理想数据，跑起来顺顺当当，性能也达标。结果一上线，真实数据里全是脏数据——空值、重复值、格式不一致、业务逻辑冲突，ETL 脚本直接崩溃。我参与过的一个电商项目，迁移后第一周就发现订单表里有几百万条重复记录，原因是源系统有多个入口写入数据，但迁移脚本没处理去重逻辑。建议你：测试阶段必须用全量真实数据，哪怕只是抽样，也要覆盖各种边界情况。别怕麻烦，麻烦总比崩盘强。
第三个坑：忽视增量同步，全量迁移后天天补数据。很多人以为一次性把历史数据倒过去就万事大吉，但业务系统每天都在产生新数据。如果没有规划好增量同步的方案，迁移完成后只能靠手工脚本每天跑批，不仅效率低，还容易漏数据。我见过最惨的一个案例，某金融公司迁移后，增量同步的延迟从 30 分钟慢慢涨到 6 小时，业务方急得跳脚。原因是增量日志解析环节设计得太粗糙，源库写入量一大就扛不住。所以，迁移方案里必须把增量同步的架构、频率、容错机制写清楚，最好能做到实时或准实时。
第四个坑：忘记兼容历史查询模式，老用户直接骂娘。迁移完成后，新系统性能再好、功能再强，如果用户习惯的查询方式变了，他们就会抗拒。比如以前用 SQL 查一张大表，现在拆成了多张宽表，用户得重新学查询语法。更惨的是，有的团队把数据库引擎换了，从 Teradata 换到 ClickHouse，语法、函数全不一样。我见过一个项目，迁移后用户反馈“查个数据要改半小时脚本”，气得直接找老板投诉。所以，迁移前必须调研清楚用户常用的查询场景，尽量兼容旧语法，或者提供迁移工具自动转换。用户舒服了，你才安全。
第五个坑：回滚方案形同虚设，出问题只能硬扛。每个迁移项目都会写回滚方案，但大部分只是纸上谈兵——写了“如果失败，恢复旧系统”，却没有说明具体怎么恢复、需要多少时间、数据一致性怎么保证。真出问题时，团队手忙脚乱，发现旧系统的备份早被覆盖，或者恢复脚本有 bug 跑不通。我经历过一个项目，迁移到一半发现源库和目标库的编码不一致，数据全乱码，想回滚却发现旧库的数据已经被清理，只能停服 48 小时重做。所以，回滚方案必须至少演练一次，备份数据要保留足够长的时间，最好能做到一键切换。
这五个坑，每个都是我或同行用血泪换来的教训。数据仓库迁移不是换个地方存数据那么简单，它牵涉业务连续性、用户习惯、团队协作和技术细节，任何一个环节出问题都够你喝一壶的。但只要在规划阶段把这些坑考虑进去，方案扎实，成功率真的能翻倍。
说句掏心窝的话：别迷信“平滑迁移”这个说法，没有哪次迁移是不疼的。但疼过之后，你能让数据跑得更快、更稳、更便宜，那这疼就值得。下次带队做迁移时，把这五个坑打印出来贴在墙上，每走一步都对照检查，保证少走弯路。毕竟，数据仓库是企业的“神经系统”，它不能乱，也乱不起。
