设计并实现数据仓库ETL过程(IBM讲座)

本文是关于计划、设计和实现基本数据仓库解决方案的系列文章的第 3 部分，将设计和实现仓库 ETL 过程，并了解仓库的性能和安全问题。

请多多支持作者作品RKWeb1.1 asp.net开发模板！
有效提高asp.net开发效率60%以上的代码框架！
类似java的struts+spring+hirbenate

下载地址：www.hositech.com

简介

数据集成是数据仓库中的关键概念。ETL（数据的提取、转换和加载）过程的设计和实现是数据仓库解决方案中极其重要的一部分。ETL 过程用于从多个源提取业务数据，清理数据，然后集成这些数据，并将它们装入数据仓库数据库中，为数据分析做好准备。

ETL 过程设计

尽管实际的 ETL 设计和实现在很大程度上取决于为数据仓库项目选择的 ETL 工具，但是高级的系统化 ETL 设计将有助于构建高效灵活的 ETL 过程。

在深入研究数据仓库 ETL 过程的设计之前，请记住 ETL 的经验法则：“ETL 过程不应修改数据，而应该优化数据。”如果您发现需要对业务数据进行修改，但不确定这些修改是否会更改数据本身的含义，那么请在开始 ETL 过程之前咨询您的客户。

调制的 ETL 过程设计

由于其过程化特性以及进行数百或数千个操作的可能性，所以以精确方式设计 ETL 过程，从而使它们变得高效、可伸缩并且可维护就极为重要。ETL 数据转换操作大致可以分为 6 个组或模块：数据的提取、验证、清理、集成、聚集和装入。要安排好这些组，按照使这一过程获得最大简化、具有最佳性能和易于修改的逻辑次序来执行操作。下图中展示了执行的次序。

图 1. ETL 数据转换过程的功能模块设计
 

在项目的业务需求和数据分析阶段，我们创建了数据映射信息。有许多中记录数据映射的方式；ETL 数据映射表是指导 ETL 过程设计的最佳方式。您还可以将该表用作与业务客户就数据映射和 ETL 过程问题进行交流的方式。ETL 数据映射表有不同的级别，如实体级别和属性级别。每个级别中都具有不同级别的详细数据映射信息。下表是一个实体级别的 ETL 数据映射表的简化例子。该表中的每个“X”表示到操作细节或较低级数据映射文档的链接。

表 1. ETL 实体映射表

源	验证	清理	转换	集成	聚集	目标
账户客户	X	X	?	X	X	客户
信贷客户	X	X	X
借贷客户	X	?	X
支票账户	X	X	?	X	X	账户
储蓄账户	X	?	X
信贷账户	X	?	X
借贷账户	X	X	?

在 DB2 数据仓库中实现 ETL 过程

DB2® Universal Database™ Data Warehouse Editions 为数据仓库功能提供了改进的性能和可用性。DB2 Data Warehouse Center（DWC）是一个可视化的 ETL 设计和实现工具，它是 DB2 UDB 中的组成部分。这一节将查看如何使用 DB2 UDB（Version 8.2.1）Data Warehouse Center 设计和实现仓库 ETL 过程。

创建仓库控制数据库

仓库控制数据库包含存储数据仓库中心（Data Warehouse Center）元数据所必需的控制表。在 Data Warehouse Center 的 Version 8.2 或更新的版本中，仓库控制数据库必须是 UTF-8（Unicode Transformation Format 或 Unicode）的数据库。这一需求为 Data Warehouse Center 提供了扩展的语言支持。如果尝试使用非 Unicode 格式的数据库登录 Data Warehouse Center，那么您会收到无法登录的错误消息。您可以使用 Warehouse Control Database Management 工具，将元数据从指定的数据库迁移到新的 Unicode 数据库中。

下面是创建和启动新的仓库控制数据库的步骤：

1. 确保启动了 DB2 仓库（Warehouse）服务器和相关的服务。在仓库控制数据库的管理窗口中，填入控制数据库名、模式名（IWH）、用户 ID 和密码，并创建该仓库控制数据库。如果在以前版本的 DB2 DWE 上已经有一个仓库，那么还可以使用此过程将仓库控制数据库迁移到当前版本中。
2. 通过新创建的或迁移的控制数据库登录到 DB2 Data Warehouse Center，如 图 2 所示。确保使用与步骤 1 相同的用户 ID 和密码。如果仓库控制数据库是一个远程数据库，则必须对该节点和控制数据库进行编目。

 

图 2. 登录 DB2 DWE 仓库中心
 

注意：DB2 Data Warehouse Center 的登录窗口将允许您在多个仓库控制数据库中进行切换。当有许多项目或开发人员在同一 DB2 数据仓库（Data Warehouse）服务器上工作时，此功能极其有用。

定义代理站点

仓库代理（agent）管理数据源和目标仓库之间的数据流。仓库代理可用于 AIX®、Linux、iSeries™、z/OS™、Windows® NT、Windows 2000 和 Windows XP 操作系统，以及 Solaris™ 操作环境（Operating Environment）。

这些代理使用 Open Database Connectivity（ODBC）驱动程序或 DB2 CLI 与不同的数据库进行通信。只需要几个代理就可以处理源仓库和目标仓库之间的数据迁移。您所使用的代理数目取决于现有的连接配置，以及计划迁移到仓库中的数据量。如果需要同一代理的多个进程同时运行，则可以生成附加的代理实例。

代理站点是安装了代理软件的工作站的逻辑名称。代理站点的名称与 TCP/IP 主机名不同。一个工作站可以只有一个 TCP/IP 主机名。不过，您可以在一个工作站上定义多个代理站点。逻辑名称将标识每个代理站点。

在设置数据仓库时，必须定义仓库将用来访问源数据库和目标数据库的代理站点。Data Warehouse Center 使用本地代理作为所有 Data Warehouse Center 活动的默认代理。但是，您可能需要使用来自包含仓库服务器的工作站的另一站点上的仓库代理。您必须在 Data Warehouse Center 中定义该代理站点，从而标识安装了该代理的工作站。Data Warehouse Center 使用这一定义来标识启动代理的工作站。

图 3. DB2 仓库代理
 

上图说明了仓库代理、数据源、目标和仓库服务器之间的关系。

定义仓库源

