如何做好大型遗留系统的数据迁移 - Thoughtworks洞见

历史悠久的大型企业，都会存在遗留系统。这些系统运转着重要的业务，但使用到的技术已经跟不上时代潮流。因此有着维护成本高、难以扩展、用户体验差等缺陷。最终，企业一定会下决心开发一套全新的系统来替代遗留系统。除了完成新系统的开发，还有一项重要的工作，是将老系统中存留的数据迁移进新系统，也就是我们常说的数据迁移。

如果你没有数据迁移的经验，很容易低估其难度。数据迁移看起来只是把数据从一个 DB 转移到另外一个 DB，select + insert + 转换逻辑就可以轻松搞定。如果带着这个想法开始数据迁移项目，你的团队很快就会坠入深渊，举步维艰。

数据迁移是一项看似简单，实而复杂且繁琐的工作，想要做好并不容易。

为什么数据迁移项目难做

不久前，我刚刚完成一次数据迁移项目。虽然项目结果很成功，但过程中遇到很多开始之初没有想到的问题，导致项目过程非常痛苦。如果在项目开始时就把这些问题考虑进来，过程会轻松很多，风险也会小很多。下面我们来看看数据迁移项目所面临的挑战有哪些。

陌生的遗留系统 DB 设计

作为新系统的开发方，你一定熟知新系统的 DB 设计。但是遗留系统的 DB 设计想必你一定不甚了解。作为要被替换的遗留系统，其开发方肯定也不会提供技术支持。在这个情况下，如何写好迁移规则就成为了一个难题。

古老的遗留系统数据库

新系统一般都会采用当前主流的数据库，例如 MySQL、Oracle 等。但遗留系统可能采用的是几十年前古老的技术，数据库的名字你可能听都没听过。这时候不会有任何 ETL 工具可以使用，甚至于没有主流语言的客户端类库可以使用。如何连接老系统的 DB，查询出里面的数据都会是一个难题。

迁移海量数据量

遗留系统经过几年甚至几十年的使用，累积了海量的数据。业务一般不会轻易放弃这些数据。同时，在上线的窗口期内，留给数据迁移的时间也就短短几个小时。如何在短时间内导入海量的数据，将会是很大的挑战！

错误数据如何处理

新老系统在业务处理上肯定会有差异，此外老系统的数据也会有质量问题。这会导致有一部分数据无法进入新系统。业务人员总是希望能够导入更多的数据到新系统。一个选择是放松校验，但低质量的数据进入新系统会造成很多问题。另外一个选择是让业务人员在老系统中修复数据。但很多问题数据无法通过界面修改。如何权衡数据的迁移准入标准也将是一个挑战。否则迁移成功率上来了，但上线后会陷入无止境的修数据工作中。

业务部门过高的预期

业务部门往往对数据迁移抱有不切实际的幻想，例如非常高的导入成功率及导入速度。如何采用有效的策略让业务部门降低预期，是数据迁移项目组要认真思考的问题。否则团队的辛苦付出不被认可，对团队伤害极大。

数据迁移程序如何兼容业务系统的改动

迫于上线时间点的压力，往往数据迁移程序开发的同时，业务系统也还在开发中。如何做到兼容业务系统的变化，是一个难题。处理不好这个问题，会导致数据按照错误的逻辑导入，甚至可能遗漏新的字段。

要开发的远不止数据迁移程序

数据迁移项目中除了开发迁移的主程序，还需要开发很多辅助的工具。比如成功率报表工具、错误日志分析工具、数据删除工具、环境检查工具等。这些工具都是数据迁移过程中必不可少的。如果项目估算时忽略了这些工作量，会造成严重的资源紧张。

较高的技术和工具门槛

数据迁移使用的技术和工具不同于业务开发，均有一定门槛。如果项目中期遇到进度吃紧，需要增加资源，往往很难短时间找到合适的资源。最终可能妥协让没有经验的工程师上项目。这些工程师如何快速掌握所需技能，加速融入团队是项目组需要提前考虑的事情。如果处理不好，会造成新人没有产出，只能依赖项目已有人员加班赶工，使得整个团队陷入疲惫不堪的状态。

