分享

IBM Infosphere Data Replication 产品族 Replication Server 与 Change Data Capture 的异同比较

 BI之路 2014-04-04


一,简介

在如今信息快速变化的商业时代,必须在第一时间做出商业决策并采取行动才能在激烈的竞争中保持领先地位。如果商业数据不能保证同步,那么生产和利润势必会遭受损失,但是,面对信息量激增并且分布存储的特点,保证数据的可信性并非易事。 IBM 的 InfoSphere Data Replication 产品族针对这一问题为应用提供了一系列数据同步解决方案,该类方案均为基于数据库日志实现对数据源变化的实时捕获,并且实时传输到目标端。本产品族包括 InfoSphere RS(Replication Server)和 InfoSphere CDC(Change Data Capture)两个产品。

回页首

二,产品介绍及其架构对比

回页首

1,Replication Server(RS)

Replication Server 产品包括 SQL 复制和 Q 复制两种技术。其中 SQL 复制(其前身为 Data Propagator)于 1994 年发布第一个版本,Q 复制于 2004 年发布第一个版本,如今已经发布了 V10FP1。相比于 SQL 复制,Q 复制的数据传输技术借助于 IBM 队列机制,从而提高了数据的传输效率和可靠性,可以达到每秒复制几千个表、几十万行数据 , 在几千英里的距离下端到端的延迟不到 1 秒(从源端 DB2 commit 到目标端 DB2 commit)。本文将主要介绍 Q 复制技术与 CDC 的对比。

如图 1 表示了 Q 复制的主要组件及其复制原理。其中主要的组成部分包括:

a).QCapture 程序,运行在源数据端,主要功能为从源数据库的日志中读取变化的数据,生成 MQ 消息并且将其放入 WebSphere MQ 队列,一般情况下每一条 MQ 消息代表一个数据库事务,消息的格式遵循一定的标准。

b).QApply 程序,并行地从队列中获取 MQ 消息,对消息中包含的数据库操作经过冲突检查、冲突处理等一系列分析处理生成相应的数据库操作,将源数据库中的数据变化反映到到目标表中。其中目标表可以是多种数据库,除 DB2 外,还可以借助于联邦数据库将数据变化复制到 Oracle, Sybase, Informix, SQL Server, Teradata 这些数据库中。

c).Websphere MQ,为 QCapture 和 QApply 之间提供数据传输功能,借助了 MQ 本身的健壮性和高性能。

图 1. Q 复制的主要组件及工作原理

图 1. Q 复制的主要组件及工作原理

回页首

2,Change Data Capture(CDC)

Change Data Capture(CDC) 的前身是 DataMirror,2007 年由 IBM 收购后正式更名为 CDC,并发布了收购后的第一个版本 V6.3,现在最新的版本为 V10.2。CDC 主要采用基于日志的变更数据捕获技术以实现对关键业务系统的实时数据复制,同时不影响业务系统性能。CDC 最大优点在于其对异构数据库的支持和与 IBM 产品的集成,为客户在数据迁移,整合,同步,动态数据仓库等应用中提供了卓越的解决方案。

图 2 显示了 CDC 的关键组件及其复制原理,其主要的组成部分包括:

a).Access Server(AS):用户配置和监控 CDC 引擎的安全管理工具,支持图形化界面(V6.5 之后集成在 MC 中)及命令行

b).Management Console(MC):CDC 的图形化界面工具,用于管理和配置复制信息,并对复制状态进行实时监控,获取 CDC 运行信息

c). 源端引擎:读取源端数据库的日志文件捕获变更数据,经过行列过滤,字符编码转换后由 TCP/IP 发送给目标端

d). 目标端引擎:接收源端发送的变更数据,经过数值转换,字符编码转换,冲突检测后将变更数据应用到目标数据库

e). 多数的 CDC 引擎既可作为源端引擎捕获变化数据又可作为目标端引擎接收变化数据并将其应用于指定的数据库;通常,CDC 引擎称为 CDC 实例,如果从 AS/MC 的角度,一个 CDC 引擎也被称作一个 CDC 数据存储

f). 元数据:存储 CDC 实例的配置信息,包括数据库连接信息,预定信息以及表的映射信息等,同时记录当前的复制进行状态