仓库源指定将为仓库提供数据的表和文件。Data Warehouse Center 使用仓库源中的说明来访问数据。DB2 Data Warehouse Center 支持所有主要平台上的大量关系数据源和非关系数据源，如下图所示。

图 4. 仓库数据源
 

这使得配置从 DB2 Data Warehouse Center 到所支持数据源的连接变得极其容易。

在建立到数据源的连接并确定需要使用哪些源表之后，就可以在 Data Warehouse Center 中定义 DB2 仓库数据源了。如果使用相对仓库代理的远程源数据库，就必须在包含仓库代理的工作站上注册这些数据库。

定义仓库数据源的过程会根据数据源类型的不同而有所不同。下面是一个在 DB2 Data Warehouse Center 中定义关系仓库数据源的例子。

为了在 Data Warehouse Center 中定义关系数据源，要执行以下操作：

1. 在 Data Warehouse Center 中打开 Define Warehouse Source 记事本。
2. 添加有关仓库源的信息。
3. 指定访问仓库源的代理站点。
4. 指定有关源数据库的信息，如下图 5 所示。
5. 将源表和视图导入仓库源中。
6. 授权仓库组，以访问仓库源。

 

图 5. 定义仓库关系数据源
 

定义仓库目标

仓库目标是指包含已转换数据的数据库表或文件。您可以使用仓库目标给其他仓库目标提供数据。例如，一个中心仓库可以向部门级服务器上的数据集市提供数据。有两种创建仓库目标的方法。一种是从现有的表或文件进行导入，另一种则是通过使用仓库系统生成目标。

图 6. 定义仓库目标表
 

正如从 图 6 中可以看到的，在定义 DB2 仓库目标表时，可以指定是否由 DB2 Data Warehouse Center 创建该表，以及该表是否是 OLAP 模式中的一部分，这意味着它可能最终被用作多诸如星型模型之类的维数据模型中的一个维度或事实表。

定义仓库主题领域、过程和步骤

仓库步骤是对仓库中单独某一操作的定义。仓库步骤定义如何移动和转换数据。可以在 DB2 Data Warehouse Center 中使用的仓库步骤类型有很多：

• SQL（插入、更新和替换）
• 文件（FTP，文件数据的导入和导出）
• DB2 程序（数据导出、装入、表重组和统计数据更新）
• 仓库转换器（数据清理、键表和时间表的生成，以及翻转和透视数据）
• 统计信息转换器

 

在运行一个步骤时，可能发生仓库源和仓库目标之间的数据迁移或转换。其中一个步骤就是 Data Warehouse Center 中的一个逻辑实体，该实体定义了以下内容：

• 到源数据的链接。
• 对输出表或文件的定义和链接。
• 用来填充输出表或文件机制（SQL 语句或程序）和定义。
• 填充输出表或文件的处理选项或时间表。

 

仓库过程包含为特定仓库执行数据转换和移动的一系列步骤。一个过程可以产生一个表或一组总结表（summary table）。过程还可以执行一些特定类型的数据转换。

图 7. 定义仓库过程
 

主题区域指定并划分与逻辑业务领域相关的过程。例如，如果构建一个营销和销售数据的仓库，那么要定义一个销售（Sales）主题领域和一个营销（Marketing）主题领域。

仓库过程和步骤模式

Data Warehouse Center 通过使用三种模式（开发、测试或生产）中的一种来划分步骤，从而允许您管理步骤的开发。该模式将确定您是否可以修改步骤，以及 Data Warehouse Center 是否将根据其时间表运行步骤。升级步骤表示将该步骤移至更高的模式（开发 -> 测试 -> 生产）。

• 开发模式：在创建一个步骤之后，您就已经处在开发模式中。您可以在该模式中修改任何步骤属性。在此模式下，仓库为这一步骤所生成的目标表并不在目标仓库中。如果需要运行这一步骤来执行测试，则必须将该步骤升级到测试模式。
• 测试模式：在步骤属性中，可以指定使用 Data Warehouse Center 为该步骤创建目标表。当您将这一步骤升级到测试模式时，Data Warehouse Center 就会创建目标表。因此，当您将一个步骤升级到测试模式之后，就只能进行那些不会损坏目标表的修改。例如，当一个目标表的相关步骤处于测试模式时，就可以向该目标表添加列，但无法从目标表中删除列。在测试模式下，可以单独运行每个步骤。Data Warehouse Center 不会根据其自动时间表来运行步骤。
• 生产模式：为了激活时间表和任务流链接，必须将步骤升级到生产模式。生产模式表明步骤已经处于最终格式。在生产模式下，只能修改不影响该步骤所生成的数据的设置。您可以修改时间表、处理选项（除了填充类型）或关于该步骤的描述性数据。但您不能修改该步骤的参数。

可以在 Data Warehouse Center 中，或者通过外部触发器程序在 DB2 Warehouse Center 外部对仓库步骤进行升级和降级，并手工运行它。

 

DB2 仓库外部触发器程序

外部触发器程序是调用 Data Warehouse Center 的仓库程序。外部触发器服务器脚本可以用于升级或降级 DB2 仓库步骤，以及启动或运行过程和步骤。在 ETL 开发和测试中，外部触发器程序对于批量升级和降级仓库过程和步骤特别有用。您还可以使用该脚本来管理 ETL 过程和步骤的执行次序。

外部触发器程序包含两个组件：外部触发器服务器（XTServer）和外部触发器客户机（XTClient）。XTServer 与仓库服务器安装在一起。XTClient 与仓库代理安装在一起，用于所有的代理类型。在从外部触发器程序触发一个步骤之前，必须在该步骤的 Properties 记事本的 Processing Options 页面上指定 Run on demand 选项。

下面是 Windows 平台上用于升级 ETL 步骤的外部触发器脚本实例：

1. 请确保 db2XTrigger.jar 和 common.jar 位于类路径中：
   CLASSPATH=%CLASSPATH%;%DB2PATH%/tools/db2XTrigger.jar;%DB2PATH%/java/common.jar
2. 从命令窗口启动外部触发器服务器：

   "%DB2PATH%/java/jdk/bin/java" db2_vw_xt.XTServer <<em>port_number</em>>

   
   其中，<port_number> 是仓库服务器上外部触发器的服务端口号。默认端口号是 11004。
