数据模型迁移和数据迁移都紧密依赖于范围分析，需要根据范围分析的结果进行工作量评估、方案设计、计划排期等相关工作，所以本期将介绍范围分析、数据模型迁移、数据迁移模块的相关实施经验，以及一些经验总结。

一、范围分析 

范围分析是整个迁移工作的第一步，也是非常重要的一步。关于它的重要性，在第一期有过简单的说明。范围分析完不完备，准不准确，影响到后面迭代迁移次数的多少，范围分析相关工作做得完备、准确，那么会减少真正迁移时因模型缺失或作业缺失等范围缺失而导致的返工。既然范围分析工作这么重要，那该如何开展呢？

一般而言，迁移之初都需要明确具体的迁移目标。我们当时的目标就是把反洗钱基础数据迁移到GP上进行加工，并实现端到端迁移，使得反洗钱加工完全不需要TD。因为是要实现端到端的迁移，所以需要根据已知的范围逆向逐层分析出来。

（一）范围分析步骤

1. 已知范围识别

对于本案例来说就是FXQ基础数据及相关模型和作业配置等。

2. 作业范围分析

通过作业依赖关系分析出数据仓库的M层、P层、S层等各层需迁移的作业范围清单。作业范围分析一般可以通过作业依赖血缘图，逆向分析出各层需迁移的相关作业，如下图。

3. 脚本范围分析

由于作业配置与脚本有一定映射关系，所以可以根据前面步骤得到的需迁移作业范围清单，分析出需迁移的脚本范围清单。

4. 模型范围分析

一般而言，由于各个脚本中使用的数据模型的方式是固定，且有限的，所以可以通过关键字匹配识别出脚本中使用的所有数据模型。因此模型范围的分析是通过写脚本工具，实现对上一步骤得到的需迁移脚本范围清单中所有脚本的批量采集，并获得需迁移的模型范围清单。

5. 初始化数据范围分析

初始化数据范围分析其实就是需迁移数据范围分析。这步会比较复杂，因为TD负载太高，数据迁移速度不高，所以数据迁移范围需要尽可能的小，同时又要满足应用加工需求。也就是说要在满足应用加工需求的情况下，获取数据迁移范围的最小集。这就需要范围分析人员了解应用加工模型，以及应用加工对各个数据实体精确的使用范围，但通常迁移人员不是能很了解应用加工，所以只能深入各个脚本，通过阅读代码去获取精确的数据迁移范围。

（二）经验总结

通过以上的范围分析，一般能获取需迁移的作业范围、脚本范围、模型范围、和数据范围，但这些范围可能无法一下子做到完全准确，需要后面迁移的过程中不断地迭代，不断地完善。接下来根据现有的经验，总结范围分析这个阶段的一些主要问题：

1. 作业依赖不能完全体现实际上的加工依赖，导致部分需迁移范围不能通过最开始的范围分析确定出来，有些缺失的范围需在后续的测试、数据验证阶段发现，如下图。

2. 除对应用加工模型有经验丰富人员外，初始化数据范围分析通常需要范围分析人员通过深入脚本阅读代码的方式来分析、确定初始化的数据范围，效率较低，且容易有遗漏、缺失。

二、数据模型迁移 

数据模型迁移，其实就是把GP上的物理表结构和视图结构迁移到TD上，简单地说就是在TD上创建出和GP上一样的表或者视图。数据模型迁移主要分如下几个步骤：

1. 范围分析

分析出具体有哪些表或者视图，这在前一节有详细的描述，即可以通过写脚本工具的方式，从需要迁移的脚本中批量获取到需要迁移的表和视图清单。但这种方式只能识别面上一层的模型，也就是在脚本中有直接使用到的表和视图，至于这些表和视图是怎么加工出来的，脚本工具就没办法获取到。如果是物理表，它的数据血缘可能会体现在作业依赖上，当然也不一定完全准确。但更重要的是分析出来的需要迁移的视图或表是依赖于其他视图或物理表生成的，这个依赖关系不会体现在作业依赖上，只体现在模型语句中，所以这需要在后续的转换后模型创建步骤中，逐步发现缺失模型，不断完善分析出的数据模型迁移范围。

2. 批量模型转换

根据TD和GP语法差异，制作出模型自动转换工具，并利用数据模型自动转换工具，批量实现物理表和视图的迁移。

