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

1、大型国有银行数据平台应用迁移之路系统迁移目标和问题分析问题与挑战以Oracle RAC和Teradata一体机为基础的系统架构，缺乏弹性伸缩能力，无法快速应对灵活多变的业务需求；系统架构数据类平台或系统都面临处理能力的瓶颈，这导致数据处理时间窗口过长，严重影响了业务体验和业务决策， 像反洗钱这样的复杂系统，时常发生报送延迟的情况，严重的时候甚至延迟到一周以上。改善时效性刻不容缓系统性能当前系统以描述型分析为主，反映已发生的业务现状，不能对将来的各种业务进行前瞻性预测。审计合规缺乏 统一平台支撑，无法满足业务需求系统功能Teradata 数据仓库一体机进行了多次扩容，由于是专有设备，每次扩容耗费

2、了大量的人力、物力和财力，成本 居高不下系统成本问题与 挑战2海量并行、完全无共享架构基于开放的X86 服务器搭建集群弹性架构，可根据具体需求缩放集群规模与SAS无缝集成，支持库内挖掘支持海量数据并行高效处理和智能分析完备高可用性保证系统持续有效筛选 识别选型依据经过充分的调研、选型测试、专家评审，最终确定新一代大数据处理产品采用Pivotal Greenplum在这样的背景下，开始Teradata迁移Greenplum的“长征之旅”。系统选型346迁移前，需要梳理具体有哪些工作，哪些事项，再对各项工作进行计划安排。当时我们梳理出主要 工作有范围分析、环境准备、数据模型迁移、数据初始化、脚本迁

3、移、调度迁移、数据一致性校验、 应用切换等工作。迁移总体方法步骤迁移总体工作任务阶段划分范围分析分析迁移范围，涉及数据区分析各数据区需迁移数据、脚本、作业、模型环境准备数据模型迁移迁移工作步骤数据初始化脚本迁移调度迁移数据一致性效验应用切换测试环境及生产设备准备数据库环境、ETL环境、调度环境字段类型及建模语法差异分析，批量模型迁移工具开发、模型分析、模 型迁移初始全量及增量追数方案，特大表单独方案、迁移路径语法、函数等差异分析、脚本迁移工具开发、脚本迁移、测试调度关系及作业配置迁移效验方案确定、校验工具开发，一致性差异分析应用系统人员对迁移数据进行确认应用系统由TD切换到GP范围分析是整个迁

4、移工作的第一步，也是非常重要的一步。关于它的重要性，在第一期有过简单的 说明。范围分析完不完备，准不准确，影响到后面迭代迁移次数的多少，范围分析相关工作做得完 备、准确，那么会减少真正迁移时因模型缺失或作业缺失等范围缺失而导致的返工。既然范围分析 工作这么重要，那该如何开展呢？数据迁移的范围分析迁移范围分析已知范围识别对于本案例来说就是FXQ基础数 据及相关模型和作业配置等通过作业依赖关系分析出数据 仓库的M层、P层、S层等各层 需迁移的作业范围清单。作业 范围分析一般可以通过作业依 赖血缘图，逆向分析出各层需 迁移的相关作业由于作业配置与脚本有一定映射 关系，所以可以根据前面步骤得 到的需迁

5、移作业范围清单，分析 出需迁移的脚本范围清单。一般而言，由于各个脚本中使 用的数据模型的方式是固定， 且有限的，所以可以通过关键 字匹配识别出脚本中使用的所 有数据模型。因此模型范围的 分析是通过写脚本工具，实现 对上一步骤得到的需迁移脚本 范围清单中所有脚本的批量采 集，并获得需迁移的模型范围 清单。作业范围分析脚本范围分析模型范围分析初始化数据范围分析这 步 会 比 较 复 杂 ， 因 为 Teradata负载太高，数据迁移速 度不高，所以数据迁移范围需 要尽可能的小，同时又要满足 应用加工需求。也就是说要在 满足应用加工需求的情况下， 获取数据迁移范围的最小集67数据模型迁移策略数据模型

6、迁移DDL转换程序Greenplum DDL脚本数据字典 抽取Teradata DDL脚本8执行建表Greemplum字段类型转换规则Teradata字符类型 Char(n)Varchar(n)Long Varchar SmallInt Integer Dec(m,n)Float Date TimeTimestampGreenplum字符类型character (n), char(n)character varying(n), varchar(n)textsmallint, int2integer, int, int4numericfloat8, floatdatetimetime with