3. 创建并运行客户端的脚本命令文件，该文件可能包含多行代码。例如（在执行该文件时，在一行中包含了所有的参数）：

   "%DB2PATH%/java/jdk/bin/java" db2_vw_xt.XTClient <em><server> <port> <DWC_user> <password> <ETL_step> <command> <wait_for_result></em>

   
   其中：
   • <server> 是仓库服务器。
   • <port> 是仓库服务器上的外部触发器服务端口号。默认端口号是 11004。
   • <ETL_step> 是您试图升级的 ETL 步骤或过程的名称。
   • <DWC_user> 是 Data Warehouse Center 的用户 ID。
   • <command> 可以具有下列值之一：
     1. populate/run a step
     2. promote a step to test mode
     3. promote a step to production mode
     4. demote a step to test mode
     5. demote a step to development mode
     6. populate/run a process
     7. verify that the Data Warehouse Center server is running
   • <wait_for_result> 是可选的。该参数表明外部触发器程序是否要返回步骤或过程的处理结果。请选择下列值之一：
     • 1：等待步骤或过程完成。如果该步骤或过程成功完成了，则返回 0，或者如果该步骤或过程失败，则返回一个错误。
     • 0 或空白：不等待步骤或过程完成。

数据提取

数据提取是捕获源数据的过程。有两种捕获数据的主要方法：

• 完全刷新
• 增量更新

 

完全刷新，顾名思义，只是对移入中间（staging）数据库的数据进行完全复制。该复制可能替换数据仓库中的内容，及时在新的时间点上添加完整的新副本，或者与目标数据进行比较，以便在目标中生成一条修改记录。增量更新的关注重点是只捕获源数据中修改的数据。

如何捕获数据修改与数据源本身是密切相关的；它实际上是逐个（case-by-case）实现的问题。DB2 Data Warehouse Center 支持许多数据捕获方法，其中包括直接用 SQL 选择来捕获所有数据或数据子集，用 FTP 来捕获源数据源中的数据，数据文件的直接导入或装入，以及数据复制。

提取大量数据

从仓库数据源提取大量数据是所有数据仓库项目中的一个重要问题。在 DB2 Warehouse Center 中，您可以采用许多方法：Select and Insert SQL 步骤或仓库负载实用程序。

• Select and Insert SQL

  增量提交是一个允许您控制 Data Warehouse Center 所管理数据的提交范围的选项。增量提交可用于 Select and Insert SQL 步骤中。在代理要移动的数据量十分大，以致于在整个步骤的工作完成之前 DB2 日志文件就可能已经填满时，或者在需要保存部分数据时，可以使用增量提交。如果所移动的数据量超出了已经分配的 DB2 最大日志文件，SQL 步骤将以失败结束。数据库的性能可能会受到损害，因为在使用增量提交时，可能出现相当多的提交。在执行提交之前，要使用增量提交选项来指定将要处理的行数（大致为最接近的因数 16）。代理将选择并插入数据，然后进行增量提交，直到成功完成数据移动为止。

  
  
  图 8. DB2 Warehouse SQL 的 Select and Insert 步骤的选项
   
  

• 仓库负载实用程序

  DB2 Load 转换器可以将大量数据从定界的（delimited）文件装入 DB2 表，替换或追加数据库现有的数据。默认情况下，DB2 Load 仅在日志中记录进度消息，而不是真正地输入数据，因此，在这里不需要考虑日志文件的长度。在数据装入结束之后，表空间会处于暂挂（pending）状态；您需要备份该表空间，以使目标表可用。然而，DB2 Load 转换器为您提供了一个保存输入数据的副本的选项，如果使用该选项，则该表在数据装入之后就立即可用。

  您还可以指定要处理的最大行数，图 9 中展示了其他许多性能相关选项。

  
  
  图 9. DB2 Warehouse 负载实用程序的性能选项
   
  

仓库数据复制

DB2 Data Warehouse Center 的数据复制服务功能非常强大，并广泛用于为数据仓库中的完全刷新和增量更新捕获数据。

对于增量更新，数据修改是从日志文件和时间取样（time-sampled）源中捕获的。提取日志数据的典型方法就是数据复制。DB2 数据复制服务是与 DB2 Data Warehouse 紧密集成在一起的，因此数据复制可以从 DB2 Data Warehouse Center 中进行配置和调度。

您可以使用 DB2 Data Warehouse Center 来定义复制步骤，它将复制所有 DB2 Data Warehouse 支持的数据源之间的修改。您所需要的复制环境取决于需要进行更新的时间以及处理事务的方式。数据仓库（Data Warehouse）支持 5 种类型的复制：

• 用户副本（User Copy）：复制源表的完整压缩副本。压缩意味着目标表中包含一个主键，并且可用它来进行更新。
• 时间点（Point-in-time）：在某一个时刻上的复制源表的完整的压缩副本。目标表有一个主键和一个时间戳列。
• 基本聚集（Base aggregation）：历史表，为每个订阅周期追加新行，在复制源表（基表）上使用 SQL 列函数的计算结果。
• 更改聚集（Change aggregate）：历史表，为每个订阅周期追加新行，对包含了最近更改数据的复制源更改数据表使用 SQL 列函数的计算结果。
• 中间表（Staging table）：生成包含所提交事务中数据的目标表的表。也称作一致的更改数据表。

 

为了在 DB2 Data Warehouse Center 中设置复制，要执行以下步骤：

1. 为复制准备源数据库。
2. 创建复制控制表。
3. 在 DB2 Replication Center 中注册源表。
4. 将定义的复制源表导入 DB2 Data Warehouse Center 中。
5. 在 DB2 Data Warehouse Center 中定义复制步骤。
6. 创建仓库步骤所需要的密码文件。
7. 在源数据库的同一系统上启动 Capture 程序。
8. 在 DB2 Data Warehouse Center 中将复制步骤升级到测试模式或生产模式。
9. 运行该步骤。在运行该步骤时，仓库代理启动 Apply 程序来处理复制订阅。

 

为复制准备 DB2 源数据库

为了使 DB2 源数据库用于复制，必须将数据库配置参数 LOG_RETAIN 设置为 RECOVERY，以保留数据库日志文件。

