大型国有银行数据平台应用迁移之路.pptx

;系统迁移目标和问题分析 问题与挑战;;;6;范围分析是整个迁移工作的第一步，也是非常重要的一步。关于它的重要性，在第一期有过简单的 说明。范围分析完不完备，准不准确，影响到后面迭代迁移次数的多少，范围分析相关工作做得完 备、准确，那么会减少真正迁移时因模型缺失或作业缺失等范围缺失而导致的返工。既然范围分析 工作这么重要，那该如何开展呢？;;数据模型迁移策略 数据模型迁移;数据初始化主要是将TD上的初始化截面数据复制到GP中，作为初始化数据。 “数据同步组件”是该 行开发的数据复制组件，可实现全量或者增量将各类型数据库（GP/TD/ORACLE/HD）的数据非常高 效地同步到各类型数据库（GP/TD/ORACLE/HD）。 为了适应迁移工作的特殊性，在该组件的基础上，额外做了一定的改造主要是为了数据迁移工作的 效率，去掉了该数据同步组件的自动数据校验功能，并改为由人工批量校验方式来保证数据迁移的 准确性;初始化数据迁移工作关键点：;工欲善其事必先利其器。根据范围分析，当时需要迁移的脚本有1000多个，用手工的方式一个脚本 一个脚本地迁移肯定能是不可行的，迁移完都不知猴年马月，所以必须要制作出一个能批量实现TD 脚本到GP脚本的自动迁移工具实现自动转化 SQL移植是脚本迁移中最大的部分，是系统迁移成功与否的关键因素。可以通过新旧语法映射开 发”ETL脚本转换程序“，对ETL脚本进行批量移植，预计可完成90％以上的修改，剩余再通过人工修 改，这样可以加快移植进度 、降低迁移工作量、提高程序规范。;虽然TD和GP都是采用的是标准SQL，但实际差异还是很大的，而且有些差异是不会报错体现的，只 是体现数据加工结果的差异上，所以这种差异往往只能在数据校验阶段才能发现，那么无疑纠错成 本就非常大，对整个迁移工作的影响也是非常不利地。根据迁移经验，总结了迁移过程中遇到的10 个影响最大的语法差异：;脚本迁移方面还有一个很重要的工作就是迁移后脚本的性能优化，做过迁移的都清楚，所谓自动化 的迁移，很大程度上只能做到功能上的迁移，非功能的迁移很多时候还是需要人工去分析、优化。 根据我们的迁移经???中，迁移脚本的性能优化可以分为数据库级、模型级、SQL级的优化。举例如 下： NOT IN 关联改成 NOT EXISTS GP对于使用NOT IN执行量表关联时，内部使用的算法效率低，一般都会在子查询中对大数据集做broadcast motion。 优化前：相关SQL执行时间超过5000秒； 优化后：相关SQL执行时间为630秒。 锁等待问题 如果一张目标表有多个数据源，且多个数据源的数据差不多时间到，就会存在对同一张表并行update/delete/insert等操作，这些操作对同一张来说，是互斥锁，会引 起锁等待。以我们迁移的某张表T举例，表T有39个来源系统，我们对表T的优化操作是：各个来源系统的处理脚本的目标表优化为分区表，并且新增分区字段，按来 源系统特征划分分区，操作时针对分区表操作。 优化前：表T所有源系统加工完成大概需要3~5小时； 优化后：表T所有源系统加工完成大概需要0.5小时。;15;15;16;该行的数据平台从Teradata迁移到Pivotal Greenplum（现VMware Greenplum）挺早之前就开始了， 本文所说的就是Teradata迁移到Greenplum第一期，从2016年的12月开始筹划，2017年3月算是正式 开始，2017年9月迁移完成，2017年11月上层应用系统正式切换。;20