图 2. CDC 关键组件及复制原理

图 2. CDC 关键组件及复制原理

回页首

3,比较

RS 和 CDC 支持目前市场应用中的大部分数据库系统之间的复制,以下是二者支持的数据源,目标,消息队列及操作系统的对比:

表 1:RS 与 CDC 所支持数据源及操作系统对比

源端 / 目标 仅作为目标端 操作系统
RS DB2 LUW,DB2 z/OS,DB2 i(仅在 SQL 复制中支持),DB2 VSM/VM 服务器(在 Q 复制中作为源端支持),Oracle,MS SQL Server(在 SQL 复制中可以作为源端 / 目标端),Sybase 在 SQL 复制中可以作为源端 / 目标端),Infomix 在 SQL 复制中可以作为源端 / 目标端) MS SQL Server(在 Q 复制仅作为目标端),Sybase(在 Q 复制仅作为目标端),Infomix(在 Q 复制仅作为目标端),Teradata IBM i OS,z/OS,AIX,HP-UX,Solaris,MS Windows,Red Hat, SUSE Linux
CDC DB2 LUW,DB2 i,DB2 z/OS,Oracle,MS SQL Server,Sybase,Infomix,SolidDB,Classic z IMS (source only) Information Server,Netezze,Cognos Now!Teradata,Greenplum,MySQL,MQ Series,JMS,TIBCO,WebMethods,BEA IBM i OS,z/OS,AIX,HP-UX,Solaris,MS,Windows,Red Hat, SUSE Linux

回页首

三,关键复制技术对比

回页首

1,Replication Server(RS)

图 3 显示了 Q 复制中的一个典型的简单配置,下面将根据本图中的配置描述 Q 复制技术的工作原理。

图 3. Q 复制工作原理分解

图 3. Q 复制工作原理分解

Q 复制通过 Q Capture 和 Q Apply 这两个程序将已提交的事务性数据从源表复制到目标表。在使用 Q 复制的时候必须首先设置源表的日志机制为“归档日志”,这是因为 Capture 程序是根据数据库日志中记录的信息发现源表的数据变化的。

Q Capture 和 Q Apply 程序都使用一组控制表来跟踪它们执行其任务所需要的信息以及存储它们自己生成的信息,用户可以使用控制表告诉 Q 复制您的复制源和目标是什么,也可以使用控制表来查看 Q 复制执行情况的信息。Q Capture 程序使用的控制表称为 Q Capture 控制表,这些表包含复制源及其对应目标、capture 所使用的 MQ 队列、Capture 运行时参数等信息。可以在一个系统上运行多个 Q Capture 程序,每个 Q Capture 程序使用自己的一组控制表,这些不同组的 Q Capture 控制表通过 Q Capture 模式标识,在启动 Capture 的时候需要通过 capture_schema 参数指定将要运行的 Capture 程序将使用哪一组控制表。

类似,Q Apply 程序使用的一组控制表称为 Q Apply 控制表,这些表包含有关目标及其对应源所在位置、Apply 使用的队列名称以及运行时参数等信息,启动多个 Apply 程序的时候通过 apply_schema 参数指定的 Q Apply 模式来指定使用哪组控制表。

在复制的过程中 Capture 和 Apply 可以运行在不同的系统上;Capture 程序既可以和源表运行在同一系统上,也可以是不同的系统上,如果运行在不同的系统上,需要将要复制的源数据库 catalog 到 Capture 程序所在的系统上,以便 Capture 远程地读取源表中的数据变化;同理,Apply 也可以和目标表位于不同的系统上。在复制的过程中并不要求源表和目标表使用同样的名字,这些信息在控制表中进行配置。

Q Capture 启动的时候从 Capture 控制表中读取信息,得知要复制的源表的位置,按顺序读取数据库恢复日志以获取对源表的更改。如果 Q Capture 程序读取到对某个源表的更改,那么它就会将该更改添加到驻留在内存中的相应数据库事务,但并不是源数据库日志中所有信息都添加进来,Capture 只包含对控制表中定义的 Q Subscription 中的源表的更改,这里 Q Subscription 定义了一对源表和目标表的映射关系。当 Q Capture 程序读取某个事务的 COMMIT 语句时,它会将该事务转换为一条消息并将该消息放置在发送队列中。