1. 将源数据库配置参数 LOG_RETAIN 的值设置为 RECOVERY。该操作使数据库处于 BACKUP PENDING 状态。
2. 备份源数据库，以解除数据库的 BACKUP PENDING 状态。
3. 检查源数据库的配置参数 LOGPRIMARY、LOGFILSIZ 和 LOGSECOND。确保这些值足够大，能够处理数据修改。

 

创建 capture 和 apply 控制表

可以在 DB2 Data Warehouse Center 中设置复制之前，必须在仓库控制数据库和目标数据库中创建复制控制表。复制控制服务器上的用于捕获复制数据的控制表。目标数据库中的控制表用于应用复制数据。

下面是从 DB2 Replication Control Center 创建控制表的步骤：

1. 对于创建 capture 控制表：在 DB2 Replication Control Center 中，右击 Capture Control Servers 并选择Create Capture Control tables。在 Select a Server 窗口中选择仓库控制数据库。

   对于创建 apply 控制表：在 DB2 Replication Control Center 中，右击 Apply Control Servers 并选择Create Apply Control tables。在 Select a Server 窗口中选择仓库目标数据库。

2. 对于创建 capture 控制表：选择选项 Host sources for replication and capture changes to those sources。

   对于创建 apply 控制表：选择选项 Apply captured changes to target tables。

3. 输入合适的大小值。下表中的值是一个实例：

   问题	回答
   您将拥有多少源表？	少于 100
   对于一个源表，您通常拥有多少目标表？	1
   隔多久将数据应用到目标表？	每天
   您期望一天捕获多少事务？	1

4. 保留 ASN 的默认控制表模式，以及 TCASNCA 和 TCASNUOW 的默认表空间。选择 Run Now 来创建复制控制表。

 

为进行复制而注册源表

注册源表将告诉 DB2 需要捕获哪些表修改。在 DB2 Data Warehouse Center 中使用表或视图作为复制源之前，必须使用 DB2 Replication Center 将之定义为复制源。

1. 在 DB2 Replication Center 中，选择 SQL Replication > Capture Control Servers。选择源数据库，然后定位至 Capture Schemas。选择模式名（ASN）并定位至 Registered Tables。
2. 选择合适的源表，并保留这些表的默认设置。选择 Run now 注册用于复制的源表。

 

将源表导入 Data Warehouse Center

在 DB2 Data Warehouse Center 中，检查 Warehouse Sources 下面所列的数据库或表。如果没有列出复制源数据库或表，则将其作为仓库数据源进行导入或添加。

将目标表导入 Data Warehouse Center

在 DB2 Data Warehouse Center 中，检查 Warehouse Targets 下面所列的数据库或表。如果没有列出复制源数据库或表，则将其作为仓库目标导入。尽管这些表可能已经列出，但仍需要重新导入它们，让 DB2 DWC 知道已经为进行复制注册了这些表。

在 Data Warehouse Center 中定义复制步骤

定义复制步骤与定义其他仓库步骤十分相似。您可以在复制仓库步骤中定义 5 种类型的复制步骤：用户副本、时间点、基本聚集、更改聚集和中间表。（这些与 上面 所解释的步骤相同。）

默认情况下，设置复制步骤是为了生成目标表。如果需要将复制步骤链接到现有的目标表中，那么可以双击该目标表来打开 Properties 窗口。在第一个选项卡上，启用选项 Data Warehouse Center created this table。然后使用数据链接工具来将复制步骤连接到目标步骤上。在进行连接之后，返回到目标表的属性，然后取消选项 Data Warehouse Center created this table。

在使用现有的用户创建的目标表时，请特别小心，它与 DWC 生成的目标表相反。正如前面提到的，在将复制步骤降级到开发模式时，DWC 将删除 Apply 以及与这些步骤相关的订阅集。在升级步骤时，将重新创建它们，而且因为 Applies 在此时是新的，所以 Capture 程序将认为它需要向目标表提供完全刷新。如果已经在每个目标表上启用了 Data Warehouse Center created this table 选项，那么将在降级时删除这些表，并在升级时重新创建它们，（以及 Apply 程序、订阅集和表），这些表将为空，准备各自接收数据的完全刷新。但是，如果从不删除这些表，那么数据都会保留着，并且如果执行完全刷新，那么通过外键连接目标表时很可能会发生错误。在作为已填充的另一表的外键的目标表上，完全刷新的 Apply 部分将失败，因为不可以从父表删除它。

图 10 说明仓库 User Copy 复制步骤的属性，其中包括数据源和目标表之间的数据映射、复制订阅集名称、事件名、应用限定符（有关的细节，请参阅下一小节）和用户 ID/密码。

图 10. 定义仓库用户副本复制步骤
 

使用 asnpwd 实用程序创建密码文件

对于 Version 8 或更新版本的 Data Warehouse Center 中的复制，必须通过使用复制程序 asnpwd 来设置并维护复制密码文件。

复制密码文件是加密的。Data Warehouse Center 复制步骤假定用于复制步骤的密码文件是：

• 位于由环境变量 VWS_LOGGING 指定的目录中。
• 名为 <applyqual>.pwd，其中 <applyqual> 是 Data Warehouse Center 复制步骤的应用（Apply）限定符。

在启动 Apply 程序之前，Data Warehouse Center 代理从该文件向 Apply 程序命令添加用户 ID 和密码。

 

为了创建 pwd 文件，在第一次使用 asnpwd 时，需要打开 DB2 命令窗口。然后切换至 LOGGING 目录（例如，C:/Program Files/IBM/SQLLIB/LOGGING），运行以下命令：

asnpwd init encrypt password using applyqual.pwd

然后添加用户 ID 和密码：

asnpwd add alias db id <em><userID></em> password <em><password></em> using applyqual.pwd

除了对所有的应用限定符重复该命令之外，您可以只创建一次 pwd 文件，然后为每个应用限定符制作该文件副本，将其重新命名为 applyqual.pwd —— 假定复制步骤都使用相同的数据库、用户 ID 和密码。

启动 capture 程序

您可以从 DB2 Replication Center 启动复制 capture 控制服务器。启动 Capture 程序将启动对复制启用的源表进行的数据库日志记录修改，其中包括删除、插入和更新。请确保您所指定的日志记录目录有足够大的空间，可以处理修改数据量。

您还可以通过将 capture 程序保存到文件中并从命令行运行它，或者通过将 capture 程序保存为任务来启动它。

