转载

使用 InfoSphere Data Replication Q 复制填充准实时操作型数据存储

操作型数据存储概述

瞬息万变的商业环境迫使企业不断地开发和部署创新的技术和想法以保持竞争地位。商业智能与数据仓库技术在过去几年的发展尤为突出。企业希望通过将所有处于不同子系统中的各种数据集成到一个统一的视图里，从而进行战略、战术、执行层面的决策。在目前大部分的系统部署里，这个集成的过程通常是在后台定期运行的。但实践已然证明，企业要想成功必须要能够快速响应商业环境变化的企业。在目前的以客户为中心的经济环境里，一方面，客户希望能够及时获得和了解产品和服务的全貌；另一方面，企业必须迅速满足客户的需求。因此，如何能够集成实时数据、快速反映市场需求、做出及时决策成为企业亟待解决的问题。

网络和电子商务的蓬勃发展使得人们能够随时随地获取需要的各种信息，这一方面方便了企业及时向用户传达产品信息，另一方面也造成用户对企业服务响应时间的忍受度大大降低。为了保持竞争地位，企业不得不寻求高效方案及时收集并理解市场讯息，快速做出决策，以越来越短的周期发布适应市场需求的产品和服务。目前很多企业正在重组和重构他们的应用以适应需要，例如集成客户服务中心、风险管理系统、库存和供应链管理等等，但是他们始终面临着跨应用的数据访问需求。操作型数据存储（Operational Data Store，ODS）应运而生，它能够让企业从无休止的商业流程改造中释放出来，集成各应用中的数据，为企业提供一个统一的数据视图。本节将为读者简单介绍操作型数据存储的基本概念和特征。

什么是操作型数据存储

操作型数据存储（Operational Data Store，ODS）是一种准实时的数据存储，它集成了来自不同操作型系统的数据，具备数据仓库的部分特征和 OLTP 系统的部分特征，它的目的是针对那些存在多功能业务的企业，为用户提供一个统一全面的企业数据视图。换句话说，它是具有面向主题的、集成的、接近当前的数据交付、当前的和细节的特征的数据系统。

面向主题的：操作型数据存储可以被设计用来满足企业核心主题的需求，也可以被设计用于某一特定功能或应用设计，例如风险管理、客户垂直信息展示等；
集成的：操作型数据存储通过一套数据转化流程取得各遗留系统中的详细数据，从而形成一个统一的数据视图。这个数据转化流程与数据仓库中的数据转化相似；
接近当前的数据交付：操作型数据存储中的数据将会被持续地更新。遗留系统中发生的数据变化必须被尽快得同步到操作型数据存储中，所以速度是至关重要的。简而言之，操作型数据存储是被高频率地快速更新的，以保证数据是接近当前的；
当前的：操作型数据存储中的数据状态反映的是后台的遗留系统中的数据当前状态，因此数据是最新的，包含很少甚至没有历史数据；
细节的：操作型数据存储是设计用来为操作人员服务的，因此它包含的数据粒度还是细节型的。当然，这里的“细节”取决于操作型数据存储所用于解决的业务需求，数据粒度也有可能与原系统中的数据不同。

操作型数据存储和数据仓库的区别

从上节操作型数据存储的定义和特点可以看出，操作型数据存储是用于支持企业日常的全局应用的数据集合，如图 1 所示，它是介于数据库和数据仓库、数据集市之间的一种数据存储。与面向应用的分散的数据库相比，操作型数据存储中的数据和数据仓库一样也是面向主题的和集成的，所以进入操作型数据存储的数据也会像进入数据仓库、数据集市的数据一样进行一定的转化和处理。

图 1. 数据库、操作型数据存储与数据仓库

使用 InfoSphere Data Replication Q 复制填充准实时操作型数据存储