Q Apply 程序读取到达目标服务器的接收队列中的消息,将这些消息转换为 SQL 操作, 并将事务应用到相关的目标表。Q Apply 程序是一个多线程程序,它可以同时应用多个互相没有依赖关系的事务,如果事务互相依赖,那么 Q Apply 程序会以源服务器中提交这些事务的顺序应用这些事务。

可以为一对 Q Capture 和 Q Apply 程序配置多个复制队列映射,每个队列映射关系指定了一对用来发送数据和接收数据的队列映射关系,以及其他 Capture 和 Apply 需要使用的队列。如果源服务器中正在运行的的应用程序需要操作独立的多个表集,那么可以考虑定义多个复制队列映射,以允许并行传递和处理每个独立表集的数据,Q Apply 程序将为每个接收队列创建一个多线程进程。

回页首

2,Change Data Capture

图 4 显示了 CDC 复制技术的基本工作原理:

图 4. CDC 工作原理分解

图 4. CDC 工作原理分解

CDC 通过日志读取模块(Log Reader)读取源端数据库中所有活动表的变化日志,并判断出哪些数据变更日志属于 CDC 配置的预定中所涉及的源端表,并将这些与应用有关的变更日志放在事务队列(Transaction Queue)中。日志读取模块读取的日志包括 redo log,archive log,transaction log 等。由于尚未提交的事务也会被 CDC 日志读取模块读取并放在事务队列中,所以事务队列中记录了各个事务的进行状态。而日志解析模块则负责过滤出事务队列中已经提交了的事务变更日志,并将其放入变更日志存储(Staging Store)中。变更日志存储是 CDC 在内存中开辟的一块存储区域,主要用来存储应用相关的表的数据变更日志,通常情况下,一旦有一条日志进入变更日志存储,与其相关的预定会马上取走该条日志处理,进行行列过滤后和其他一些变换之后,通过 TCP\IP 发送至目标端。

由上图可见,CDC 的所有预定共享一套日志读取,解析,事务队列和数据变化存储,该设计的优点在于可以极大的降低 CDC 在源端应用系统的影响极资源使用,由于不需要多个日志读取模块重复读取日志,CDC 的效率得到极大提高。

回页首

3,对比

通过简单介绍 Replication Server 和 CDC 使用的技术有很多相似之处但是又有一些不同。例如,都是基于日志来读取源数据库的数据变化,并且都只复制源端已经提交的数据变更。

但 RS 和 CDC 在信息传输和确保数据一致性上方式有所不同:

a). 由于 Q Rep 使用的 MQ 作为信息传输工具,使得 Q Capture 和 Q Apply 可以以非同步的方式工作,例如,当目标系统无法使用,既由于接收队列无法正常工作、或者目标表暂时不能访问等原因造成的数据变化无法在目标端实施的时候,Q Capture 还可以继续捕获数据,直到目标便可用或者 MQ 队列消息溢出,因为 MQ 队列本身有一定的缓存功能,Q Apply 在目标端恢复使用的时候依然可以总队列中获取没有成功实施的数据变化。

b). 而 CDC 的传输方式采用 TCP/IP,没有类似于 MQ 的缓存功能,但 CDC 运用了 bookmark 机制,每当源端的一条变更日志成功地应用到目标端,CDC 便会在目标端的元数据中存储一条 bookmark,该 bookmark 记录了目标端成功应用源端发送来的变化日志的时间戳,在网络中断或者源端,目标端宕机恢复之后,目标端会将其元数据中存储的 bookmark 发送给源端,这样源端即可获目标端最后一条变更成功应用的时间戳,并从改时间戳开始继续复制,从而确保数据的一致性。

回页首

四,常见部署方式及典型适用场景简介

回页首

1,常见部署方式

RS 和 CDC 的部署方式类似,都可以采用单向,双向,并行,级联,集中,分发等多种拓扑结构及其组合的部署方式进行复制:

图 5. RS 与 CDC 常见部署方式

图 5. RS 与 CDC 常见部署方式

回页首