将复制步骤升级到测试或生产模式

在 DB2 Data Warehouse Center 中，将复制步骤升级到测试或生产级别。在升级步骤时，DB2 将创建订阅集和 Apply 程序，并在降级步骤时删除它们。

在 DB2 Replication Center 中，可以在数据库名下面发现新生成的 Subscription Sets 和 Apply Qualifiers。您可能需要刷新该视图。在订阅集的属性中，可以看到 DB2 Data Warehouse Center 已经为您将源映射到目标表列。

可以修改测试模式中复制步骤的属性，只要不将复制降级到开发模式，修改就会有效。下次将复制步骤降级到开发模式时，这些修改将会丢失。

DB2 复制错误记录

如果您有麻烦，则可以在日志记录目录（通常为 C:/Program Files/IBM/SQLLIB/LOGGING）中找到日志文件的默认位置。对于 capture 程序的错误，可以检查文件 DB2.<source db name>.<replication schema name>.CAP.log。（例如：DB2.DSACCT.ASN.CAP.log）

名为 <ApplyName>.trc 的文件通常为 Apply 相关的错误提供良好的错误处理信息。

文件 DB2.<target db name>.<Apply name>.APP.log 还包含一些与 Apply 相关的信息。（例如：DB2.STAGEDB.APPLYPROD.APP.log）

数据验证

在项目的业务数据分析阶段，您产生了一组数据质量假设。这些假设将指定客户和解决方案提供者双方在数据质量问题上的职责。解决方案提供者通常关心数据清理和增强问题。客户至少要关注仅仅可以在数据源本身中解决的问题，以及与解释数据含义相关的数据质量问题。例如：

• 丢失的数据恢复。
• 模糊的数据转换。
• 业务操作应用程序相关的数据问题 —— 只能从应用程序本身解决的数据质量问题。

 

您应该在项目合同文档中包含数据质量假设，因为如果没有用正确的方法及时解决业务数据的质量问题，它可能严重影响项目时间表。数据质量假设可能是与客户进行时间表协商的一个好基础。

即使假设客户将承担其责任，解决他们业务数据源中的数据质量问题，将来仍然可能在业务数据源中产生质量较差的数据。在那些数据对后面的 ETL 过程产生负面影响之前，实现数据验证 ETL 筛选器模块来拒绝它们就显得十分重要。数据验证包含许多检查，其中包括：

• 属性的有效值（域检查）。
• 属性在剩余行的环境中是有效的。
• 属性在该表或其他表中相关行的环境中是有效的。
• 关系在该表和其他表中的行间是有效的（外键检查）。

 

这并非是一个详尽的列表。它仅仅强调了数据验证的一些基本概念。

错误处理是一个确定如何处理不尽人意的（less-than-perfect）数据的过程。可以暂时拒绝这些数据，将数据存储起来以便在固定领域中对它们进行修正，或者将其缺点传递给数据仓库。所拒绝的数据将存储在客户可以访问的位置；请确保每次发生数据的拒绝时，都会通知您的客户。应该允许稍后将已修理的遭拒绝的业务数据移至数据仓库中。

DB2 Data Warehouse Center 中的 Clean Data 转换器可以用于基本的数据验证目的。您还可以构建自己的数据验证 SQL 步骤或特殊的数据验证步骤来进行复杂的数据验证。

数据清理

数据清理是清理有效数据，使之更精确更有意义的过程。数据清理包括下列等任务：

• 从数据源的数据合并。
• 域转换和同步。
• 数据类型和格式的转换。
• 用于不同目标表的数据分离（Data splitting）。

 

数据合并的一个常见例子就是姓名和地址信息。客户的姓名和地址信息通常存储在多个位置上。经过一段时间，这些信息可能就不同步了。为客户合并数据通常比较困难，因为用于匹配不同客户映像的数据不再匹配。数据增强将重新同步这些数据。

您可以使用 DB2 Warehouse Center 中的 Clean Data 转换器来执行源数据上的基本清理、替换和映射操作。Clean Data 转换器操作源表中步骤所访问的特定数据列。然后，转换器在您的步骤所写入的目标表中插入新的行。根据您所选择的处理选项，将无法清理的数据写入目标错误表中。在将数据作为过程中一部分进行装入或导入之后，您还可以使用 Clean Data 转换器来清理和标准化数据值。

Clean Data 转换器提供了下列可供指定的清理类型：

• Find and replace：在规则表的 Find 列中定位所选择的源列值，然后在目标表中用规则表中相应的替换值替换该值。规则表是这种清理类型所必需的。规则表指定 Clean Data 转换在查找和替换过程中将使用的值。
• Numeric™ clip：缩短超出了指定范围的数字输入值。范围内的输入值将不加修改的写入输出。范围之外的输入值将由下界替换值或上界替换值进行替换。规则表是这种清理类型所必需的。
• Discretize into ranges：基于规则表中的范围执行输入值的离散化（discretization）。规则表是这种清理类型所必需的。如果允许该清理类型为空（null），则必须在规则表的 Bound 列中放入 null 值。
• Carry over with null handling：指定输入表中要复制到输出表中的列。您可以从输入表中选择多个列移至输出表中。规则表不是这种清理类型所必需的。这种清理类型允许您用指定的值替换空（null）值。您还可以拒绝 null，并将所拒绝的行写入错误表中。
• Convert case：将源列中的字符从大写转换成小写，或从小写转换成大写，并将其插入目标列中。默认情况下，将源列中的字符转换成大写。规则表不是这种清理类型所必需的。
• Encode invalid values：用指定的值替换没有包含在您所使用的规则表的有效值列中的所有值。您要在 Clean Data 转换器的 Properties 记事本中指定替换值，并且必须指定与源列数据类型相同的替换值。例如，如果源列是数字类型的，则必须指定一个数字型的替换值。有效值在写入目标表时不会发生改变。规则表是这种清理类型所必需的。

 

大多数清理类型都有一个 Matching Options 窗口，用于指定希望用来处理匹配的方式。

数据集成

数据集成是将多个数据源联合成一个统一数据接口来进行数据分析的过程。数据集成是仓库数据转换过程中最重要的步骤，也是数据仓库设计中的关键概念。

