,大型国有银行数据平台应用迁移之路,系统迁移目标和问题分析 问题与挑战,以Oracle RAC和Teradata一体机为基础的系统架构，缺乏弹性伸缩能力，无法快速应对灵活多变的业务需求；,系统架构,数据类平台或系统都面临处理能力的瓶颈，这导致数据处理时间窗口过长，严重影响了业务体验和业务决策， 像反洗钱这样的复杂系统，时常发生报送延迟的情况，严重的时候甚至延迟到一周以上。改善时效性刻不容缓,系统性能,当前系统以描述型分析为主，反映已发生的业务现状，不能对将来的各种业务进行前瞻性预测。审计合规缺乏 统一平台支撑，无法满足业务需求,系统功能,Teradata 数据仓库一体机进行了多次扩容，由于是专有设备，每次扩容耗费了大量的人力、物力和财力，成本 居高不下,系统成本,问题与 挑战,2,海量并行、完全无共享架构 基于开放的X86 服务器搭建集群 弹性架构，可根据具体需求缩放集群规模,与SAS无缝集成，支持库内挖掘 支持海量数据并行高效处理和智能分析 完备高可用性保证系统持续有效,筛选 识别,选型依据,经过充分的调研、选型测试、专家评审，最终确定新一代大数据处理产品采用Pivotal Greenplum 在这样的背景下，开始Teradata迁移Greenplum的“长征之旅”。 系统选型,3,4,6,迁移前，需要梳理具体有哪些工作，哪些事项，再对各项工作进行计划安排。当时我们梳理出主要 工作有范围分析、环境准备、数据模型迁移、数据初始化、脚本迁移、调度迁移、数据一致性校验、 应用切换等工作。,迁移总体方法步骤 迁移总体工作任务阶段划分,范围分析,分析迁移范围，涉及数据区 分析各数据区需迁移数据、脚本、作业、模型,环境准备,数据模型迁移,迁移工作步骤,数据初始化,脚本迁移,调度迁移,数据一致性效验,应用切换,测试环境及生产设备准备 数据库环境、ETL环境、调度环境,字段类型及建模语法差异分析，批量模型迁移工具开发、模型分析、模 型迁移,初始全量及增量追数方案，特大表单独方案、迁移路径,语法、函数等差异分析、脚本迁移工具开发、脚本迁移、测试,调度关系及作业配置迁移,效验方案确定、校验工具开发，一致性差异分析,应用系统人员对迁移数据进行确认 应用系统由TD切换到GP,范围分析是整个迁移工作的第一步，也是非常重要的一步。关于它的重要性，在第一期有过简单的 说明。范围分析完不完备，准不准确，影响到后面迭代迁移次数的多少，范围分析相关工作做得完 备、准确，那么会减少真正迁移时因模型缺失或作业缺失等范围缺失而导致的返工。既然范围分析 工作这么重要，那该如何开展呢？,数据迁移的范围分析 迁移范围分析,已知范围识别,对于本案例来说就是FXQ基础数 据及相关模型和作业配置等,通过作业依赖关系分析出数据 仓库的M层、P层、S层等各层 需迁移的作业范围清单。作业 范围分析一般可以通过作业依 赖血缘图，逆向分析出各层需 迁移的相关作业,由于作业配置与脚本有一定映射 关系，所以可以根据前面步骤得 到的需迁移作业范围清单，分析 出需迁移的脚本范围清单。,一般而言，由于各个脚本中使 用的数据模型的方式是固定， 且有限的，所以可以通过关键 字匹配识别出脚本中使用的所 有数据模型。因此模型范围的 分析是通过写脚本工具，实现 对上一步骤得到的需迁移脚本 范围清单中所有脚本的批量采 集，并获得需迁移的模型范围 清单。,作业范围分析,脚本范围分析,模型范围分析,初始化数据范围分析,这 步 会 比 较 复 杂 ， 因 为 Teradata负载太高，数据迁移速 度不高，所以数据迁移范围需 要尽可能的小，同时又要满足 应用加工需求。也就是说要在 满足应用加工需求的情况下， 获取数据迁移范围的最小集,6,7,数据模型迁移策略 数据模型迁移,Greenplum DDL脚本,数据字典 抽取 Teradata DDL脚本,8,执行建表 Greemplum,DDL数据模型转换可以实现自动转换，通过DDL转换程序将Teradata 的DDL脚本批量、自动转换为 Greenplum DDL语法。 Teradata 分布健,数据压缩、行列存储 数据分区 字段类型映射,数据初始化主要是将TD上的初始化截面数据复制到GP中，作为初始化数据。 “数据同步组件”是该 行开发的数据复制组件，可实现全量或者增量将各类型数据库（GP/TD/ORACLE/HD）的数据非常高 效地同步到各类型数据库（GP/TD/ORACLE/HD）。 为了适应迁移工作的特殊性，在该组件的基础上，额外做了一定的改造主要是为了数据迁移工作的 效率，去掉了该数据同步组件的自动数据校验功能，并改为由人工批量校验方式来保证数据迁移的 准确性,数据初始化 数据初始化-数据迁移工具,Teradata,Greemplum,fastexport,External table load,数据,模型,Insert 外 部 临 时 表,数据复制 组件,9,初始化数据迁移工作关键点：,数据初始化 数据初始化-数据迁移工作关键点,范围分析,分析确认哪些表需要做数据初 始化，并且尽量精确每张表在 满足加工用数的需求下的最小 初始化量，即确认初始化时源 表的最精准筛选条件。,确定初始化截面日期，即以哪,个业务日期作为初始化的截面,将数据从TD数据库复制到GP数,据库；大表容易失败，需拆分为,日期。在截面日期之前的数据， 小表复制。 通过数据初始化的方式，用数 据迁移工具，从TD同步到GP； 在初始化截面日期以后的数据， 在GP上以加工跑批的方式生成。 搬迁前需要做好搬迁数据备份， 以防止数据变动带来的影响,所以，需要批量进行验证初始 化结果、范围是否准确，主要 是确认各张表的各个批次是否 有丢失，每个批次数据量是否 准确。,数据搬迁前处理,数据搬迁,数据验证,数据搬迁后处理,10,这步主要有两个工作，其一是 拉链表退链，由于初始化截面 后的数据需要在初始化数据的 基础上进行跑批加工，所以需 要将已经闭链的截面数据进行 退链处理。其二是初始化数据 去有空格处理等，由于TD可以 自动去有空格，而GP无法自动 去有空格，为了保证数据加工 的一致性，需要对迁移后的数 据统一做去有空格处理。,工欲善其事必先利其器。根据范围分析，当时需要迁移的脚本有1000多个，用手工的方式一个脚本 一个脚本地迁移肯定能是不可行的，迁移完都不知猴年马月，所以必须要制作出一个能批量实现TD 脚本到GP脚本的自动迁移工具实现自动转化 SQL移植是脚本迁移中最大的部分，是系统迁移成功与否的关键因素。可以通过新旧语法映射开 发”ETL脚本转换程序“，对ETL脚本进行批量移植，预计可完成90以上的修改，剩余再通过人工修 改，这样可以加快移植进度 、降低迁移工作量、提高程序规范。,ETL脚本和调度迁移 脚本转换和迁移,Teradata ETL脚本,Greenplum ETL脚本V2,Perl脚本登录、密码验证、管道调用批量修改 Teradata函数，如日期函数、字符处理函数、 CHAR,NULLIFZERO等需要做相应转换 Teradata事务，BT/ET语法需要修改成标准ANSII语法 Teradata创建临时语法需要修改 日期FOARMAT,手工修改,字段别名、子查询别名 Teradata的OLAP语法，如rank，qualify，csum等需要转换 为Greemplum的OLAP语法。,Greenplum ETL脚本V1,空跑测试,带数验证,11,虽然TD和GP都是采用的是标准SQL，但实际差异还是很大的，而且有些差异是不会报错体现的，只 是体现数据加工结果的差异上，所以这种差异往往只能在数据校验阶段才能发现，那么无疑纠错成 本就非常大，对整个迁移工作的影响也是非常不利地。根据迁移经验，总结了迁移过程中遇到的10 个影响最大的语法差异：,12,ETL脚本和调度迁移 脚本迁移-语法差异,脚本迁移方面还有一个很重要的工作就是迁移后脚本的性能优化，做过迁移的都清楚，所谓自动化 的迁移，很大程度上只能做到功能上的迁移，非功能的迁移很多时候还是需要人工去分析、优化。 根据我们的迁移经验中，迁移脚本的性能优化可以分为数据库级、模型级、SQL级的优化。举例如 下： NOT IN 关联改成 NOT EXISTS GP对于使用NOT IN执行量表关联时，内部使用的算法效率低，一般都会在子查询中对大数据集做broadcast motion。 优化前：相关SQL执行时间超过5000秒； 优化后：相关SQL执行时间为630秒。 锁等待问题 如果一张目标表有多个数据源，且多个数据源的数据差不多时间到，就会存在对同一张表并行update/delete/insert等操作，这些操作对同一张来说，是互斥锁，会引 起锁等待。以我们迁移的某张表T举例，表T有39个来源系统，我们对表T的优化操作是：各个来源系统的处理脚本的目标表优化为分区表，并且新增分区字段，按来 源系统特征划分分区，操作时针对分区表操作。 优化前：表T所有源系统加工完成大概需要35小时； 优化后：表T所有源系统加工完成大概需要0.5小时。,13,ETL脚本和调度迁移 脚本迁移-性能调优,15,应用迁移的数据校验，一般是以迁移之前跑批产生的数据作为标准，比对迁移后跑批产生的数据， 如果能比对上，两边数据一致，则认为数据校验成功。在我们的案例里，是以Teradata上跑批生成 数据为标准，校验迁移后Greenplum跑批生成的数据。,数据一致性校验 数据一致性校验,研发出数据一致性校验工具后，差异识别环节并不需要花费太 多的时间、精力。所以，事实上数据校验的时间主要是消耗在 怎么分析出差异的原因，也就是差异分析环节。,从配置表中获取表 所需检查的类型信息,结果采集,记录数采集,抽样比对,求和采集,求和比对,记录数比对,结构比对,数据一致性校验工具,15,16,该行的数据平台从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下线了一些不再需 要加工的作业，并且减少了原本反洗钱每天需要从Teradata复制基础数据的大量复制作业， 整个Teradata的负载下降也相当明显，Teradata上的各应用加工时效也实现一定程度提升。 对后续TD2GP迁移项目影响： 作为第一期项目，我们成功的制作出了一系列迁移工