在数据仓库应用方面，比较显著的问题存在于其易用性和易操作性方面；其次是用户对于标准化和开放性要求；再次是系统的可扩展性和性价比。本文立足于数据仓库在电信金融行业经营分析系统中的应用，首先分析了
Teradata 数据仓库的局限性，进而提出了 IBM DB2 数据仓库解决方案的独特优势。基于实际案例，本文给出了经过实践证明有效的迁移计划和迁移步骤。随后，详细描述了如何使用
IBM 中国 Avalanche 团队开发的 DDLMapping 工具将 Teradata 数据库对象自动化迁移到
DB2 数据库中，并且给出了 DDL 语句映射表，以方便读者使用。
引言
数据仓库是面向数据分析应用的数据库。在国内的电信和金融行业中，数据仓库的应用经过近十年的发展，已经具有相当的规模。其中，经营分析系统是以数据仓库技术为基础，综合运用联机分析处理、数据挖掘和统计学等多种技术，为企业经营管理、市场营销、业务运营提供分析决策支持的系统。由于中国的实际情况，目前经营分析系统所要处理的数据量已达到海量。为了解决海量数据的存储，数据仓库普通采用了分级式，即省级数据仓库——地市数据集市多层体系，如图
1 所示，经营分析系统发展逐渐成为企业的信息集成平台。
图 1. 省级—地市数据集市分级式体系
Teradata 数据仓库的局限性
Teradata 数据仓库和 DB2 数据仓库（DWE）一样，都使用了非共享（Share Nothing）的体系结构（见表
1：共享方式和非共享方式的比较），都可以用来搭建高性能的数据仓库，而且已经在电信、金融行业中得到了验证，是最适合于经营分析系统的架构。但与
DWE 相比，Teradata 数据仓库具有下述的局限性：
1. 从硬件平台来看。Teradata 是内部封闭的系统环境，不能使用开放式平台。
2. 从技术实现来看。Teradata 采用封闭的 Bynet 技术，限制了 MPP 节点之间的通讯带宽。另外，Teradata
在技术上还有很多“特别”之处，如：必须向空表中装载数据，否则效率很低；表的查询会有表级锁，为了提供并发性，每个表都被建立了视图等等。
3. 从商业角度来看。Teradata 数据仓库产品在全世界的安装数目（Install Base）少于
IBM DB2 数据仓库。Teradata 的平台和技术是封闭的，这导致报价高昂。就目前全国的各省市装机来看，采用
Teradata 的省份，他们的投资都远远大于采用 DB2 的省份。
4. 近年来，Teradata 推出的新的硬件平台与以往的平台互不兼容。很多客户甚至被逼迫采购旧型号的设备以满足整体系统的兼容性。
表 1. 非共享方式和共享方式的比较
IBM DB2 数据仓库解决方案的优势
1. IBM 数据仓库提供了一套完整的、平衡的、专业的数据仓库配置方案。IBM DWE 通过消除系统瓶颈，在各项性能之间达到平衡和优化，从而提供了一个平衡和优化的系统。一般的，在计算机系统中都会有瓶颈存在。比如一个服务器可以驱动峰值为
28800IOs/sec 的存储系统，然而配置的存储子系统只能达到 14440IOs/sec。 那么服务器处理
I/O 要求高的负荷时，最多将有 50% 的时间处于 IO 等待。
图 2. 系统性能的平衡和优化
BCU（Balanced Configuration Concept），是指把处理器、内存、存储和 DB2
数据库的 Partition（分区）、配置参数等合在一起，作为一个可扩展的基本建设单元。通过多个 BCU
复制生成大型系统。BCU 成功的关键，是把合适比例的 HW/SW 组织到一起。
图 3. BCU 把合适比例的 HW/SW
组织到一起
2. DB2 数据仓库提供了基于 MPP 的高并行性、可扩展性和良好的伸缩性。
DB2 数据仓库并行性支持节点内并行（SMP）和节点间并行（MPP）。
DB2 数据仓库的分区特性支持多层次：数据库级（DPF）、表级（Table Partition）和 MDC。数据库由多个数据库分区构成，每个数据库分区可运行在不同的节点上，每个数据库分区拥有独立的资源，SQL
任务在所有分区上并行处理。分区数据库对用户和应用而言是透明的。 如图 4 所示，DB2 数据仓库提供了水平（Scale
Out）和垂直（Scale Up）两种收缩方式。
数据分区不发生变化，在单个服务器内增加 CPU，内存，存储，无需重分布数据。
数据分区不发生变化，增加服务器节点，无需重新分布数据，数据仓库管理系统需要重新启动。
数据节点发生变化，增加服务器节点，需要重新分布数据。支持在线的数据重新分布，仅正在重分布的那张表不可以读写，其他表都可以读写，支持中断重分布操作后，继续重分布操作。
图 4. 垂直水平两种伸缩方式
3. DB2 数据仓库基于开放平台，具有高性价比的突出优势。
IBM DB2 支持广泛的硬件厂商和操作系统，为用户提供了丰富的选择。DB2 支持的操作系统有 AIX、HP-UX、Linux、Solaris、Windows
等；DB2 支持主流硬件厂商设备，包括主机和存储，开放的存储系统，可以采用 IBM，HP，EMC 等的存储系统；对于升级后退下来的硬件，客户仍然可以考虑其它用途。
强大的数据压缩技术。大大降低对存储的要求，压缩率超过 60%；不降低甚至提升系统的查询性能。如图 5 所示，初始大小为
179.9GB 的数据被压缩到了 42.5G。
图 5. 32K 页面的压缩比
迁移方案
迁移方案选择
从 Teradata 向 DB2 数据仓库迁移，首先需要确定迁移方案。针对具体情况，可以从下述三种方案中选择其一。
1. 自上而下：从数据集市开始迁移，属于数据集市的表迁移到 DB2 中，然后逐层向下，扩展至整个数据仓库。
优点：通常符合项目的立项目标和要求；确定属于某个数据集市的表可以完整地迁移到 DB2 中，空间缩减是逐步的、持续的；在整个过程中可以梳理各个数据集市的元数据。
缺点：这个过程对 Teradata 数据量的减少较为缓慢；在迁移改造的过程中需要考虑现有 Teradata
系统扩容压力的问题。
2. 自下而上：从数据的采集，ETL 层面开始迁移，随后把整个数据仓库层面改造到 DB2 系统中，最后再迁移数据集市。
优点：首先解决 ETL 迁移的问题，效率较高。
缺点：并不能最大限度地缩减 Teradata 系统的空间，只有在整个系统都迁移完成的时候，才能够一下子缩减
Teradata 的空间，所以整个迁移过程中压力较大。
3. 自部分到整体：把一部分数据（例如，某些地区）的全部流程（从 ETL 到数据集市）迁移到 DB2 中，然后逐步扩大规模，最后到整个数据仓库。
优点：这个方案涉及了两套数据库表和 ETL 系统的维护，而且很多分析的应用需要访问全范围的数据。这个方案在空间缩减方面比较直接。
缺点：实施风险很大；在逻辑上的交叉访问不容易实现。
软硬件方案选择
针对业务需求，完成主机、操作系统以及存储选型。安装好网络、备份磁带库，完成存储规划。最后安装好 DB2
数据仓库并划分好表空间。例如在某电信运营商的数据仓库向 DB2 迁移中，选用了图 6 所示的软硬件架构。
图 6. 硬件架构逻辑示意图
迁移步骤
如图 8 所示，从逻辑上整个迁移步骤划分为 5 个阶段。
1. 数据库对象迁移
据库对象的迁移，主要包括表，视图，索引等的迁移工作。
2. ETL 工具和 Perl 脚本迁移
在 Teradata 中，ETL 过程是 Perl 脚本中嵌入 Teradata SQL 的程序处理模式。调度工具使用
Teradata Automation 服务器启动任务（Job）来调度 Perl 脚本。就工具的迁移而言，可以根据具体需要，选择下面的方式。
方式一，继续沿用 Teradata Automation 工具，工作重点是迁移大量的 Per l 脚本。
方式二，放弃 Teradata Automation 工具，使用 IBM DataStage 或 SQW，工作重点是编写新的
ETL 脚本来实现业务逻辑。
3. 数据迁移
如图 7 所示，首先使用 FastExport 工具将 Teradata 数据仓库中的数据导出为文本，然后再用
DB2 Load 加载文本到 DB2 数据仓库中。最基本的加载方式有全量加载和增量加载。
图 7. 从 Teradata 加载数据到
DB2 数据仓库中
4. 数据集市迁移
数据集市的迁移，其实质是将集市应用中的 Teradata 的标准扩展 SQL 转化成 DB2 SQL，同时还要处理
Teradata 中的存储过程、触发器和用户自定义函数等。典型的数据集市应用包括查询、分析、报表以及数据挖掘等。
5. 测试和性能优化
设计测试用例，对数据验证，完成对应用的功能测试。最后在产品环境中进行性能测试，并和软硬件的测试基准进行对比。如果需要，则对数据仓库系统进行性能优化。
图 8. 五阶段迁移步骤
值得强调的是，上述 5 个阶段只是逻辑上的步骤。实际上数据仓库的迁移是由各个任务组成的，相互可以并行、依赖的整体甘特图。例如，我们经常在实践中，采取中间划线，上下对进的策略，来加快实施。另外第三阶段的数据迁移，通常分初次装载和日常连续装载两个部分。日常连续装载是以后每天要做的事情，初次装载情况各异，还可能不做。
数据库对象迁移
不同于通常的 DDL 脚本转换，我们对数据库对象迁移采取了从目标 Teradata 数据仓库直接获取的方式，以满足和生产系统状态完全同步以及迁移便捷性的需要。另外，我们在迁移中发现，客户的数据仓库中总是会有一些由于历史原因不再使用的数据库对象例如表、索引等，或者会有一些当前阶段暂不需要迁移的数据库对象，所以我们会在文件中记录下需要获取的数据库对象列表，来做有针对性的迁移。
当然，在迁移数据库对象的同时，读者可能会想也可以考虑迁移数据，同步进行。但实际项目中，我们发现很难做到。因为数据仓库的数据量通常都非常大，如果迁数据需要很多时间，特别是一旦出现问题，会影响后续工作的开展。所以通常都是先迁移数据库对象，这时候一些上层应用就可以来测试了，随后再迁移大量数据。
就数据库对象迁移的技术细节来看，Teradata 的 SQL 语法标准和 DB2 大部分是一致的，例如表、索引、触发器、约束等。但也有少数部分有所区别，例如在
Teradata 的建表语句中的 TITLE 字段描述 , 需要转换为 DB2 的 COMMENT 描述；Teradata
数据表的分片，需要用 DB2 的 DPF、表分区来做相应实现。最后，由于 Teradata 的视图无法从其目录字典中取出，所以在映射时不得不对建视图语句进行字符串级别的解析。解析的正确性依赖于对
Teradata 视图语句文法规则的理解。目前解析能转换 90% 以上常见的情况，还有少部分需要做额外的手工处理。
上述是数据库对象迁移的总体策略，我们最终使用 DDLMapping 这个工具完美实现了想法。DDLMapping
工具是 IBM 中国 Avalanche 团队开发的，用于从 Teradata 数据库对象向 DB2 迁移，并且已经用在了具体的电信项目实践中，取得了非常好的迁移成果。与业界同类工具相比，这个工具具有转换速度快、准确度高的突出优点。这个工具的所有权最终归
IBM 中国软件开发实验室所有。
接下来，我们使用 DDLMapping 工具将 Teradata 的表、视图、索引以及 Title 等有关的
DDL 语句映射成 DB2 数据库相应的 DDL 语句。DDLMapping 工具基于 Perl 实现，读者可以从后文给出的链接中下载。
下面说明 DDLMapping 工具的用法：
在客户机上安装 Teradata 客户端，并配置 Teradata ODBC 数据源。如图 9 所示。
图 9. 配置 Teradata ODBC
数据源
在客户机上安装 Perl 运行时和 Teradata 数据库访问环境。
运行 DMLMapping.pl，生成适合 DB2 的 DDL 脚本文件，如列表 1 所示。
列表 1. 运行 DDLMaping 工具
DDLMapping <odbc_name> <uid>,<pwd> <dbname> <schema> <tablespace_for_table> <tablespace_for_index> {tablelist} |
如表 2 所示，DDLMapping 工具的参数说明如下：
表 2. DDLMapping 工具的参数说明
映射后，检查 <dbname>.MSG 文件在映射过程中是否有错误。如图 10 所示，DDLMapping
工具的输出结果如下：
与 Table 相关的 DDL 存储到 <dbname>.SQL (CREATE TABLE,
COMMENT)
与 View 相关的 DDL 存储到 <dbname>.SQV (CREATE VIEW)
与 INDEX 相关的 DDL 存储到 <dbname>.IDX （PRIMARY KEY，
INDEX）
图 10. DDLMapping 的输出结果
DB2 数据库对象的生成
可在 db2 中执行如下语句，生成表，视图，索引，检查 .out 文件中是否有错误信息。
db2 -tvf <dbname>.SQL > sql.out
db2 -tvf <dbname>.SQV > sqv.out
db2 -tvf <dbname>.IDX > idx.out
DDL 语句映射表
如表 3 所示，Teradata 和 DB2 DDL 语句映射表示例，DDLMapping 工具自动化了映射过程，从而实现了数据库对象的自动化迁移。另外，DB2
除了和 Teradata 一样都支持数据库分区外，还支持表分区。关于数据表的分片，参考表 3。
表 3. Teradata 和 DB2 DDL 语句映射表示例
迁移最佳实践
制定迁移计划之前，首先要做好迁移评估。这包括收集 Teradata 的系统现状，例如用户量，数据量，表个数，脚本个数，I/O
吞吐量，是否存在性能瓶颈等。
要有回退机制。如果迁移过程中或者迁移后，数据库出现了问题，要有机制能恢复到原有状态。
关于数据集市的迁移。把所有存放在 Teradata 中的数据集市进行优先级排序，制定迁移计划。
关于元数据管理。在数据集市迁移中，对于在 DB2 系统中建立的所有数据，建立并维护一个较为完备的元数据管理体系。这个元数据管理体系就是
Teradata 数据仓库迁移到 DB2 数据仓库所拥有的元数据管理体系。
关于 Teradata 中的视图。由于查询操作时，Teradata 默认对数据表加表级的读锁，这导致性能和并发性下降，这种问题在
DB2 中不存在，在 DB2 中不需要在此类应用建立相应的视图。
关键应用的逻辑验证。在迁移的初期，采可以用 Federation Server 连接 Teradata，配置
Teradata 的 Wrapper，来对关键应用进行验证，以降低迁移风险。
关于海量数据迁移。例如话单数据，就尽量提前来做，不能成为整个迁移的关键路径。
关于 Teradata Automation 自动化调度工具。通常在 Teradata Automation
中，有数以万计的任务被调度。即便我们完成了每个任务的 Perl 脚本和 Teradata SQL 的迁移，但是，将
Teradata Automation 中的设置搬到 IBM DataStage 或者 SQW 中需要巨大的工作量。这需要在前期方案中，确定好
ETL 调度化工具，并制定与工作量相适应的迁移计划。
关于性能调整和优化，需要分阶段来做。软硬件安装完毕后，做一次性能测试，结果和基准数据做比较。迁移完毕后，在系统忙时对生产环境中的
DB2 数据仓库做第二次性能测试，结果和 Teradata 旧系统的数据做比较，来确认性能提升情况。
结束语
本文是《从 Teradata 迁移到 IBM DB2 数据仓库》系列中的第一篇，其中所提出的方案、计划和实施步骤已被实践证明是行之有效的，对读者具有极强的参考意义。另外，读者从本文学习到如何将数据库对象从
Teradata 迁移到 DB2 数据仓库之后，就可以学习该系列中的下一篇了。
|