数据集成可能极其复杂。在该模块中，可以应用数据集成业务规则以及数据转换逻辑和算法。集成过程的源数据可以来自两个或更多数据源；它通常包含不同的连接操作。源数据还可能来自单个数据源；该类型的数据集成通常包含域值的合并和转换。集成结果通常生成新的数据实体或属性，易于终端用户进行访问和理解。

数据聚集

数据聚集是收集并以总结形式表达信息的过程。数据聚集通常是数据仓库需求的一部分，它通常是以业务报表的形式出现的。

在多维模型中，数据聚集路径是维度表设计中的重要部分。在数据存储库或数据仓库中，数据聚集的级别是逐个（case-by-case）确定的。因为数据仓库几乎仍然都是关系数据模型类型的，所以最好是建议您的客户从数据集市构建业务报表。但是，某些客户喜欢直接从数据仓库构建报表。本例中，将考虑在仓库数据模型中进行数据聚集。请确保数据聚集表与其余的仓库数据模式相对分隔，因此，报表的业务需求修改将不影响基本的数据仓库数据结构。

将数据装入仓库目标表

将数据移至中心数据仓库中的目标表通常是 ETL 过程的最后步骤。装入数据的最佳方法取决于所执行操作的类型以及需要装入多少数据。您可以通过两种基本方法在数据库表中插入和修改数据：

• SQL insert/update/delete（IUD）
• 成批 load 实用程序

 

大多数应用程序使用 SQL IUD 操作，因为它们进行了日志记录并且是可恢复的。但是，成批加载操作易于使用，并且在装入大量数据时速度极快。使用哪种数据装入方法取决于业务环境；应在 ETL 设计文档中指定装入方法。

ETL 数据拒绝的处理

如何处理拒绝的业务数据是 ETL 设计中的重要问题。当业务数据违背下列条件时将遭到拒绝：

• 业务数据质量假设。
• 数据参照完整性。
• ETL 过程中所实现的业务数据集成规则。

 

您应在数据仓库开发人员/管理员和终端用户都同意的地方存储遭拒绝的业务数据。被拒绝的业务数据中的问题的解决是数据仓库维护中的一部分；它通常是属于客户的职责。因为处理这类问题需要域知识和数据库技能，所以数据库管理员和终端用户都应该参与该工作。修复的业务数据最终将重新进入 ETL 周期，从而流入数据仓库。

ETL 过程和步骤的执行次序

执行次序是另一个重要的 ETL 设计问题。尽管从数据仓库服务器执行了越来越多的并行处理，但是并非所有的 ETL 过程都可以并发执行。有许多影响执行次序的因素：

• 实体依赖性：参照完整性的实施决定了表和对象的依赖性。例如，父实体表需要在子数据或关系表之前进行装入。
• 属性依赖性：属性依赖性通常意味着属性值是基于一个或多个属性的一个或多个值进行计算的。
• ETL 逻辑模块：ETL 模块设计次序通常决定了 ETL 过程中 ETL 步骤的执行次序。在数据集成步骤之前，需要验证并清理数据是很易于理解的。
• 数据集成依赖性：数据集成业务规则通常包含对象和数据依赖性。

 

在仓库过程中，执行次序是在设计阶段使用 图 7 所示的仓库链接工具进行定义的。您可以定义仓库过程中步骤之间的捷径，以控制过程的执行次序。

运行仓库 ETL 步骤

您可以随需应变地运行步骤，或者按照下列方法来安排将运行的步骤：

• 在指定的时间
• 只有一次
• 重复地，例如每个星期五
• 依次，在一个步骤结束时，下一个步骤才开始运行
• 在完成时，不管是成功还是失败，都将开始另一个步骤

 

如果您安排一个过程，该过程中的第一个步骤就会在安排的时运行。

图 11. DB2 Warehouse Work in Progress 窗口
 

您可以组合这些方法来运行一个过程中的步骤。您可以安排第一个步骤在指定的日期和时间运行。当该步骤处于生产模式时，这些时间表和级联（cascade）就是活动的。在安排好第一个步骤之后，您可以指定另一步骤在第一个步骤运行之后开始，并指定第三个步骤在第二个步骤运行之后开始，等等。

您可以安排过程和步骤，并指定一个过程在另一个过程运行之后开始。您必须小心地将步骤组合成有意义的过程，以便可以正确地调度和指定过程的任务流。通过 Scheduler 记事本的 Process Task Flow 页面，您可以基于一个过程的完成来启动另一个过程。

Work in Progress 窗口允许您监控 Data Warehouse Center 中所有运行或计划运行的步骤和过程的进度。Work in Progress 窗口为正在运行的步骤或过程显示了一个条目，其中包含 Populating 状态。如果处理失败，可以使用Show Log 动作找到问题所在。

管理 ETL 元数据

元数据管理对于 ETL 的有效开发和操作至关重要。ETL 元数据包括 ETL 过程设计、ETL 过程执行历史、被拒绝的数据过程记录、调度信息、数据增长和存储管理记录，以及用户数据访问记录中所涉及的所有东西。

您可以导出 Data Warehouse Center 中所存储的元数据，并且还可以从另一元数据源导入元数据。

导出元数据

您可以使用 Data Warehouse Center 导出功能来导出主题、过程、源、目标和用户定义的程序定义。在导出对象时，所有的隶属对象在默认情况下都将导出到标记语言文件或 XML 文件中。您可以导出下列类型的元数据：

• 标记语言（XML 格式）
• 公共仓库元模型（Common Warehouse Meta-model）元数据
• DB2 OLAP Integration Server 元数据（仅在 Windows 上）

 

默认情况下，导出包括所选择的对象和所有选择对象引用的对象。例如，如果您选择导出一个过程，那么就包括了步骤所使用的源和目标、隶属的步骤和隶属的过程。

在将元数据导出到标记语言时，您可以通过取消 Export dependent source properties 选项，在导出中排除源定义。如果这样做，则必须在导入该标记文件之前在目标系统中定义源，以避免错误。

您可以限制导出对象的数目，减小标记文件的大小。默认情况下，导出操作包含具有数据依赖性的步骤。例如，考虑下列场景：过程 P1 包含用于填充 T1 的步骤 S1，而过程 P2 包含步骤 S2，而 S2 包含作为源的 T1，因此可以建立下列依赖性：S1 –> T1 –> S2 –> T3。如果您仅导出过程 P2，那么 P1 也将导出到标记文件中，因为 S2 依赖于 S1 的数据。数据依赖性反向也成立。因此，即使您仅导出 P2，P1 也会包含在标记文件中。分开导出 P1 和 P2 不会有什么帮助，因此最佳方法就是将其一起导出。当将元数据导出到标记文件时，您可以启用选项 Do not export dependent steps from unselected process 来排除相依赖的步骤。

