“结束了吗?”

“不用再每天工作到凌晨两点了吗?”

“不用再一遍遍核对数据了吗?”

“不用再研究难读的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 的变更要格外小心,尤其在开发的收尾阶段,原因如下:

  1. 为了让几条报错数据能够进入新系统而改了 Mapping rule,有可能导致更多数据进不来。
  2. Mapping rule的修改很可能影响系统的性能。

如果mapping rule是错误的,必须要改,那么一定注意上面的两个问题。千万不要仅仅关注 mapping rule 变化的实现。

工具、技术培训

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

注意留存学习和分享的资料。未来有新人加入时,能够直接拿来学习。加速融入。否则新人上项目会很困难。

程序设计

架构师需要先设计好整体的代码框架,定义好开发规范和流程,并写好样例代码。这样可以确保开发集中进项目时能够尽快产出。程序设计要考虑如下事项:

  1. 迁移任务的记录、解耦以及依赖管理
  2. log 设计。需要包含任务名称,错误数据业务主键子段等关键信息。总之需要方便统计和定位错误。
  3. 通过模版化,让开发只关注业务逻辑。从而降低mapping rule实现的复杂度。
  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 才做修改。小问题宁可带着上线,以后再修数,也不要去改代码修复。因为你不知道是否会引入更为严重的问题。

上线失败方案

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

上线

经过数轮测试和演练,终于迎来了上线时刻,关于上线我有如下建议:

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

线上支持

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

  1. SQL修复

    修复问题数据涉及的表,在同一个DB中,逻辑不复杂的情况。可以采用直接写SQL来修复

  2. 存储过程修复

    修复问题数据涉及的表,在同一个DB中,逻辑比较复杂的情况。可以写存储过程修复。优点是不用发布程序。缺点是不好调试和维护。

  3. 程序修复

    修复问题数据需要跨DB时,需要写程序来修复。这种场景也是最复杂的。

无论采用哪种方式,都需要经过充分的测试。数据修复是很危险的操作,一旦程序有问题,可能会把没问题的数据改坏。此外还要测试修复程序的性能,对执行时长要有预估。

另外生产环境执行修复前一定要做数据的备份。

总结

数据迁移从来都是一件困难的事情,一定要做好规划,把问题想在前面。如果团队有做过数据迁移的成员最好。即使没有,解决了本文所提到的这些问题,你的数据迁移工作也会轻松很多!