操作型数据存储是偏事务处理的，设计用来记录级别的数据访问，重视数据更新的速度和系统响应速度方面的性能，所以一般按照数据库第三范式进行设计；而数据仓库、数据集市是面向主题的，设计用于结果集级别的数据访问，它不在乎响应速度而偏重批处理批计算和查询速度等方面的性能，使用多维模型进行设计。实际上，操作型数据存储与数据仓库、数据集市最大的区别是其包含数据的更新频率和路径。因为操作型数据存储存放的是当前的数据，数据是及时地不断更新的，提供的是企业的当前视图；而数据仓库、数据集市中的数据通常不会进行修改，提供的是企业的历史视图。在操作型数据存储中使用数据库的插入、更新、删除操作是常见的，因为其中的数据总是反映它的最新状态；而数据仓库中基于不同的目的，通常会同时存在数据的不同版本来反映它的不同状态，因此从数据量来说，操作型数据存储所包含的数据量通常少于数据仓库。

操作型数据存储与商业智能

正如本文开篇所说，越来越多的企业依赖于信息技术来提高企业的竞争力来适应目前不断变化的商业环境，商业智能方案成为最热门的选择。很多企业都通过数据仓库技术的成功部署获得了对历史数据的理解，为企业战略层面的决策提供了有力的帮助。但企业仍然缺少对当前数据的理解，战术、执行层面的决策仍然还缺少全局的视角。操作型数据存储填补的正是商业智能方案在这部分的空缺。图 2 展示了操作型数据存储在商业智能方案中的定位。

图 2. 操作型数据存储与商业智能

当操作型数据通过数据集成和转化程序进入商业智能系统时，一个数据流进入了操作型数据存储，另一个进入了数据仓库，这两个数据流可能不尽相同，取决于功能需求。操作型数据存储同样可以使用常见的批处理方法将数据推送到数据仓库中，对于某些操作型数据存储类型，一些数据也有可能从数据仓库返回给操作型数据存储，这一部分数据可能数据量并不大但却是至关重要的，例如一些影响战术决策的战略决策。另一方面，某些操作型数据存储中，一些数据也可能会返回给终端用户，例如返回客户的准确信息，因为操作型数据存储获得了来自不同系统的最新信息，它包含的信息可能会比用户当前操作系统的信息更加准确。

回页首

操作型数据存储类型

根据操作型数据存储与事务系统之间数据交互的程度，可以将操作型数据存储分为三类，如图 3 所示，一是单向的，即数据仅从事务系统推送到操作型数据存储；二是部分双向，即少部分数据会偶尔从操作型数据存储返回到事务系统中；三是双向，即数据交互是完全对等、实时的。本节将具体介绍三种操作型数据存储的架构。

图 3. 操作型数据存储类型

单向型操作型数据存储架构

数据从事务系统通过数据集成层，流向操作型数据存储。数据更新可以是实时地也可以是批量的，取决于根据需求所部属的数据集成软件。例如对某些数据使用数据同步软件进行实时更新，对某些数据使用常见的批量程序进行日更新。这种单向类型中，不存在从操作型数据存储到事务系统的数据流。其典型架构如图 4 所示。

图 4. 单向型操作型数据存储架构

单向类型的操作型数据存储的数据源大致有两类，一类是来自于事务系统，另一类来自于数据仓库系统。来自于事务系统的数据通常是及时更新的，而来自于数据仓库系统的数据通常是在非高峰阶段的批量的更新。操作型数据存储中的数据可能会需要定期推送到数据仓库作为数据在某一时刻的快照，这部分的数据流向也需要与其他数据仓库数据源一样考虑。因此必须综合考虑操作型数据存储中的数据结构和字段，不能把操作型数据存储当做数据进入数据仓库前的临时缓存区，有些不必要的数据也不能仅仅因为它存在于事务系统中而存储在操作型数据存储中。

部分双向型操作型数据存储架构

部分双向类型的操作型数据存储除了具备单向型的特征外，它存在从操作型数据存储到源事务系统的少部分数据回流，并且回流的频率并不高，可能是一定周期的。其典型架构如图 5 所示。

图 5. 部分双向型操作型数据存储架构