除了数据依赖性，您还必须考虑级联（cascading）。可以考虑过程 P5 中的一个步骤，它包含到过程 P6 中某一个步骤的捷径。如果导出 P5，那么 P6 也会被导出。本例中，导出通过捷径级联向下转到下一步骤。默认情况下，导出操作包括级联操作和过程，无论在导出到标记文件时是否提供一个机会，使之不包括级联步骤和过程。

图 12. 仓库元数据导出
 

导入元数据

您还可以导入对象定义，以便在 Data Warehouse Center 系统中使用。

在导入元数据时，所有对象都分配给标记语言文件中指定的安全分组。如果没有指定安全分组，那么所有对象都将分配给默认的安全分组。

您可以导入下列类型的元数据：

• 标记语言文件
• 公共仓库元模型（Common Warehouse Metamodel）元数据
• ERwin
• IBM MQSeries
• Trillium

 

提示：

• 如果您将标记语言文件从一个系统移至另一系统，则必须移动与之相关的所有文件（例如：源文件），它们必须位于在同一目录中。
• 如果导出具有未链接的捷径的过程，然后导入另一控制数据库作为 .tag 文件，那么未链接的捷径数据将导致错误 DWC3142：“<dirID> was not found in the Data Warehouse Center control database。”该错误显示在未链接的捷径 dirIDs 没有进行转换时，它们会回到初始的控制数据库。

 

导出和导入元数据的提示：

• 因为仓库的导入和导出格式取决于版本，所以无法使用来自前面版本的导出文件从一个版本的 Data Warehouse Center 迁移到另一个版本的 Data Warehouse Center。
• 导出和导入过程都使用大量系统资源。当您导出对象定义时，可能需要限制其他程序的使用。当您进行大型导出操作时，可能需要将仓库数据库的 DB2 应用程序堆数大小增加到 8192。
• 与仓库数据源、目标和代理相关的服务器名和用户名都要导出到标签文件中，而且在导入到新系统之后，需要对这些信息进行更新。不过，不用导出密码，因此您需要提供密码信息，以访问仓库数据源、目标和代理。

 

设置原型

一旦实现了数据仓库项目业务域领域的第一个分组，您就应设置仓库实现原型，以验证：

• 所使用的技术
• 设计和实现
• 项目业务需求
• 仓库性能

 

技术质量保证

当开始与用户一起验证设计时，实地体验（hands-on）测试是最好的方法。让用户尝试通过对测试目标的操作来回答问题。记录测试目标无法提供所需数据的所有领域。必须与终端用户一起执行建议解决方案的功能性验证。这通常导致终端用户暂时使用所构造的解决方案，让他们有机会使用本地解决方案中（可能是数据集市中）已经可用的信息。此外，本地解决方案然后可能集成到更大业务范围的数据仓库架构中，包括所生成的数据模型。

除了测试之外，要与用户一起检查在设计阶段产生的模型添加和修改，以确保它们是可以理解的。与模型的验证步骤一样，要将起作用的东西传递到实现阶段。将不起作用的返回给需求阶段，以便澄清和重新进入建模。

数据仓库的性能调优

数据仓库是系统、网络配置、应用程序、数据库、报表和人员的集合。数据仓库的性能受所有这些因素的影响。这一节将关注如何从终端用户的角度寻找数据仓库的性能问题，该意味着从查询工作负载和响应时间的角度查看问题。

数据仓库上的工作负载很少保持不变。新的用户带来了他们自己的需求类型，现有的用户修改他们的焦点，并且常常改变其研究深度，业务周期呈现其自己的峰值和谷值类型，在大多数情况下，数据仓库随着它存储数据跨越更长时期而进行扩展。

索引的使用在只读的数据仓库中将更加自由，因为索引是为了高效的数据检索而定义的。索引应根据数据仓库决策支持环境中的访问模式和查询需求来进行优化。

随着数据仓库上的需求发生改变，一些索引成为无用的，而需要创建其他索引，一些聚集不再被引用，而其他的则需要进行评估，必须对并行处理上的限制进行评估和调整，以满足当前需求。这些任务和其他调优任务都将定期执行，以确保查询性能满足业务需求。

查询性能的评估和调优最接近于包含了一系列连续改进的进行过程。每次改进都是从对于分组查询的较差响应时间的抱怨或观察开始的。

在执行查询调优任务之前，您需要知道有问题的查询的期望响应时间。为了刻画工作负载，您必须整理查询，将其组成家族，然后确定它们在处理时间、I/O 请求、内存需求、网络数据信息量（如果可适用）等方面的资源需求。期望的查询响应时间是基于对查询工作负载特性的评估而估算的。

一旦知道了期望的响应时间，并且测量了查询的当前响应时间，就可以按照下列方法定期调优数据仓库：

1. 分析监控的响应时间，以确定它们是否满足期望的响应时间。
2. 当查询无法满足响应时间目标时，考虑进行调优：
   • 设置系统和数据库的性能监控，收集数据和分析监控的响应时间信息以寻找瓶颈。
   • 记录产生最大乃至最小影响的性能决定因素的列表，以进行相应的调整。
   • 确定哪些查询仍然无法满足响应时间目标。数量应该很少。使用 DB2 Query Performance Monitor 为这些查询开发详细的概要文件和动作计划。该动作计划很可能将包含性能权衡（trade-off），这些权衡可能导致其他的资源瓶颈。
3. 继续调整系统和数据库，直到所有查询都½满足其性能目标。

 

数据仓库的安全性

数据仓库包含秘密的和敏感的业务数据。在进入稍后的数据仓库设计阶段之前，数据仓库的安全性常常被忽略。随着其中涉及了更多数据源或业务主题领域，数据仓库安全的复杂性也在增加。不同的数据源通常具有不同的安全性需求或用户，因此为集成的仓库数据定义数据访问可能十分困难。幸好 DB2 数据库系统和 DB2 Data Warehouse Center 提供了极其广泛的数据访问安全性服务，这使得维护数据仓库的安全性变得更容易。