3. 转换后模型创建

为什么需要将转换后模型创建单独成一个步骤？是因为这一过程通常需要耗费一定的时间去迭代才能最终将转换后的模型都创建成功。视图创建的时候，容易出现该视图所需要的其他视图或者物理表未迁移，而导致该视图创建不成功的情况。这就需要将该视图需要的其他视图或者物理表加入到迁移范围中，再重新梳理更新需要迁移的作业范围、脚本范围、模型范围和数据范围。更新完后，再将新分析出来并转换完后的模型再进行创建，若又发现有模型的缺失，则需要再更新各迁移范围，依此类推，不断地迭代更新迁移范围。

4. 脚本空跑

脚本空跑也是验证数据模型迁移范围是否完备的重要一步，只有真正的脚本空跑过了，才能算是数据模型迁移范围的基本确定（当然，后面数据验证的时候，也可能会发现一些模型的缺失，但一般不会太多）。

三、数据初始化 

数据初始化主要是将TD上的初始化截面数据复制到GP中，作为初始化数据。这方面建行有个占优的地方，就是P9平台本身有为各个数据线系统提供了数据同步组件，这个组件既能实现全量或者增量将各类型数据库（GP/TD/ORACLE/HD）的数据非常高效地同步到各类型数据库（GP/TD/ORACLE/HD）中去。所以在做数据迁移的时候，可以复用P9平台的数据同步组件，当然，为了适应迁移工作的特殊性，在该组件的基础上，额外做了一定的改造。主要是为了数据迁移工作的效率，去掉了该数据同步组件的自动数据校验功能，并改为由人工批量校验方式来保证数据迁移的准确性。接下来阐述初始化数据迁移工作主要步骤。

（一）数据迁移步骤

1. 范围分析

分析确认哪些表需要做数据初始化，并且尽量精确每张表在满足加工用数的需求下的最小初始化量，即确认初始化时源表的最精准筛选条件。

2. 数据搬迁前处理

主要有两个工作，其一是确定初始化截面日期，即以哪个业务日期作为初始化的截面日期。在截面日期之前的数据，通过数据初始化的方式，用数据迁移工具，从TD同步到GP；在初始化截面日期以后的数据，在GP上以加工跑批的方式生成。其二是当前表备份，因为数据初始化是长期过程，当前表有时点问题，如果某张当前表没有及时备份，那么等当前表开始数据初始化迁移时，可能已经过了那个时点，那么里面的初始化数据就是错误的，所以当前表需要及时备份，初始化时从备份表迁移数据。

3. 数据搬迁

将数据从TD数据库复制到GP数据库；大表容易失败，需拆分为小表复制。

4. 数据验证

前面有介绍到，迁移过程中，为了保证数据迁移的效率，去除了原本P9数据同步工具中的自动数据校验功能，改为由人工批量的方式去校验。所以，需要批量进行验证初始化结果、范围是否准确，主要是确认各张表的各个批次是否有丢失，每个批次数据量是否准确。

5. 数据搬迁后处理

这步主要有两个工作，其一是拉链表退链，由于初始化截面后的数据需要在初始化数据的基础上进行跑批加工，所以需要将已经闭链的截面数据进行退链处理。其二是初始化数据去有空格处理等，由于TD可以自动去有空格，而GP无法自动去有空格，为了保证数据加工的一致性，需要对迁移后的数据统一做去有空格处理。

（二）经验总结

根据我们迁移经验，总结了数据初始化迁移工作中遇到的主要问题：

• 初始化数据体量大，初始化效率一般，耗时久

• 单表数据量大，容易超时等失败

• TD负载过高，容易报资源不足

据此，我们为后面做类似迁移工作的实施团队，总结了几点优化建议，希望对各位有用：

1. 初始化路径优化：

像我们当时来说，我们有两套TD集群，TD2系和TD6系。TD2系负载较高，所以如果在TD6系上存在的表尽量从TD6系迁移，如果模型GP集群上有，且能满足数据初始化需求，则最好直接从GP集群复制。

2. 初始化范围优化：

在不影响用数情况下，精简初始化量。这在前面强调过好几次了，因为确实很重要！实在是趟过太多这方面的坑！

3.初始化工具优化：

初始化数据迁移工具尽量摒弃非必须功能，生成专门初始化工具，做到“短小精悍”，提升效率。