这种类型出现在用户同时拥有操作型数据存储读和写的权限时。操作型数据存储的大部分使用者都是企业战术执行层人员，他们在操作型数据存储中做的数据变化是需要及时反馈到事务系统中的。这里需要解决的一个突出的问题就是数据冲突，因为数据变更有很大可能会同时发生在事务系统和比如认定来自于操作型数且据存储的对客户住址的更新最能代表数据的状态，那么当客户呼叫中心系统在同一时刻更新客户住址时，该更新将被丢弃并被来自操作型数据存储的更新覆盖。操作型数据存储中。因此回流的数据需要从业务需求出发谨慎设计，只有真正是业务需要的数据才能回流并还需要定义好当数据发生冲突时，从哪里来的数据才是被认为是最新的。由此可见，定义相关的规则至关重要，因为它可能会造成数据的丢失。在此之前，定义数据回流的触发条件和时机也是不可忽略的。

双向型操作型数据存储架构

双向类型的操作型数据存储比部分双向类型更进一步，数据在操作型数据存储和源事务系统之间通过数据集成层来回，操作型数据存储在此类型中成为了整个数据系统的主数据存储。也就是说，在此类型的操作型数据存储中的数据是所有业务系统公共的，数据在整个系统中是一致的。在这种类型中，所有信息系统都要访问操作型数据存储中的同一份数据，因此遗留系统都需要慢慢进行相应的应用修改。其典型架构如图 6 所示。

图 6. 双向型操作型数据存储架构

数据集成层对数据的转化必须是双向支持的，比如事务系统中使用“M”和“F”代表男性和女性，但操作型数据存储中使用“0”和“1”来代表对应的含义，那么不管数据流向如何，数据集成层都需要做相应的转化。另外，由于数据在任何系统上都会发生更改，这就需要各系统环境都是同构的，而且如何进行数据冲突的检查和解决在此类型中更加严峻。

回页首

使用 Q 复制实时填充单向型操作型数据存储

Q 复制属于表级别的复制技术，是通过 Q Capture 程序从数据库日志中捕获表的数据变化，而后通过 MQ 将变化传送给目标端，目标端的 Q Apply 程序将变化应用到目标数据库里，具有高性能、次妙级延迟和高吞吐量等特点。从复制的流向角度，可以导致分为四种类型：单向复制、双向复制、对等复制、事件发布。

单向复制。数据从源端流向目标端。适用于目标表仅供应用查询的情况，因为此类复制不会将发生在目标表的数据变化回传给源端。用户可以选择复制表里所有列、所有行，或者仅复制部分列、部分行。也可以将同一个数据源复制到目标多个数据库表里，或者多个数据源复制到同一个目标表等。除了普通的用户表，它的目标还可以是存储过程，这种目标类型中，源表中的列将与存储过程中的参数映射，用户可以在存储过程中定义业务逻辑，最终数据通过存储过程插入目标表。
双向复制。数据从源端流向目标端，也允许从目标端流向源端。这种复制类型适用于源表和目标表表结构完全一致的情况，用户仍然可以选择复制部分列或部分行，但必须保持源表加入复制的集合和目标表的集合一致。尽管数据变化可以发生在任一端，用户需事先定义好哪一端为主结点，支持多种输出格式，例如 XML,CSV。它使得数据能够从数据库中取出，每个 MQ 消息可以包含完整的事务或者行级别的变化，用户同样可以定制部分列或者部分行。它的出现是为了方便作为其他应用或产品的数据输入，应用只需要根据已知的格式解析 XML 或 CSV 文件即可，从而可以灵活地使用数据。当发生数据冲突时，将以该主结点中的数据为准。
对等复制。数据在多个结点间相互流动。与双向复制类似，它也需要各个结点上的复制表结构保持一致。用户可事先选择数据冲突发生是的解决方式，一般是通过数据发生的时刻来决定。
事件发布。数据流向 MQ 队列。

实现架构

Q 复制作为专业的数据复制产品，致力于提高数据的时效性，能大幅度地减少数据在获取过程的时间，它也能够做一定的数据转化操作以满足一般操作型数据存储的需求，即各种单向复制。但正如前文所介绍，操作型数据存储是介于数据库和数据仓库之间的，它对所存储数据集成的需求可能是千差万别的，而对于更复杂或者说更接近于数据仓库需求的数据集成操作，例如清洗、重构等，则需要更专业的 ETL 产品的介入，Q 复制也为这类需求提供了方便接入的接口，即事件发布类型的复制。