您需要在数据仓库安全性设计中考虑许多因素：

• 数据访问：数据仓库是为了决策支持的传递而创建的；终端用户只是从中挖掘信息。对于数据仓库中数据的访问是只读性的。
• 终端用户：知道谁将使用数据仓库将指导仓库的设计。如果授权终端用户访问仓库中的所有数据，则只需要设置一个系统或数据库组来访问数据仓库即可。然而，在实际的业务世界中，不是每位终端用户都被允许访问所有的业务数据，不同的终端用户被授权访问仓库中不同的数据子集。
• 数据分析方法：有几种从数据集市中生成报表的方法，其中包括标准化的业务报表、即席 OLAP 报表和数据挖掘。对于标准化的报表，在允许终端用户访问一组预先定义的报表时，安全性易于实现。对于即席 OLAP 和数据挖掘报表，安全性很可能通过将数据库级别的数据集市或数据集市子集分配给用户组来实现。
• 性能：限制性的安全性计划是按不同的方式以牺牲性能为代价得到的。找到安全性和性能需求之间的平衡十分重要。
• 数据仓库设计：数据安全性本身就是数据仓库设计中的重要问题。该解决方案中两层的数据仓库设计假设终端用户将仅仅访问数据集市中更加用户友好的数据，而非数据仓库中复杂的数据结构。这极大地简化了数据仓库终端用户的安全性，因为数据集市通常是为特定的部门或与用户组定义的。
• 数据仓库工具：DB2 Data Warehouse Center 安全性结构是与数据库和操作系统的安全性相分离的。该结构包含仓库组和仓库用户。通过属于某一仓库组，用户可以获得对 Data Warehouse Center 对象的权限和访问。仓库组是仓库用户和权限的命名分组，它授权用户执行功能。仓库用户和仓库组不需要与为仓库控制数据库所定义的数据库用户和数据库组相匹配。

 

下图展示了 DB2 仓库用户、仓库组以及仓库数据库的用户 ID 和密码之间的关系。

图 13. DB2 Data Warehouse 用户管理结构
 

数据仓库解决方案的可交付性

下面是重要的数据仓库可交付性列表：

• 业务需求
• 数据质量假设
• 架构文档
• 逻辑和物理数据模型
• 业务数据集成规范
• ETL 设计文档
• 测试计划和结果
• 部署计划和结果
• 客户教育文档
• 技术支持文档

 

结束语

该文章系列向您介绍了商业智能，并提供了交付灵活的低成本数据仓库解决方案的基本方法。该方法使用 IBM DB2 Data Warehouse Edition Version 8.2.1，它以用户可承担的价格提供了端对端的商业智能软件，特别是对于中型市场的客户。

商业智能特定领域中所提供的信息让您洞悉在为客户开发数据仓库解决方案时将碰到的任务、决策和问题。从与客户的第一次见面到将商业智能解决方案部署到生产中，本文包含了许多有用的想法和提示，其中包括 ETL 过程、数据仓库的设计与实现，以及数据仓库的安全性和性能。

IBM 是世界一流的商业智能解决方案提供商，而商业智能也是 IBM 的关键计划。商业智能解决方案的范围很广，可以从部门级的数据集市，即用于诸如销售或金融分析的特定功能，到增加到亿万字节（terabyte）的大规模企业数据仓库。本文剖析了咨询师或解决方案提供者为交付 IBM 商业智能策略中的部分解决方案要付出什么代价。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 关于商业智能和其他解决方案领域的更多详细信息，请参阅 IBM Solution Builder Express。
  
  
• 关于更新的产品特定信息，请查看官方的 IBM DB2 Business Intelligence 网站。
  
  
• 关于商业智能的更多技术参考资料，请参阅 developerWorks 中国网站上的 DB2 Business Intelligence 专区。
  
  
• 关于 DB2 数据挖掘、编程、系统管理、内容管理等的技术和业务级特性，请阅读 DB2 Magazine。
  
  
• 关于广泛的技术主题的深入介绍，请在线浏览 IBM Redbooks。

讨论

• International DB2 Users Group 提供了许多有帮助的参考资料。
  
  

作者简介

		Leon Gong 是在 IBM Solution Builder Express Portfolio 工作的一位软件工程师。在过去的 4 年中，他为 IBM Mid-Market Business Partners 开发了许多集成解决方案。他主要致力于商业智能（Business Intelligence）和电子贸易（e-commerce）领域。他拥有 DB2 应用程序开发和管理的认证。您可以通过 leongong@us.ibm.com 与他联系。

		Mike Olivas 是在 IBM Solution Builder Express Portfolio 团队工作的一位架构师。最近，他的工作是帮助业务合作伙伴创建不同行业和解决方案领域中的解决方案，这些领域包括但不仅限于商业智能（Business Intelligence）、基础设施和工作场所（workplace）服务。您可以通过 molivas@us.ibm.com 与他联系。

		Christine Posluszny 是 IBM Solution Builder Express Portfolio 的一位解决方案开发人员。她有 6 年开发利用 DB2 的 Java 和 SQL 应用程序的经验。最近，她为 IBM Mid-Market Business Partners 开发集成解决方案。她是一位 Sun 认证的 Java 程序员。您可以通过 cpos@us.ibm.com 与她联系。

		Donna Venditti 是 Solution Builder Express 的项目经理。在过去的 6 年中，她为 IBM Mid-Market Business Partners 交付了行业级别以及跨行业级别的入门级解决方案。她主要致力于零售业的电子贸易（e-commerce）以及商业智能（Business Intelligence）解决方案领域。您可以通过 donnav@us.ibm.com 与她联系。

		George McMillan 是在 IBM Solutions Builder Express 团队中工作的架构师。最近，他与业务合作伙伴以及 SBE 架构师们一起工作，开发咨询工具（tooling），并作为方法专家为合作伙伴渠道开发方法策略。他的工作包括为不同行业和解决方案领域的业务合作伙伴创建解决方案。他在协作和内容管理领域担任技术指导，并参与团队开发商业智能（Business Intelligence）和基础设施解决方案。您可以通过 gmcmillan@us.ibm.com 与他联系。

----

http://blog.csdn.net/yuzhic/article/details/1585245