最近有个项目需要迁移旧系统的数据，原来以为确定好数据口径，写个程序跑一遍就完事了。程序逻辑也比较简单，读旧库遍历需要的数据，写入新库，加上并发执行的逻辑。然而现实却是问题多多，频频返工修改程序。最终还被扣了分哎。反思了整个过程，总结了以下几点，避免以后犯同样的问题。
1. 捋清数据迁移的口径
此次项目我初次接手，业务逻辑不熟悉，由另外一个同事提供迁移数据的口径，原始问题也源于此：同事告知的数据的口径有误，迁移完后才发现缺少一部分数据。虽然很无奈但也没办法，接着修改下程序又再跑一遍。这都算了，最离谱是上线后，又被告知迁移的数据仍有缺漏，上司又告诉我以另一个口径全量跑一遍，真是崩溃。
事后我琢磨着从自身角度如何能尽量避免这个事发生，可能能够去做的就是在确定数据口径时，应该首先跟熟悉业务的同事确定好，随后在小组群里@上司同步一下结论，进行二次确认。这样的话无论结果如何，此环节也已尽到了工具人的责任了。（┓( ´∀` )┏ ）
2. 注意读取旧数据的性能
发现第一步的问题后，立即修改读取数据的SQL语句，改着改着语句条件出现了慢查询的问题，导致跑起来的时候影响到数据库性能。
这个问题属于低级错误，修改程序时应该时刻注意着读取语句的性能问题。出现问题，不但影响原业务，也会导致迁移程序的效率低下。
3. 脚本执行可断点续跑
执行程序过程中，由于各种原因（比如：并发太高，数据库压力过大），导致程序被迫停止。但程序被迫停止以后，重新执行又要从头开始执行。
回想处理线上问题时，情绪比较紧张，总是很急于快点改好程序，就开始执行，也由于最初设计脚本时，迁移数据口径清晰，并没有考虑要反复去跑的可能，所以设计上没有加入可以断点续跑。如果程序需要执行数小时，这一点很关键，多花一些时间去支持它，你就会在意外中断发生时，保持从容。
4. 脚本执行的幂等性
由于迁移设计没有考虑断点续跑，程序被迫中断以后，不得不重头开始跑，所以程序上要支持重复执行的幂等性。基本做法就是写入之前判断是否已经写入过啦，这一点非常重要，万一重复写入了，很有可能引发其他的数据问题。
5. 脚本执行进度可监测
从发现问题到迁移程序执行完毕，整个过程都要时不时回复业务方或者上司的灵魂拷问：「跑完了吗？跑了多少？进度如何？」。由于这次实现的程序只记录了插入信息的日志，而且数据源是分表分库多实例的架构，无法通过SQL语句来查询对比分析出迁移进度，每次的问都没法准确回复，让我越发焦躁。
因此在程序真正开始跑之前，需要考虑记录哪些关键信息，其实统计进度的维度不一定要细到记录的粒度，也可按照表的粒度来统计，粗略估算出整体进度即可。
当然，数据量如果不大，自己预计能在几十分钟能执行完的可不用考虑这一点。但如果预计要跑数小时的话，建议要考虑整体进度的监测，这样不用每次被问到都只能支支吾吾地回复：还在跑，没那么快。
6. 选择合适的脚本语言
这一次用了Python实现迁移程序，整体数据量预估有接近10亿，在跑数据时也怀疑过是不是用go写这个程序可以跑的快一点。但仔细分析瓶颈其实在于数据库，不能把并发提到太高，所以选择合适的语言时，语言性能不是最重要的，更重要是：个人熟悉程度、友好的并发支持。
7. 总结
上面描述过程的问题，可能有些情绪，毕竟背锅了，但自觉不是全部是个人的问题。也不想回头调整文字了，就这样吧。自己整体做的也不是很好，核心问题是对迁移数据的事情经验不足，遇事不够冷静。不怪别人，下次争取做的更好吧。