7、time zoneDDL数据模型转换可以实现自动转换，通过DDL转换程序将Teradata 的DDL脚本批量、自动转换为Greenplum DDL语法。Teradata分布健数据压缩、行列存储数据分区字段类型映射数据初始化主要是将TD上的初始化截面数据复制到GP中，作为初始化数据。 “数据同步组件”是该 行开发的数据复制组件，可实现全量或者增量将各类型数据库（GP/TD/ORACLE/HD）的数据非常高 效地同步到各类型数据库（GP/TD/ORACLE/HD）。为了适应迁移工作的特殊性，在该组件的基础上，额外做了一定的改造主要是为了数据迁移工作的 效率，去掉了该数据同步组件的自动数据校验功能，

8、并改为由人工批量校验方式来保证数据迁移的 准确性数据初始化数据初始化-数据迁移工具TeradataGreemplumfastexportExternal table load数据 模型Insert外 部 临 时 表数据复制 组件9初始化数据迁移工作关键点：数据初始化数据初始化-数据迁移工作关键点范围分析分析确认哪些表需要做数据初 始化，并且尽量精确每张表在 满足加工用数的需求下的最小 初始化量，即确认初始化时源 表的最精准筛选条件。确定初始化截面日期，即以哪个业务日期作为初始化的截面将数据从TD数据库复制到GP数据库；大表容易失败，需拆分为日期。在截面日期之前的数据， 小表复制。 通过数据初始

9、化的方式，用数据迁移工具，从TD同步到GP；在初始化截面日期以后的数据， 在GP上以加工跑批的方式生成。搬迁前需要做好搬迁数据备份， 以防止数据变动带来的影响所以，需要批量进行验证初始 化结果、范围是否准确，主要 是确认各张表的各个批次是否 有丢失，每个批次数据量是否 准确。数据搬迁前处理数据搬迁数据验证数据搬迁后处理10这步主要有两个工作，其一是 拉链表退链，由于初始化截面 后的数据需要在初始化数据的 基础上进行跑批加工，所以需 要将已经闭链的截面数据进行 退链处理。其二是初始化数据 去有空格处理等，由于TD可以 自动去有空格，而GP无法自动 去有空格，为了保证数据加工 的一致性，需要对迁移

10、后的数 据统一做去有空格处理。工欲善其事必先利其器。根据范围分析，当时需要迁移的脚本有1000多个，用手工的方式一个脚本 一个脚本地迁移肯定能是不可行的，迁移完都不知猴年马月，所以必须要制作出一个能批量实现TD 脚本到GP脚本的自动迁移工具实现自动转化SQL移植是脚本迁移中最大的部分，是系统迁移成功与否的关键因素。可以通过新旧语法映射开 发”ETL脚本转换程序“，对ETL脚本进行批量移植，预计可完成90以上的修改，剩余再通过人工修 改，这样可以加快移植进度 、降低迁移工作量、提高程序规范。ETL脚本和调度迁移脚本转换和迁移ETL脚本转换程序Teradata ETL脚本Greenplum ETL

11、脚本V2Perl脚本登录、密码验证、管道调用批量修改Teradata函数，如日期函数、字符处理函数、 CHAR,NULLIFZERO等需要做相应转换Teradata事务，BT/ET语法需要修改成标准ANSII语法Teradata创建临时语法需要修改日期FOARMAT手工修改字段别名、子查询别名Teradata的OLAP语法，如rank，qualify，csum等需要转换 为Greemplum的OLAP语法。Greenplum ETL脚本V1空跑测试带数验证11虽然TD和GP都是采用的是标准SQL，但实际差异还是很大的，而且有些差异是不会报错体现的，只 是体现数据加工结果的差异上，所以这种差异往

12、往只能在数据校验阶段才能发现，那么无疑纠错成 本就非常大，对整个迁移工作的影响也是非常不利地。根据迁移经验，总结了迁移过程中遇到的10 个影响最大的语法差异：12ETL脚本和调度迁移脚本迁移-语法差异序号差异项TDGP影响度影响范围1字段值长度超过字段定义长度自动截取报错退出特别严重特别广2大小写敏感不敏感敏感特别严重特别广3自动去空格会不会特别严重特别广4S层加载自动去重会不会严重广5数据存储字符集（汉字存储截取）GBKUTF8严重广6TO_DATE(日期类型字段，YYYYMMDD)正确错误特别严重广7乱码自动替换为？保留原编码严重广8MAX取值严重特别广9ROW_NUMBER随机取值10浮

