从某保险集团看企业级数据仓库迁移技术_杨进玉专栏

本文研究的数据仓库迁移方案以某保险集团的数据仓库迁移为例，概述了数据迁移的技术和步骤，以及异构数据仓库之间进行数据迁移所存在的问题和解决方法。

险企对数据仓库的迁移，主要有两方面的原因。一方面是将数据仓库的元数据（技术元数据与业务元数据）迁移到性能更加优越的平台上，另一方面是为了规范和优化物理模型、程序等。数据仓库技术的不断成熟，使其对海量数据的处理能力愈加卓越。目前各个保险集团正在进行以客户为中心的战略转型，而不断增长的客户数据和业务数据，对数据仓库的性能提出了更高的要求。为了及时满足企业对数据仓库的应用需求，需要把EDW（Enterprise Data Warehouse，企业级数据仓库）迁移到性能更强大，并行计算能力更卓越，业务处理效率更迅速的平台上(比如GreenPlum平台，Teradata平台，Netezza平台等）。

总之，企业级数据仓库的迁移不仅仅是为了提升系统的性能, 更是期望迁移之后的数据仓库能够为集市层（比如，数据挖掘部署，审计集市，客户关系管理，数据质量管理等）迅速而灵活地提供底层的基础数据。本文研究的数据仓库迁移方案以某保险集团的数据仓库迁移为例，概述了数据迁移的技术和步骤，以及异构数据仓库之间进行数据迁移所存在的问题和解决方法。

Greenplum数据仓库解决方案的一个核心的功能是，它采用了“无共享”的开放平台的MPP架构，此架构是为商业智能（BI,business intelligence）和海量并行处理（MPP,Massive parallel processing）而设计。目前，最普遍的关系数据库管理系统（如Oracle或Microsoft SQL Server），都是利用“共享磁盘”架构来实现数据处理，会牺牲单个查询性能和并行性能。而使用Greenplum 数据库提供的MPP架构，数据在多个服务器区段间会自动分区，而各分区拥有并管理整体数据的不同部分；所有的通信是通过网络互连完成，没有磁盘级共享或连接，使其成为一个“无共享”架构。Greenplum数据库提供的MPP架构为磁盘的每一个环节提供了一个专门的、独立的高带宽通道，段上的服务器可以以一个完全并行的方式处理每个查询，并根据查询计划在段之间有效地移动数据，因此，相比普通的数据库系统，该系统提供了更高的可扩展性。

1、迁移需求分析

该保险集团面对大量的历史数据，其数据仓库也面临着如下问题：①系统运行速度慢，影响业务开展；②数据入口不一致，无统一的数据视图；③脏数据多，系统可维护性差；④技术相对落后, 无法满足新的业务分析需求。新的数据仓库系统要求在满足现有业务需求不变的情况下，提升系统速度、统一数据入口，建立起面向多主题的、集成的、相对稳定的、反映历史变化的数据集合, 同时可以优化面向数据挖掘等高级工具，为数据集市，客户关系管理，报表平台，财务信息共享集市等提供唯一的数据源支撑。在充分调研和了解了源数据仓库系统相关的软硬件配置、版本、体系架构、数据、应用等基础上，决定最大限度的保留和复用旧系统的ETL服务层、数据展现层。尽量避免对源系统结构做改动和对前端应用的改变。

数据仓库迁移策略需分别考虑其逻辑模型和物理模型在迁移之后的一致性。在逻辑模型方面，尽量确保迁移工作集中在基础详细数据模型层的ETL部分，确保EDW信息平台的迁移对前端数据仓库应用是透明的，避免对业务用户的影响。需求分析阶段的目标是为了明确数据迁移的业务需求和相关的工作范围，重点是源数据如何转换成目标系统所需的数据。通常来说，迁移需求分析通常包含以下几点。

（1）源系统数据属性分析。主要分析原系统中数据所运行的环境，数据量的大小及其逻辑上的分布特性，数据表的分区情况，数据的存储方式等。比如对大表的存储和压缩的方式。用户量，数据量，表个数，脚本个数，I/O 吞吐量，是否存在性能瓶颈等。

（2）数据类型划分。按照数据性质可以划分为与交易相关的业务数据与客户数据、与交易无关的业务和客户数据、临时类数据、参数类数据等。对于不同类型数据可采用不同的数据装卸载，转换和校验方式。

（3）数据库对象迁移分析。Oracle的触发器（Trigger）和表空间（Table space）目标库并不支持，需要考虑其他的实现方式。Oracle中的存储过程，需要转换到Greepplum中的函数（Function）等。另外两种数据仓库的分区（Partition）实现方式也不同，在进行物理模型迁移时应重点考虑。Oracle没有数据分布（Distribution）策略，要分析现有模型和应用，改写建表语句增加分布键。

（4）数据表字段类型分析。对原系统的数据库字典进行整理，明确源数据结构的定义和类型，并映射出目标数据的定义和类型，在物理模型方面要注意Oracle特有的内容，将其迁移到Greenplum时要注意修改。不同数据库特有的SQL（structured query language）语法，找到Greenplum数据库中相对应的语法。

（5）运行参数分析。运行参数的定义为广义上的参数，包含数据表形式参数、文件形式参数、程序中的常量定义，参数可能以各种形式存在于系统中，对这些参数都要进行基于目标库的重新配置和校验。在这个过程中还需要对数据转换逻辑与加工规则进行单元测试，集成测试，以追溯验证。

通过对所迁移的数据仓库的深入理解，大胆对软件开发生命周期模型的流程进行客户化定制，最终确定采用经过裁减的瀑布型生命周期方法进行数据迁移模块的开发。裁减后的数据迁移开发生命周期模型包括迁移需求分析、详细设计、移植代码编写、数据仓库对象改造迁移、存量数据迁移、增量数据加载、单元测试、集成测试、项目上线发布等阶段。

2、迁移总体架构

该保险集团有产险、寿险，财务，投资，主数据管理（MDM，Master Data Management）等源系统需要做在异构数据库平台间做数据仓库的迁移。总体架构设计如图1所示。其中产险和寿险是由源系统直接提供增量数据文件，传输到数据文件服务器指定目录下；而财务和投资还需要到源业务系统去抽取数据。原子层数据抽取-转换-加载程序由Datastage job和Greenplum数据仓库中的程序实现。底层数据迁移完毕后，基于数据仓库底层数据的通用语义层和集市层迁移工作可以有序展开。通用语义层和集市层迁移的重点在于将对大量的计算逻辑进行改造，使其在目标库MPP架构上运行计算逻辑，产生各类指标型报表和业务型报表。

企业级数据仓库迁移技术图1.jpg