做数据迁移差点累死的程序员有话要说----数据迁移经验分享相关推荐

  1. 程序员转型产品经理经验分享

    这是我见过最好的一个分享,不算是公司招聘还是应聘都值得每个人看一看,想一想 程序员转型产品经理经验分享 本文作者是 Google 集团产品经理Ken Norton ,他由技术转产品,在创业公司和大公司 ...

  2. 在职场,光有技术是不行的,18年老程序员职场宝贵经验分享

    程序员是公认的技术型岗位,我们喜欢用实力说话,那么是否技术实力强就能在职场如鱼得水? 以前我觉得只要技术过硬,在哪都是香饽饽,后来发现也不尽然,公司不是研究所,在研究所里你或许可以不管不顾地只追求技术 ...

  3. 转载CSDN - 从程序员到HR——面试经验分享

    CSDN博客一周热文推荐,为您总结回顾过去一周的CSDN博客热门文章,推荐优质的博客作者,分享精华文章和优质博客. [1] 谭海燕:北漂之惠普H3C面试经历 上一篇讲到了<北漂之百度面试> ...

  4. 优秀程序员的秘密|宝贵经验分享

    源作者:Edmond Lau 来源:程序师 更新整理:极客重生 优秀程序员是稀缺的,你只要问大厂面试官:你们还招人吗,他肯定会说:一直在招人,为什么会一直在招人呢,HC真的有那么多吗?真实情况是,面试 ...

  5. 程序员爱情+10年经验分享

    展望未来,总结过去10年的程序员生涯,给程序员小弟弟小妹妹们的一些总结性忠告  走过的路,回忆起来是那么曲折,把自己的一些心得体会分享给程序员兄弟姐妹们,虽然时代在变化,但是很可能你也会走我已经做过的 ...

  6. 资深程序员面试的五大经验分享,顺利走向人生巅峰

    一.为什么入职这么难? 入职比较难的原因一般有三个: 简历通不过筛选: 不知道面试官问什么: 不知道如何提升自己的技能. 以下我们会逐步对上面三个问题进行回答. 二.如何写简历 简历写的不好,就意味着 ...

  7. 好程序员大数据技术分享:Zookeeper集群管理与选举

    为什么80%的码农都做不了架构师?>>>    大数据技术的学习,逐渐成为很多程序员的必修课,因为趋势也是因为自己的职业生涯.在各个技术社区分享交流成为很多人学习的方式,今天很荣幸找 ...

  8. 商业方向的大数据专业_好程序员大数据培训分享大数据就业方向有哪些

    好程序员大数据培训分享大数据就业方向有哪些?看到了大数据的就业前景及就业薪资,相信很多人都对大数据技术跃跃欲试,想要学习大数据技术.小编认为在学习大数据之前,你还需要了解一下大数据的就业方向有哪些?毕 ...

  9. 好程序员大数据教程分享之Hadoop优缺点

    好程序员大数据教程分享之Hadoop优缺点,大数据成为时代主流,开启时代的大门,全球43亿部电话.20亿位互联网用户每秒都在不断地产生大量数据,人们发送短信给朋友.上传视频.用手机拍照.更新社交网站的 ...

  10. 甲骨文华育兴业|【大数据调查】80%的程序员年薪都在10万以上,三分之一的人年薪20万以上

    看了上面文章的小伙伴 如果感到不舒适 那么请看看这篇文章 非常适合你找准方向 你们印象中程序员是什么样?他们的实际生活状态怎样?针对中国程序员薪资生存现状做了一项调查,大数据让你更懂程序员.(以下数据 ...

最新文章

  1. vector 容器 动态数组总结
  2. exchange迁移测试作业
  3. css3动画、2D与3D效果
  4. 【C++】32. Boost C++ 库系列博客搜集
  5. html 空格_HTML标签
  6. “git pull” 强制覆盖本地文件
  7. 抓捕盗窃犯(并查集)
  8. 处理机流水线------经典五段流水线
  9. 领域应用 | 中医临床术语系统
  10. c++:多线程的创建和unique_lock<mutex>的使用
  11. 程序员必备的书籍有哪些?
  12. 加州大学洛杉玑分校计算机专业,加州大学洛杉矶分校
  13. MYSQL间隙锁详解
  14. 转:https://mp.weixin.qq.com/s/O_D_FVRIIII1wqq4jGZqHA
  15. java2017期末考试,2017年java考试模拟试卷(2)
  16. JVM 之 JDK安装与配置
  17. 手机建站系统php,zzzcms免费开源建站系统含手机
  18. char matlab中,matlab中char什么意思
  19. 【计算机视觉 | ViT-G】谷歌大脑提出 ViT-G:缩放视觉 Transformer,高达 90.45% 准确率
  20. EasyPOI使用 导出导入Excel数据

热门文章

  1. 基于Rasa_NLU的微信chatbot
  2. 利用SWT做Java版局域网QQ(一)——基于UDP协议
  3. 服务器系统如何设置屏幕保护,在windows中要设置屏幕保护程序可以使用控制面板的什么功能?_网站服务器运行维护,windows,屏幕保护程序,控制面板...
  4. window.dialogArguments与window.showModalDialog用法
  5. 两步解决科来数据包生成器找不到网卡的问题
  6. 如何查看class文件内容
  7. 上传项目源码至Nexus私服
  8. 5套精美的石器时代游戏官方网页源码
  9. springboot制作补丁包通用解决方案
  10. 免费图床、mp3外链,音乐上传,QQ空间永久背景音乐,mp3联接