数仓系统迁移方案

数仓系统迁移方案

第1章. 项目背景和目的

首先，了解项目的背景和目的，才能设计出满足客户需求的迁移方案。

1.1. 项目背景

XX银行基于Teradata一体机构建的数据仓库，存在成本高、可替换性差、在线升级能力弱等问题，希望引入扩展性更强、具有成本竞争力、在线升级能力强的产品替代。

1.2. 项目目标

项目总体目标：替换的数据仓库产品能力要不低于现网Teradata的整体能力，而且要满足数仓上下游生态工具的对接，做到对应用的改动量最小化。

第2章. 数仓迁移方案设计

2.1. 需求分析与规划设计 

2.1.1. 数仓迁移总体规划

数仓迁移是一个系统的复杂的过程，涉及数据迁移、加工逻辑迁移及应用改造。在掌握通用迁移方法论的基础上，还需要结合源数据库和目标数据库的数据库特性进行迁移方案的优化，不然就有可能导致迁移项目失败，浪费人力和财力。比如：分为两个大的阶段进行，第一阶段从xx日期到xx日期完成主仓迁移，第二阶段从xx日期到xx日期完成集市层迁移等。

2.1.2. 需求分析及调研评估

2.1.2.1.需求调研分析

信息收集会贯穿整个数仓迁移项目的生命周期，通常需要多次多种方式的收集动作。在不同阶段使用的信息收集方法也不相同。

• 数仓信息收集

1) 数据库环境信息调研表

比如：源数据版本，并发数，字符集，函数等

2) 源数据搬迁调研表

比如：源数据库的数据架构、数据量等。

3) 第三方软件调研

比如：ETL的调度工具，对接的分析工具等。

4) 用户权限调研

比如：总共有多少个用户、多少个应用，用户与应用的权限关系等。

5) 特定源数据库技术（以下为示例）

如有，请描述。

2.1.2.2. 系统架构

系统架构主要表述了契合一个环境的系统的基本元素及元素之间的关系构成的结构集，在环境中体现出来的基本属性，以及设计与演进的原则。通过系统架构，我们通常可以粗略了解该系统的一个全貌，包括该系统由哪些组件构成，他们的关系是什么，以及与其有关联的上下文系统的关系。比如常见的金融数仓系统架构主要由数据仓库系统、作业调度系统、文件或数据传输系统、上游业务系统、下游应用系统等构成，他们直接通过一定的关系有机地组成了一个数据仓库的整体。比如

2.1.2.3. 数据架构

数据架构，可以帮助我们熟悉数据的源头以及数据在整个系统中的一个流转过程。比如，下图是一个常见的金融系统的数据架构。

2.1.2.4. 调研评估

迁移评估调研是整个数仓迁移工作的基础，为数仓迁移方案规划和实施提供信息基础。并对迁移技术可行性、实施难度、风险、资源需求进行整体分析和评估。

迁移评估调研主要包括以下内容：

1) 信息调研：通过上述信息调研和原厂以往经验，认为可以从当前环境中将数据迁移到GaussDB数据库。

2) 业务关联性分析和评估：根据上述基本信息调研，评估是否可以对接其关联的系统。

3) 迁移风险分析和评估：可能存在极少数兼容性的问题或者数值型精度的问题，评估风险可控。

2.2. 环境准备

四套环境：原数仓的比对环境、新数仓的单元测试环境、集成测试环境和生产环境。

2.2.1. 环境部署方案

GaussDB(DWS)系统的网络划分为2个平面，即业务平面和管理平面，两个平面之间采用物理隔离的方式进行部署，保证业务、管理各自网络的安全性。主备管理节点还支持设置外部管理网络的IP地址，用户可以通过外部管理网络进行集群管理。

采用双平面组网时，集群中每个节点分别接入管理平面和业务平面，每个节点需要准备一个管理IP地址和一个业务IP地址，每个IP地址用两个网络接口配置Bond，分别接入两个接入交换机。各节点的业务平面建议采用25GE带宽，业务平面接入交换机与汇聚交换机之间建议采用25GE带宽，业务平面汇聚交换机的堆叠带宽建议设置为40GE。

2.2.2. 数据库设计

数据库设计需要考虑的问题：

1、 创建数据库时，使用什么字符集？

比如使用UTF8 or latin字符集

2、 目标数据库与原数据库的特性差异及对应关系

比如：Teradata是按照”库，子库”这样的方式进行的单元组织；

GaussDB(DWS)是按照“库，Schema”这样的方式进行的单元组织。

两者转换后的对应关系，比如：

原Teradata的根库DBC转换到GaussDB以后为一个schema；

（之所以仍然保留DBC是因为我们脚本中使用了很多原dbc的系统表，为了减小业务脚本的改动量，我们保留该Schema）。

3、 用户及权限管理

用户的权限设计应该与原设计基本相同，数据库的用户权限管理与原Teradata的权限管理的形式基本一致。

原Teradata库中的权限设计中将每个库的权限拆成四类权限组：

3.1 表和视图的查询访问权限(查询)

3.2 表和视图的增删改访问权限(IDU)

3.3 创建对象、清空表、修改对象的约束等权限(Tab)

3.4 函数执行、序列访问等其他权限(其他)

3.5 作业调度方案

3.6 作业调度通常可以采用与原来一致的调度方式即可。

3.7 迁移工具