13、点数0存储不一致.000.00一般一般脚本迁移方面还有一个很重要的工作就是迁移后脚本的性能优化，做过迁移的都清楚，所谓自动化 的迁移，很大程度上只能做到功能上的迁移，非功能的迁移很多时候还是需要人工去分析、优化。 根据我们的迁移经验中，迁移脚本的性能优化可以分为数据库级、模型级、SQL级的优化。举例如 下：NOT IN 关联改成 NOT EXISTSGP对于使用NOT IN执行量表关联时，内部使用的算法效率低，一般都会在子查询中对大数据集做broadcast motion。优化前：相关SQL执行时间超过5000秒； 优化后：相关SQL执行时间为630秒。锁等待问题如果一张目标表有多个数据源，且

14、多个数据源的数据差不多时间到，就会存在对同一张表并行update/delete/insert等操作，这些操作对同一张来说，是互斥锁，会引 起锁等待。以我们迁移的某张表T举例，表T有39个来源系统，我们对表T的优化操作是：各个来源系统的处理脚本的目标表优化为分区表，并且新增分区字段，按来 源系统特征划分分区，操作时针对分区表操作。优化前：表T所有源系统加工完成大概需要35小时； 优化后：表T所有源系统加工完成大概需要0.5小时。13ETL脚本和调度迁移脚本迁移-性能调优15应用迁移的数据校验，一般是以迁移之前跑批产生的数据作为标准，比对迁移后跑批产生的数据， 如果能比对上，两边数据一致，则认为数

15、据校验成功。在我们的案例里，是以Teradata上跑批生成 数据为标准，校验迁移后Greenplum跑批生成的数据。数据一致性校验数据一致性校验研发出数据一致性校验工具后，差异识别环节并不需要花费太 多的时间、精力。所以，事实上数据校验的时间主要是消耗在 怎么分析出差异的原因，也就是差异分析环节。从配置表中获取表所需检查的类型信息结果采集记录数采集抽样比对求和采集求和比对记录数比对结构比对数据一致性校验工具15序号差异项TDGP差异处理1字段值长度超过字段定义长度自动截取报错退出对GP模型及加工脚本中临时表字段扩 长，保证数据完整性2大小写敏感不敏感敏感1、数据优化：对数据做UPPER处理2、

16、脚本优化：关联条件UPPER处理3自动去空格会不会1、存量数据去右空格处理2、关联条件RTRIM4S层加载自动去重会不会对可能重复的表做去重处理5数据存储字符集（汉字存储截取）GBKUTF8SUBSTR时，调整长度6TO_DATE(日期类型字段，YYYYMMDD)正确错误TO_DATE（TO_CHAR(日期类型字 段,YYYYMMDD),YYYYMMDD)7乱码自动替换为？保留原编码忽略8MAX取值忽略9ROW_NUMBER随机取值忽略10浮点数0存储不一致.000.00忽略16序号差异原因差异处理1跑数时点不一致当前表跑批时点不一致，导致数据核对不上2脚本转换问题转换规则缺失，导致脚本转换失

17、真，跑出数据错误3迁移范围存在缺失范围有遗漏，导致迁移结果数据缺失或错误4作业依赖错误作业依赖错误，导致依赖数据尚未就绪就开始加工数据，导致结 果数据错误5空值和NULL的不一致在比对SQL中，空值和NULL被识别不一致该行的数据平台从Teradata迁移到Pivotal Greenplum（现VMware Greenplum）挺早之前就开始了， 本文所说的就是Teradata迁移到Greenplum第一期，从2016年的12月开始筹划，2017年3月算是正式 开始，2017年9月迁移完成，2017年11月上层应用系统正式切换。迁移成果总结迁移成果经过半年多的努力，最终成功迁移了300T左右的初始化数据迁移，1000多个 物理表，1500多个作业，1200多个脚本，迁移系统至今稳定运行。对迁移系统影响：反洗钱系统切换到我们迁移后的Greenplum仓库数据后，这两年甚少听到报送延迟问题， 这与迁移之前时常报送延迟一周以上的情况对比，效果是非常明显的。而且切换后，整 个反洗钱日常报送时效性提升了78小时，月末提升23天（2018年1月统计数字）。对Teradata影响：反洗钱系统切换到Greenplum以后，正常运行了一段时间后，Teradata下线了一些不再需要加工的作业，并且减少了原本反洗钱每天需要从Teradat