图 7. 使用 Q 复制实时填充单向型操作型数据存储

图 7 展示了这两种配置。图中上半部分展示的是单向复制，Q Capture 程序从数据库日志中取得数据变化后检查用户是否定义了数据过滤条件，过滤后将需要的数据转化为 MQ 消息发送给 MQ 队列，MQ 队列负责消息传输，Q Apply 程序从队列中取得消息并检查用户是否定义了特殊的映射关系，例如标量、聚集函数，存储过程等，如果存在则会调用相应的例程，转化后的数据最终被插入到目标数据库中。图中下部分展示的是事件发布与 ETL 产品的集成，事件发布只需运行 Q Capture 程序，无需 Q Apply 程序。也就是说，与 Q Apply 程序从队列中读取数据变化不同，数据变化被 Q Capture 以一定格式写入队列，因此用户可以编写自己的程序直接从队列获得数据，ETL 产品也只要实现对该格式的解析就能取得数据，从而进行复杂的数据清洗、转化、重构工作。

架构部署

对于单向复制架构，目标数据库可以是 DB2 也可以是其他非 DB2 数据库，不过需要借助联邦数据库屏蔽异构数据库的不同。在最新的 Q 复制版本中（IBM InfoSphere Data Replication v10.2.1），Q 复制实现了对 Oracle 目标数据库的直接访问，即 Native Oracle Apply，本文在此不作详细介绍。对于源端数据库，可以是 DB2 也可以是 Oracle。

源端数据库、Q Capture 程序、MQ、Q Apply 程序、目标数据库之间是松耦合的关系，一般我们会将这三者部署在同一台服务器上，但在某些情况下，需要将他们分散部署在两台或更多的服务器上，这就涉及到 Remote Q Capture 或者 Remote Q Apply，对于这些情况，Q 复制都是支持的。

在部署前，需要评估数据量、数据增量的大小，以方便计划 Q 复制的内存、存储的需求量。Q Capture 程序和 Q Apply 程序的内存大多用于数据分析、过滤、消息构建、事务重做等等。应准备足够的内存以避免 Q Capture 程序将大事务写到外存，增加 I/O 消耗。对于外存储的需求，主要在于 Q Capture 程序和 Q Apply 程序生成的日志等。

典型配置

图 8 展示了一个典型的单向 Q 复制，它通常包含一些基本的对象：源端的 Q Capture 控制表（Control Table）用于包含 Q Capture 程序需要使用的元信息，与目标端的 Q Apply 控制表对应；一些 MQ 队列，包含数据传输队列以及管理队列；复制队列映射（QMAP）确定 MQ 队列间的映射关系，即数据通道；Q 预定用于定义源表与目标表间映射关系，它必然从属于某个数据通道，即使用某个 QMAP。

图 8. 典型单向 Q 复制

因此，为了定义一个单向 Q 复制，用户需要经过几个步骤: 1）创建 Q Capture 和 Q Apply 控制表；2）创建 MQ 队列；3）创建 QMAP；4）创建 QSUB。Q 复制提供了灵活的配置工具，基于界面的复制中心（Replication Center）和基于命令行的 ASNCLP。清单 1 为一个简单的 ASNCLP 脚本，其为源表 db2admin.EMPLOYEE 配置了完全的数据复制，不存在行或列的过滤，也不存在任何转化。ASNCLP 具体的使用方法本文不做详细介绍，读者可从参考信息中心获得说明。

清单 1. ASNCLP 脚本创建单向 Q 复制