做好数据迁移，就这些事

看完上面数据迁移过程中的各种问题，是不是觉得很头疼？没关系，办法总比困难多。根据经验，我提炼出如下几件数据迁移要关注的事情。

Mapping rule（映射规则） 管理

Mapping rule是数据迁移的需求。写好 mapping rule 需要既熟悉新系统，又熟悉老系统。并且还要熟悉数据库设计。一个人能同时做到新老系统都熟悉几乎不可能。一般来说需要新老系统各出一位熟悉系统的成员，一起讨论 mapping rule。
建议参与 mapping rule 讨论和制定的是开发成员。因为此人不仅需要熟悉业务，还需要熟悉数据如何存储。
Mapping rule 还需要明确迁移的数据范围。哪些业务数据需要迁移，迁移多久的数据都需要明确。
Mapping rule 制定完成后，要和业务部门澄清确认。并且告知成功率不可能100%，尽量降低业务的预期。
对 Mapping rule 的变更要格外小心，尤其在开发的收尾阶段，原因如下：

1. 为了让几条报错数据进入系统而改了 mapping rule，有可能导致更多数据进不来。
2. Mapping rule的修改很可能影响系统的性能。
   如果 mapping rule 是错误的，必须要改，那么一定注意上面的两个问题。千万不要仅仅关注 mapping rule 变更的工作量。

工具、技术培训

数据迁移一般会使用 ETL 工具，当然也可能自开发程序。迁移程序的关注点在如何高效快速的处理数据，这和业务开发关注点完全不同。因此采用的技术栈也区别很大。由于数据迁移所使用的技术在业务开发中较少使用，所以需要提前投入时间学习。并且需要制定长期的学习计划，项目开始后也要保持团队的学习和技术交流。

注意留存学习和分享的资料，未来有新人加入时，能够直接拿来学习，加速融入团队的速度。

程序设计

架构师需要先行设计好代码框架，定义好开发规范和流程，并写好样例代码。这样可以确保开发集中进项目时快速产出。程序设计要考虑如下事项：

1. 迁移任务的记录、解耦以及依赖管理。
2. log 设计。需要包含任务名称，错误数据业务主键子段等关键信息。总之需要方便统计和定位错误。
3. 通过程序设计，让开发只关注业务逻辑的实现。不需要过多关注任务记录、异常处理等非功能性需求。
4. 能够方便调节并发数等性能相关参数。
5. 成功率统计程序设计。
6. 错误日志分析程序设计。
7. 其他辅助工具。
8. 如何兼容业务系统的新变更。

重点说一下最后一点，很多时候在迁移程序开发阶段，业务系统还未开发结束。如果解决业务逻辑的改动和表变更改动对数据迁移的影响是个难题。首先业务逻辑的改动我们可以通过调业务API完成数据迁移的方式来屏蔽掉。由于不是表对表转换后直接sql写入，而是通过业务的API写入。那么当API输入有变化时，迁移程序就会报错。此外如果逻辑有调整，数据自然也会按照最新的逻辑进入的数据库。

对于新的字段和新的表，我们可以通过工具对比现有 mapping rule 的表和字段，识别出变化点，再分析是否需要增加 mapping rule 来迁移这些数据。

一定要在开发高峰到来前做好程序设计和框架代码开发。否则会让开发团队陷入泥沼，有力气使不上。
性能调优

大数量级的数据迁移，肯定会有性能的问题。数据迁移时，新老系统都不可用。因此，业务部门肯定希望数据迁移时间越短越好。这对性能是极大的挑战。关于性能优化，我有如下建议：