迁移工具通常分两类：

一类考虑如何将数据从源数据库中搬迁到目标数据库中；

比如DSC工具。

一类考虑如何根据目标数据库生成业务脚本：

比如XX银行的IDE工具

3.4. 迁移策略

3.4.1. 迁移策略分析

常见的三种迁移策略：

3.4.2. 迁移策略的选择

根据信息调研以及业务的不同、目标和计划的不同，综合评估后选择上述其中之一即可；比如zx客户选择了“渐进式迁移”，而hg客户选择了“重新设计迁移”。

3.5. 迁移实施计划

通常根据客户的目标和总体计划倒排计划，不详述。

3.6. 迁移流程

从异构数据库迁移到GaussDB(DWS)数据库，一般要经过需求调研与评估→环境准备→分析设计→开发→测试→切换六个阶段，期间涉及数据库厂商、应用开发商、业务部门、科技部门等多个部门和组织的协同配合，为了保证迁移项目成功，每一个环节都要仔细分析并加以充分验证。

3.6.1. 迁移对象分类

数仓迁移是一个系统的复杂的过程，涉及数据迁移、加工逻辑迁移及应用改造。

为了将整个工程变得简单化，通常情况会将迁移对象分为以下几大类，包括元数据迁移，业务数据迁移，业务脚本迁移，调度系统迁移等。

在这几大类的基础上，通常还会结合客户的实际情况分阶段，分层次等手段进一步拆解任务。

3.6.2. 元数据迁移

3.6.2.1. 元数据迁移方案

元数据迁移包括源数据库的库，表，视图，函数，用户及权限等；首先从源库中读取建表的DDL等信息；通过人工创建或者DSC语法迁移工具自动化实现语法的转译和改写后，在目标库中执行创建，并进行测试和验证；语法迁移工具将显示迁移过程状态，并用日志记录操作过程中发生的错误。

3.6.2.2. 各模块元数据迁移方案

• 缓冲层元数据迁移

数据缓冲层包括接收的核心系统、个贷系统等业务系统的数据。数据以增量或全量形式进入数据仓库，表数量、脚本程序数量较大，缓冲层表是根据DDL每日根据数据加载程序自动生成“表名+数据日期”的数据表。

主要工作包括：统计需要完成多少DDL、视图，函数，用户及权限的迁移等。

• 主题层元数据迁移

主题加工层是数据仓库的核心部分，采用三范式设计。当前银行数仓主要采用FS-LDM主题模型设计。

主要工作包括：统计需要完成多少DDL、视图，函数，用户及权限的迁移等。

• 汇总层元数据迁移

汇总层又叫共性加工层，通常分为明细加工层、汇总加工层；是对主题模型的轻度汇总。

主要工作包括：统计需要完成多少DDL、视图，函数，用户及权限的迁移等。

• 集市元数据迁移

集市主要是根据不同的业务进行划分的应用；比如监管报送、1104报表等。

主要工作包括：统计需要完成多少DDL、视图，函数，用户及权限的迁移等。

3.6.3. 作业脚本迁移

3.6.3.1. 作业迁移方案

业务迁移，主要是将作业脚本中Teradata的SQL语法等信息通过语法迁移工具自动化实现转换为GaussDB(DWS)语法，实现作业一对一的迁移, 作业转换后需要测试功能及性能调优；语法迁移工具将显示迁移过程状态，并用日志记录操作过程中发生的错误。

各个模块的迁移方法同“元数据迁移”类似，需要根据不同的模块分别调研并统计需要迁移的作业等，不再赘述。

3.6.4. 业务数据迁移

在数仓迁移项目中，现有存量数据迁移占据着非常重要的位置，通常在数据库元数据迁移完成之后进行，主要包括历史数据迁移和实时数据迁移，可使用迁移工具将数据从源数据库迁移到目标数据库。

3.6.4.1 各模块数据迁移方案

根据数据架构，调研每个模块需要迁移的数据，方法类似“元数据迁移”，不再赘述。

3.6.5. 数据核验方案

3.6.5.1. 数据核验目标

数据检核的目标主要有：

据核验的目标是比对新平台的业务数据与原平台的业务数据一致。

为了达到以上目标，需要考虑以下几个方面：

• 表级记录数一致

• 表级记录sum值一致

• 表级按照维度分类一致

• 记录级的MD5值一致

3.6.5.2. 各模块数据核验方案

各模块的验证方案需要根据数据架构进行调研并参照“元数据迁移”的方法进行验证。

3.6.6. 并行期策略方案

3.6.6.1. 作业追批方案

对于业务数据迁移，一般采用首次全量导出导入，之后通过增量文件追批的方式进行。在保证调度系统一致，首次全量验证通过以后，可以开始追批。不同的环境，追批的标准不同，开发测试环境可以进行多轮追批，集成测试环境一般设置2~3轮的追批，而生产环境一般是两轮的的追批方式。

3.6.7. 应用切换方案

3.6.7.1. 应用切换原则

应用切换的原则主要有：

1) 应用切换要确保原来的数据及任务平稳从原来的源环境过渡到目标环境。

2) 数据迁移的上线，要稳抓稳打，逐步推进。或分层、或分应用，分阶段、分步骤逐步上线。

3) 确保切换前后数据的完整性；也就是转换过程中不能丢失数据。

4) 确保切换前后加工任务的工作效率，达到项目要求的效率。