ASNCLP SESSION SET TO Q REPLICATION; SET SERVER CAPTURE TO DBALIAS SAMPLE ID db2admin PASSWORD "passw0rd"; SET SERVER TARGET TO DBALIAS TARGETDB ID db2admin PASSWORD "passw0rd"; SET RUN SCRIPT NOW STOP ON SQL ERROR ON;  CREATE CONTROL TABLES FOR CAPTURE SERVER; CREATE CONTROL TABLES FOR APPLY SERVER USING PWDFILE "asnpwd.aut";  CREATE MQ SCRIPT RUN NOW CONFIG TYPE U MQSERVER 1 NAME SAMPLE MQHOST "9.30.54.118", MQSERVER 2 NAME TARGETDB MQHOST "9.30.54.119",  CREATE REPLQMAP SAMPLE_ASN_TO_TARGETDB_ASN;  CREATE QSUB USING REPLQMAP SAMPLE_ASN_TO_TARGETDB_ASN (SUBNAME EMPLOYEE0001 db2admin.EMPLOYEE OPTIONS HAS LOAD PHASE I KEYS (EMPNO) LOAD TYPE 1);  QUIT;

数据过滤及转化

在这一部分，笔者将基于一般情况下的操作型数据存储的需求，介绍 Q 复制是如何支持数据转化的。为了方便理解，这里主要通过 RC 来配置数据过滤及转化。如图 9 所示，在创建以普通表作为目标的 QSUB 时，当进行到第 6 步“Rows and Columns”时，用户需要定义数据过滤条件，即哪些行或列是需要被复制的。默认值为所有的列和所有的行。同时用户也可以定义源和目标之间是如何映射的，也就是是否需要进行数据转化，默认值为按照相同列名进行一一映射。

图 9. 数据过滤及转化界面

点击行或列过滤框后面的按钮可以得到如图 10 所示的行和列过滤界面。在列过滤界面通过选中或着取消列名前的复选框选择需要的列。在行过滤界面，用户可通过“WHERE”语句指明需要的数据子集，也可以通过“$OPERATOIN”语句指明只复制特定的数据操作，列入插入（I）、更新（U）、删除（D）。

图 10. 数据过滤界面