1. 一定要有 APM 工具。还要有虚机、DB 等资源的监控工具。有了工具才能将性能状况透明出来。性能瓶颈在哪里一目了然，否则就是胡乱抓药。
2. 性能要全局考虑，不要只考虑某个运算单点的性能。很多时候，性能是相互制约的。
3. 减少网络IO的次数，让单次请求传输更多数据。但并不是越多越好，需要找到性能的平衡点。
4. 数据量太大的话，可以分几个批次迁移，分批上线。
5. 变化不大的非交易数据可以提前上线。甚至交易数据也可以考虑提前上线，真正上线时再做增量迁移。这种方式需要额外开发增量迁移程序。
6. 在高并发的迁移过程中，任何关于性能的参数调整都可能有想不到的影响。要不断试验，不能想当然。

成功率及错误分析报告

没有数据迁移经验的团队很可能在项目初期遗漏掉这两部分的开发工作。数据迁移的核心关注点是迁移没错，但是业务最关心的是成功率。

这两种报告要提前设计好。迁移程序的设计和开发要考虑报表的需求来记录任务成功率和日志。否则等到程序开发完再去思考报告程序的开发，很可能会对原有迁移程序的造成比较大的返工。

这两份报告要和业务部门澄清，确定错误数据如何处理。错误数据处理一般分为如下三类：

1. 数据问题，业务可以改数据。让业务自行修改。
2. 数据问题，业务不能直接修改。通知业务数据无法导入，自行备份。
3. Mapping rule 未考虑的场景。修改 Mapping rule 来适配这些数据。

除了这两个报告，迁移过程中需要开发很多小工具，比如数据清理、环境状态检查工具等等。对这些工具的开发工作量要有预期。

上线演练

上线前如果有条件，一定要使用真实环境和数据进行演练。演练的时间和执行步骤也尽量和上线计划一致。

上线演练的不能过早进行，否则会造成演练的数据和上线时差异过大，减弱了演练的效果。但演练的时间也不能过晚，否则发现问题没有时间解决。我的经验是上线前两周进行演练。

由于演练的时间点已经比较接近上线时间，除非发现严重 bug 才做修改。小问题宁可带着上线，以后再修数。此时千万不要轻易修改代码，因为很可能会引起其它 bug 或者性能问题。

上线失败方案

虽然你经历的上线可能从来没有失败过，但不要以为这一次也一定会成功。如果出现问题，全部回滚还是部分回滚，都要提前计划好。先上线后面再补历史数据是一种方案。直接终止上线，再次开启老系统也是一种方案。不管什么方案，都需要提前和业务沟通好。因为上线期间的时间十分宝贵。一定避免临时定方案，这会造成决策困难，甚至无人拍板。

上线

经过数轮测试和演练，终于迎来了上线，关于上线我有如下建议：

1. 分配好资源。如果晚上通宵上线，不要全部开发都来支持上线。一定留有人手第二天线上支持。
2. 根据上线计划，一步步小心执行，确保每个操作至少两个同事 pair 完成。
3. 每一步操作完成都要做相应的检查。
4. 上线前预测可能出现的异常，准备好处理方案。如果出现预料之外的错误也不要惊慌，冷静思考解决方案。

上线后的支持

我向你保证，迁移进来的数据一定会有各种各样的问题。一般来说修复数据有如下几种方式：

1. SQL 脚本修复。适用于修复问题数据涉及的表，在同一个 DB 中，逻辑也不复杂的情况。
2. 存储过程修复。适用于修复问题数据涉及的表，在同一个 DB 中，逻辑比较复杂的情况。存储过程的优点是不需要发布程序。缺点是不好调试和维护。
3. 程序修复。修复问题数据需要跨 DB 时，只能通过开发程序来修复。这种场景也是最复杂的。
   无论采用哪种方式，都需要经过充分的测试。数据修复是很危险的操作，一旦程序有问题，可能会把没问题的数据修坏。此外还要测试修复程序的性能，对执行时长要有预估。最后切记修复前一定要好做数据备份。

总结

美国管理学家 哈罗德·孔茨 曾经说过：虽然计划不能完全准确地预测将来，但如果没有计划，组织地工作往往陷入盲目，或者碰运气。千万不要低估数据迁移项目的难度，参考本文内容提前做好规划，会让你的数据迁移项目有一个好的开始。