博主：爱码叔
个人博客站点： icodebook
公众号：爱码叔漫画软件设计（搜：爱码叔）
专注于软件设计与架构、技术管理。擅长用通俗易懂的语言讲解技术。对技术管理工作有自己的一定见解。文章会第一时间首发在个站上，欢迎大家关注访问！
“结束了吗？”
“不用再每天工作到凌晨两点了吗？”
“不用再一遍遍核对数据了吗？”
“不用再研究难读的mapping rule了吗？”
“是在做梦，还是已经醒了？”
睁开眼，此时是下午两点。昨夜结束了为期一年的数据迁移工作。历经多次上线上，数亿条数据从老系统进入新系统，开启了新生。
回首数据迁移的整个过程，可以说是无比痛苦。当然，随之也获取了宝贵经验。
据说每个程序员都会至少参与一次数据迁移工作。如果想在轮到你的那一次痛苦少一点，我们不妨继续看下去。
为什么数据迁移项目难做
如果你没有做过数据迁移项目，很容易低估数据迁移的难度。
“不就是把数据从一个DB转移到另外一个DB吗？select + insert 搞定！“ 如果抱着这个想法开始做数据迁移，保证你和团队很快就会掉入深渊。
现在让我们掀开数据迁移 “简单” 的外衣，把一个个阻挡迁移成功的小恶魔揪出来看看。
新老两套系统的DB设计全部熟悉吗？
“你熟悉新系统的DB设计吗？”
“当然！核心业务逻辑我都参与了开发！这就是我亲儿子！”
“那你了解老系统的数据库设计吗？”
“肯定不了解啊！咱们同事应该没人了解！”
”那迁移规则怎么写？“
”这个……让BA想办法“
“BA可能连新系统的数据库都不熟悉……”
“……”
不同数据库的数据如何对接？
“你了解MySql吗？“
”废话，咱们正在开发的系统不就用Mysql吗？“
”那你了解xxxx吗“
“这是什么新的技术吗？”
“这是诞生于上世纪70年代的数据库，要被新系统替代掉的老系统就是使用这个数据库”
“What？”
数据量、性能
“你知道要迁移的数据量吗？”
“据说有几个T！”
“上线当晚全部搞定吗？”
“是的，业务要求3小时以内搞定。”
“……”
错误数据如何处理？
“你看，好多数据导入失败了”
“看错误信息，大多数是迁移的校验太严格了。”
“要不校验放松点？”
“那新系统刚上线，就有大量脏数据啊！”
“要不就不迁移这些数据了？”
“业务人员会同意吗？”
“那就让业务人员把数据改正确！”
“但是好多数据通过界面没法改啊！”
“那你说怎么办……”
“先吃饭吧，回头再说……”
业务部门过高的预期
“项目启动会上业务经理要求数据100%导入成功！”
“这不可能啊！”
“业务说数据就是公司的财富，不能因为换系统造成公司资产损失！”
“这么说倒也没毛病。”
“没毛病？那今年你的KPI就是确保数据迁移100%正确率！”
“……你直接说今年不给我发奖金得了！”
数据迁移已经开始开发，但新系统开发还没完成
“下周数据迁移项目就要正式开始了！”
“嗯？新系统业务需求不是还有4个月才开发完吗？业务逻辑都不确定，怎么开发迁移程序？”
“等业务需求开发完再动工，明年这时候都不一定能上完线啊……”
“但业务变了，确定好的迁移规则也要跟着变……另外如何做到不遗漏新的业务场景？”
“哎，走一步算一步吧，且行且珍惜…”
“What？”
要开发的，远不只数据迁移程序
“加了俩月班，终于快把迁移程序开发完了！下周我请两天假出去旅旅游。”
“嗯……确实迁移的逻辑部分快开发完了。但现在只能通过调API执行迁移任务，那么多任务很容易乱套”
“明白了，我再写个API把有依赖的任务串一下！”
“但还是好多API要调用，要不你再写个页面吧，通过按钮触发！”
“没问题！”
“还得开发统计成功率的工具，咱不能一直手动统计成功率啊！玩 Excel 的都用上 Python了！”
“行，应该也不复杂！好歹咱们也是专业人士！”
“还有客户要的错误日志分析报告，我们需要分类统计、分析，提供错误数据，每次都要手动统计半天。你也写个程序来搞吧！”
“这个稍微复杂点，不过也还好！”
“还有每次测试想重新跑数据，删除上一次导入的数据也挺麻烦，要不你也想想办法？”
“……”
“我知道任务有点多，但也都是必须的……”
“喂？老婆，把下礼拜去马尔代夫的机票退了吧！我可能要去封闭开发……”
迁移工具和技术学习成本高，加资源困难
“经理，最近进度有些吃紧，迁移规则变化了好多，QA还提了好多bug。”
“要不我调几个开发过来支援三周？”
“项目用的这些工具和技术，很难快速找到合适的开发。没经验的开发光熟悉就得两周，还剩一周够干啥的……”
“那你说怎么办？”
“只能我再加加班了，回头调休吧”
“行，这个项目做完，估计你可以调休一个月！”
“想想还有点期待呢！”
做好数据迁移，就这些事
看完上面数据迁移过程中的各种问题，是不是觉得很头疼？其实这些问题都有解决的方案。根据经验，我提炼了如下几件数据迁移项目要关注的事情。
Mapping rule（迁移规则） 管理
Mapping rule是数据迁移的需求。写好 Mapping rule 需要既熟悉新系统，又熟悉老系统。并且要熟悉数据库设计。一个人能同时做到新老系统都熟悉几乎不可能。一般来说需要新老系统各出一位熟悉系统的成员，一起讨论 Mapping rule。
这里我建议参与Mapping rule讨论和制定是开发同学。因为这个人不仅需要熟悉业务，还需要熟悉数据如何存储。
Mapping rule 还需要明确迁移的数据范围。哪些业务数据需要迁移，迁移多久的数据都需要明确。
Mapping rule 制定完成后，要和业务部门澄清确认。并且告知成功率不可能100%，尽量降低业务的预期。
对 Mapping rule 的变更要格外小心，尤其在开发的收尾阶段，原因如下：
- 为了让几条报错数据能够进入新系统而改了 Mapping rule，有可能导致更多数据进不来。
- Mapping rule的修改很可能影响系统的性能。
如果mapping rule是错误的，必须要改，那么一定注意上面的两个问题。千万不要仅仅关注 mapping rule 变化的实现。
工具、技术培训
数据迁移一般会使用 ETL 工具，当然也可能自己开发程序。迁移程序的关注点在如何高效快速的处理数据，这和业务开发关注点完全不同。因此采用的技术栈也区别很大。由于数据迁移所使用的工具和技术在业务开发中较少使用，所以需要提前投入时间学习。并且需要制定长期的学习计划，项目开始后也要保持团队的学习和技术交流。
注意留存学习和分享的资料。未来有新人加入时，能够直接拿来学习。加速融入。否则新人上项目会很困难。
程序设计
架构师需要先设计好整体的代码框架，定义好开发规范和流程，并写好样例代码。这样可以确保开发集中进项目时能够尽快产出。程序设计要考虑如下事项：
- 迁移任务的记录、解耦以及依赖管理
- log 设计。需要包含任务名称，错误数据业务主键子段等关键信息。总之需要方便统计和定位错误。
- 通过模版化，让开发只关注业务逻辑。从而降低mapping rule实现的复杂度。
- 能够方便调节并发数等性能相关参数。
- 成功率统计程序设计
- 错误日志分析程序设计
- 其他辅助工具
- 如何兼容业务系统的新变更
重点说一下最后一点，很多时候在迁移程序开发阶段，业务系统还未开发结束。如果解决业务逻辑的改动和表变更改动对数据迁移的影响是个难题。首先业务逻辑的改动我们可以通过调业务API完成数据迁移的方式来屏蔽掉。由于不是表对表转换后直接sql写入，而是通过业务的api写入。那么当API输入有变化时，迁移程序就会报错。此外如果逻辑有调整，数据自然也会按照最新的逻辑进入的数据库。
对于新的字段和新的表，我们可以通过工具对比现有mapping rule的表和字段，识别出变化点，再分析是否需要增加mapping rule来迁移这些数据。
一定要在开发高峰到来前做好程序设计和框架代码开发。否则会让开发团队陷入泥沼。
性能调优
大数量级的数据迁移，肯定会有性能的问题。数据迁移时，新老系统都不可用。因此，业务部门肯定希望数据迁移时间越短越好。这对性能是极大的挑战。关于性能优化，我有如下建议：
- 一定要有APM工具。还要有虚机、DB等资源的监控工具。有了工具才能将性能状况透明出来。性能瓶颈在哪里一目了然，否则就是胡乱抓药。
- 性能要全局考虑，不要只考虑过程某个单点的性能。很多时候，都是相互制约的。
- 减少网络IO的次数，每次请求可以传输更多数据。但并不是越多越好，需要找到性能的平衡点。
- 数据量太大的话，可以分几个批次迁移，分批上线。
- 变化不大的非交易数据可以提前上线。甚至交易数据也可以考虑提前上线，真正上线时再做增量迁移。
- 在高并发的迁移过程中，任何关于性能的参数调整都可能有想不到的影响。要不断试验，不能想当然。
成功率及错误分析报告
没有数据迁移经验的团队很可能在项目初期遗漏掉这两部分的开发工作。数据迁移的核心关注点是迁移没错，但是业务最关心的是成功率。
这两种报告要提前设计好。迁移程序的设计和开发要考虑报表的需求来记录任务成功率和日志。否则等到程序开发完再去思考报告程序的开发，很可能会对原有迁移程序的逻辑作变更。
这两份报告要和业务部门澄清，确定错误数据如何处理。错误数据处理一般分为如下三类：
- 数据问题，业务可以改数据。让业务自行修改。
- 数据问题，业务不能直接修改。可以通知业务自行备份数据。
- Mapping rule未考虑的场景。修改Mapping rule来适配这些数据。
除了这两个报告，迁移过程中涉及到的一些小工具会很多，比如数据清理，环境状态检查工具等等。对这些工具的开发工作量要有预期。
上线演练
上线前如果有条件，一定要使用真实环境和数据进行演练。时间和执行步骤也尽量和上线计划一致。
上线演练的时间不能过早。过早会造成演练的数据和上线时差异过大，减弱了演练的效果。但演练的时间也不能过晚，否则发现问题没有时间解决。我的经验是上线时间往前推两周。
由于演练的时间点已经比较接近上线时间，除非发现严重 bug 才做修改。小问题宁可带着上线，以后再修数，也不要去改代码修复。因为你不知道是否会引入更为严重的问题。
上线失败方案
虽然你经历的上线可能从来没有失败过，但不要以为这一次也一定会成功。如果出现问题，是全部回滚还是部分回滚，都要提前计划好。先上线后面再补历史数据是一种方案。直接终止上线，再次开启老系统也是一种方案。不管什么方案，都需要提前和业务沟通好。因为上线期间的时间十分宝贵。一定避免临时定方案，这会造成决策困难，甚至无人拍板。
上线
经过数轮测试和演练，终于迎来了上线时刻，关于上线我有如下建议：
- 分配好资源。如果晚上上线，不要全部开发都来支持通宵上线。留有人手第二天做线上支持。
- 根据上线计划，一步步小心执行，确保每个操作至少两个同事 pair 完成。
- 每一步操作完成都要做相应的检查。
- 上线前需要预测可能出现的异常及处理方案。如果出现预料之外的错误也不要惊慌，冷静思考解决方案。
线上支持
我向你保证，迁移进来的数据一定会有各种各样的问题。一般来说修复数据有如下几种方式：
-
SQL修复
修复问题数据涉及的表，在同一个DB中，逻辑不复杂的情况。可以采用直接写SQL来修复
-
存储过程修复
修复问题数据涉及的表，在同一个DB中，逻辑比较复杂的情况。可以写存储过程修复。优点是不用发布程序。缺点是不好调试和维护。
-
程序修复
修复问题数据需要跨DB时，需要写程序来修复。这种场景也是最复杂的。
无论采用哪种方式，都需要经过充分的测试。数据修复是很危险的操作，一旦程序有问题，可能会把没问题的数据改坏。此外还要测试修复程序的性能，对执行时长要有预估。
另外生产环境执行修复前一定要做数据的备份。
总结
数据迁移从来都是一件困难的事情，一定要做好规划，把问题想在前面。如果团队有做过数据迁移的成员最好。即使没有，解决了本文所提到的这些问题，你的数据迁移工作也会轻松很多！