点击行映射框后面的按钮可以得到如图 11 所示的数据转化界面。点击“New Expression”后在出现的表达式配置界面里，可以选择要进行转化的列，然后在表达式框中输入具体要进行的转化以及目标列的名称。例如本例中，通过表达式“CASE WHEN (:VAR1 = ‘F’) THEN 1 WHEN (:VAR1 = ‘M’ THEN 0 END”将源表中的字符值 F 或 M 转化成为目标表中的数值 1 或 0，目标表中的对应列名定义为“TEST”。在该界面中还提供了“Validate”按钮，用户可在输入完表达式后点击该按钮验证表达式的正确性。

图 11. 数据转化界面

如果存在固定模式的批量转化，用户可以从 Q 复制->定义->Q Apply 服务器，选中具体的 Q Apply，右键打开“Target Object Profiles”，找到如图 12 所示的批量数据转化定义界面，根据数据类型事先定义好不同的转化规则，这样在创建 QSUB 的步骤 6 中配置转化表达式时，这些定义好的规则会自动出现在如图 11 所示的表达式框中，用户可以选择继续使用或进行修改。

图 12. 批量数据转化定义界面

对于数据的过滤和转化，正如前文提到的，除了上述介绍的行级别的变化，用户还可以在一个存储过程中定义好各种复杂的过滤和转化的逻辑，然后创建一个以存储过程为目标的单向复制。由于存储过程的定义与业务逻辑相关，本文不再举例介绍，这里列出了通常需要经历的几个步骤：

写好一个存储过程。除了与源表的列一一对应的参数，该存储过程还必须有 4 个 Q 复制需要的参数：OPERATION (INOUT)，SUPPRESSION (IN)，LSN(IN)，COMMITTIME (IN)，这些参数必须是存储过程的前 4 个参数，代表数据操作类型、是否被压缩、源事务提交的日志序号和时间戳。用户可参考随产品打包的存储过程实例来定义自己的存储过程。
在目标数据库上创建、编译、绑定该存储过程。
赋予 Q Apply 程序使用该存储过程的权限。
如果存储过程的最终结果会涉及到目标数据库中的某些用户表，确保这些表存在且可用。
创建以该存储过程为目标的单向 Q 复制。

回页首

使用 Q 复制实时填充双向型操作型数据存储

尽管 Q 复制支持双向复制，但其要求两端的表结构是一致的。而正如前文所述，在双向型的操作型数据存储中，是希望数据能够在事务数据库和操作型数据存储中转化和逆转化的。因此，Q 复制进一步改进了单向 Q 复制，允许用户可以在一对源表和目标表间，两个方向上定义独立的单向 Q 复制，并且提供不同的选项供用户定义当数据发生冲突时数据的解决方案。由于实现架构、配置部署以及数据过滤和转化的机制与单向复制类似，这里重点介绍数据冲突的检测和解决。

实现架构

图 13 展示了该实现架构，用户可简单理解在一对表间的两个方向各定义一个单向 Q 复制。但与单向型操作型数据存储架构不同，这一架构要求在同一端同时运行 Q Capture 程序和 Q Apply 程序。

图 13. 使用 Q 复制实时填充双向型操作型数据存储

冲突检测和解决

Q 复制提供了数据冲突检测和解决机制供用户在配置 Q 预定时选择。如果使用复制中心，在创建 Q 预定步骤 7“Unexpected Conditions”时，需要确定两个问题的答案，第一个是“Q Apply 程序将如何检测冲突？”，另一个是“发生数据冲突时，Q Apply 程序将如何解决？”。对应于 Q 预定的属性，他们分别是 CONFLICT_RULE 和 CONFLICT_ACTION。

图 14. Q 复制冲突检测和解决

对于 CONFLICT_RULE，即冲突检测规则，Q 复制目前支持三种：

K（Key Only）。只检测关键字，即当 Q Apply 程序在目标表查询某行是否存在时，只有关键字列及值会放在查询语句的 WHERE 子句中。
C（Changed Columns Only）。除了关键字，发生数据变化的列也将会被放在查询语句的 WHERE 子句中。
A（All Columns）。无论该列是否发生数据变化，所有列都会用于 WHERE 子句定位目标表中的行。

对于 CONFLICT_ACTION，即冲突解决方案，Q 复制目前支持两种：

I（Ignore）。忽略 Q 复制捕获到的数据变化。这行变化虽然不用被应用到目标表中，它仍然会被记录在 Q Apply 控制表 IBMQREP_EXCEPTIONS 中以便用户分析。
F（Force）。将 Q 复制捕获到的数据变化强制应用到目标表中。根据具体的冲突类型，操作会略有不同:
- 如果 Q 复制捕获的是一个 Update 操作，但是目标表中不存在对应行，将 Update 转化为 Insert 从而将数据插入目标表；
- 如果 Q 复制捕获的是一个 Update 操作，目标表中存在与其关键字匹配的行，但非关键字列不匹配，更新目标列使其与捕获的数据变化一致；
- 如果 Q 复制捕获的是一个 Delete 操作，而目标表中不存在对应行，则什么都不做；
- 如果 Q 复制捕获的是一个 Delete 操作，目标表中存在与其关键字匹配的行，但非关键字列不匹配，将该行删除；
- 如果 Q 复制捕获的是一个 Insert 操作，目标表中存在与其关键字匹配的行，覆盖该行使其与捕获的数据变化一致。

回页首

结束语

本文首先介绍了什么是操作型数据存储以及它在商业智能系统里扮演的角色，在进一步介绍了操作型数据存储的不同类型后，从实现架构、架构部署、数据过滤和转化、数据冲突和检测等方面，重点介绍了用户如何通过 InfoSphere Data Replication 中的 Q 复制技术来达到单向型和双向型操作型数据存储的实时填充，从而让企业最终能够及时获得市场信息作出决策。由于数据转化随业务的不同千差万别，本文仅从原理角度介绍了 Q 复制的使用，在具体实施过程中，用户需要针对具体需求具体分析，无论是使用 Q 复制中的单向复制实现行对行的转化，或者是使用存储过程为目标的单向复制，亦或是使用 Q 复制的事件发布与 ETL 工具或产品结合使用，甚至结合多种配置混合使用，都是可以的。

正文到此结束