2,典型适用场景

在如今的商业中随时随地都在产生着大量的数据,但是这些数据杂乱无章,并不一定能直接应用于商业应用,在数据和信息之间的转换需要经过从众多庞大、异构的数据源中抽取出所需的数据、进行数据清洗、并最终按照预先定义好的数据仓库模型,将数据载入数据仓库供应用程序使用等一系列过程的。ETL(数据的提取、转换和加载)是实现此过程的一种传统工具,IBM InfoSphere DataStage 作为一款的基于图形化界面的 ETL 工具,可以读取不同数据库中数据,但是每一次都会读取全部的数据,重复性的读取严重影响了效率;而 Replication Server 和 CDC 有能力捕获更新的数据,却没有类似 DataStage 的强大数据转换的功能,并且不像 DataStage 可支持对如此多的数据库,企业级应用程序和文件进行读写。所以可将 RS/CDC 和 DataStage 联合使用,为 Warehouse 提供实时高效的数据,实现优势互补。

回页首

(1),RS 与 DataStage 整合

图 6 所示展示了一种 Q Replication 和 DataStage 整合的方式。

首先,利用 Replication Server 的 Event Publisher(EP),Q capture 从可恢复日志中捕获更新的数据,并且把数据变化写到 MQ 队列中;接着,MQ 消息通过 MQ 触发器触发了 DataStage 作业;最后,DataStage 的作业从 MQ 队列里直接读取数据进行处理。

EP 支持两种类型的 MQ 消息:XML 和 CSV,XML 格式有好的移植性和灵活性而 CSV 有很好的性能。DataStage 可以通过使用 MQ Connector stage 读取队列中的消息,然后基于所选的消息格式来解析消息,最后完成必要的转换。

图 6. RS 与 DS 整合

图 6. RS 与 DS 整合

回页首

(2),CDC 与 DataStage 整合

CDC 与 DataStage 整合的方式主要有两种:一种是通过文件的方式进行整合,可以实现大数据量的并行载入;另一种是与 DataStage 直接连接,相比于第一种方式实时性更强。

方式 1: 中间临时文件

a).DataStage 使用标准的 ETL 功能从数据源抽取、转换、清洗数据,并且装载数据到目标数据库

b).CDC 捕获数据源的变更数据

c).CDC 把捕获的数据变化写入中间临时文件

d).DataStage 从临时文件读取变更数据

e). 最后把变更数据写入目标数据库

图 7. CDC 与 DS 整合方式 1

图 7. CDC 与 DS 整合方式 1

2: 直接连接

a).DataStage 使用标准的 ETL 功能从数据源抽取、转换、清洗数据,并且装载数据到目标数据库

b). 用户定期操作,手动从 CDC 获取变更数据

c).CDC 捕获数据源的变更数据

d). 变更数据专递给 CDC for DataStage 引擎

e).DataStage transaction Stage 读取变更数并且传递给下游的 Stages

f). 最后把其它 Stages 处理后的变更数据写入目标数据库

图 8. CDC 与 DS 整合方式 2

图 8. CDC 与 DS 整合方式 2

回页首

五,关键概念区分

在 Replication Server 和 CDC 的概念中有一些不同但又及其类似容易混淆的概念,在次对他们进行了对比。

表 2:RS 与 CDC 所支持数据源及操作系统对比

RS CDC
peer to peer 是指一种对等复制配置方式,多个节点每两个之间都进行相互的数据复制操作。 定义了一个源端到一个目标端的复制配置
Map 定义了一对发送队列和接收队列,以及使用此 map 的 Q Capture 和 Q Apply 程序使用的管理队列。 定义了一对源表和目标表之间的映射关系
Subscription 定义了一对源表和目标表之间的映射关系,多个 Subscription 可以使用同一个 Q Map。 定义了一个源端(datastore)和一个目标端 (datastore) 的映射,一个 subscription 可以有多个 mapping

回页首

六,结束语

本文中将 IBM Infosphere Data Replication 产品族中 RS 和 CDC 的最基本概念放在一起介绍,意在抛砖引玉是读者对两种复制产品有初步了解,关于两种的产品更深层次的原理,请阅读下文中的相关参考资料。


    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多