大数据治理系列，第四部分: 大数据治理统一流程参考模型的第四步到第九步

shawnsun007 2016-04-17

展开全文

大数据治理专题详细阐述了什么是大数据治理、为何要做大数据治理，并结合实际业务问题介绍了大数据治理统一流程参考模型的实施步骤，以及 IBM 相关的大数据治理的产品介绍。

大数据治理统一流程参考模型（续）

第四步：定义业务问题

如何准确的定义和描述业务问题是数据治理计划成功的关键，企业可以从对特定问题或领域进行数据治理的紧迫程度以及数据治理能够带来的价值来综合衡量，对排名靠前的问题或领域优先进行数据治理，这样能充分获得业务职能部门以及 IT 部门的支持，从而保证数据治理计划的成功。数据治理初始范围确定后，执行具体的数据治理工作，等成功后再考虑扩展至其他领域。

总结以往很多企业进行数据治理失败的原因时可以发现很多经常出现的症状，比如：

企业未从数据治理中获得任何价值；
数据治理过于长期，和企业专注短期目标不符；
IT 部门应对数据质量负责；
IT 部门认为数据治理过于复杂，无法顺利落地；
企业为数据管理员分配了其他职责。

分析以上问题出现的根源，可以发现数据治理计划失败的根本原因在于与业务价值缺乏关联，IT 部门独自进行数据治理，没有和相关业务部门进行联动。数据治理需要所有利益相关方参与，可以从业务角度（而不是技术角度）总结出各种数据治理的价值，从而吸引相关业务领域高层领导的支持，从而保证数据治理可以获得更高的业务收益。举例说明如何定义业务问题，很多上市公司财报都被监管机构要求提供其数据来源并证明其数据可信，而报告本身所使用的数据流经信息供应链多个组件（如立方体、数据集市或数据仓库、ODS、ETL、数据源等）并在各个组件间进行特定转换，如果没有方便易用的数据沿袭分析，公司无法准确向监管机构描述其数据来源，如果没有严格的审计分析报告（记录数据都经过哪些访问和变更），公司无法向监管机构证明其数据可信。另外，安全与隐私同样是企业关注的重点，比如如何保护个人可标识信息（PII），如何限定对敏感信息的访问等。

回页首

第五步：获得主管支持

数据治理计划获得主管支持至关重要，通常需要创建虚拟数据治理工作团队、获取来自 IT 部门和业务部门内部高级管理层的支持以及识别数据治理的所有者等子步骤。

创建虚拟数据治理工作团队：通过跨部门的虚拟数据治理团队解决各个业务条块各自关心的业务问题。
获取来自 IT 部门和业务部门内部高级管理层的支持：越早越频繁地引入利益相关方参与并获取利益相关方高层的支持，数据治理计划越容易成功。
识别数据治理的所有者：数据治理可以根据业务条块单独进行以及跨业务部门（需要业务部门和 IT 部门参与）统一进行。按业务条块单独进行的好处是业务部门非常熟悉其业务问题可以快速上手，缺点是难以解决跨业务条块的数据治理问题。跨业务部门统一进行数据治理的好处是可保证整个企业数据治理的一致性，缺点是协调工作比较多，进展不如按业务条块快速。同时越来越多的企业倾向于委任数据治理的综合所有者进行统一的数据治理协调和管理，该所有者可能是首席信息安全官（CISO）、首席信息官（CIO）、首席风险官（CRO）、首席合规官（CCO）和首席隐私官（CPO）等，也可能是全职的首席数据官（CDO）。

回页首

第六步：执行成熟度评估

根据能力成熟度模型（CMM）提供的分类方法，成熟度可以分为 5 个等级，1 级为初始级，此时流程通常是临时的，整体环境不够稳定；2 级为受管级，成功是可重复发生的，但可能无法针对组织中所有项目重复流程，存在基本的项目管理和流程规则，但仍有超出预期成本和时间的风险；3 级为定义级，建立了标准流程集，通过组织的标准流程集定制标准、流程描述和项目过程，以适应特定项目或组织单位；4 级为定量管理级，对流程进行定量度量和控制，所选的子流程大大提高了整体流程绩效；5 级为优化级，在该级明确了组织的定量流程改进目标，并不断优化以适应变化的业务目标。

IBM 数据治理成熟度模型如图 1 所示，共包含 11 个类别来度量数据治理能力，分别隶属于四个相互关联的组 [1]。

成果（Outcomes）：数据治理计划预期结果，通常致力于降低风险和提升价值等，而降低成本和提高收入反过来又促进了实现这些结果。

数据风险管理及合规性（Data Risk Management&Compliance）：确定数据治理与风险管理关联度，用来量化、跟踪、避免或转移风险等。
价值创造（Value Creation）：确定数据资产是否帮助企业创造更大价值。

支持条件（Enablers）：

组织结构和意识（Organizational Structures & Awareness）：主要用来评估企业针对数据治理是否拥有合适的数据治理委员会、数据治理工作组和全职的数据治理人员，是否建立了数据治理章程以及高级主管对数据的重视程度等。
管理工作（Stewardship）：是指质量控制规程，用来管理数据以实现资产增值和风险控制等。
策略（Policy）：为企业如何管理数据在高级别指明方向。

核心规程（Core Disciplines）：

数据质量管理（Data Quality Management）：主要指用来提高数据质量，保证数据准确性、一致性和完整性的各种方法。
信息生命周期管理（Information Lifecycle Management）：主要指对结构化、半结构化以及非结构信息化全生命周期管理相关的策略、流程和分类等。
信息安全与隐私（Information Security and Privacy）：主要指保护数据资产、降低风险的各种策略、实践和控制方法。

支持规程（Supporting Disciplines）：

数据架构（Data Architecture）：是指系统的体系结构设计，支持向适当用户提供和分配数据。
分类与元数据（Classification and Metadata）：是指用于业务元数据和技术元数据以及元模型、存储库创建通用语义定义的方法和工具。
审计信息记录与报告（Audit Information Logging and Reporting）：是指与数据审计、内部控制、合规和监控超级用户等有关的管理流程。

图 1. IBM 数据治理成熟度模型

IBM 数据治理成熟度模型框架提供了衡量当前状态和未来状态之间差距的参考，比如某用户其数据治理成熟度评估结果如图 2 所示，成熟度级别与能力成熟度模型一一对应。

图 2. 数据治理成熟度评估示例

回页首

第七步：构建路线图

路线图是关于人员、流程和技术方案的短期和中长期计划，通常，企业需要制定未来 1 到 2 年数据治理计划的路线图。根据数据治理成熟度的评估结果（11 类数据治理成熟度的当前状态）以及与未来目标的差距，列出弥补这些差距所需要关键人员、流程和技术计划并根据计划的优先级制定路线图。随着大数据对企业越来越重要，信息治理计划需要将大数据纳入路线图之中。

回页首

第八步：建立组织蓝图

企业需要组建具有足够权限的数据治理组织架构以便可以贯穿整个企业各个业务、技术和管理部门对整个信息供应链进行治理。针对大数据治理计划，企业需要明晰大数据治理的目标和关键流程图，以识别大数据治理中的利益攸关者，酌情任命大数据主管并确定新增角色和现有角色的适当组合，确定各个角色应当承担的大数据责任。当企业的数据治理计划相对成熟时，就会有很多确定的角色如首席信息官（CIO）、首席信息安全官（CISO）、首席隐私官（CPO）、首席数据官（CDO）、信息治理主管和数据主管等，企业需要明确这些已经存在的角色是否可以承担大数据治理职责，还是需要设立新的大数据角色，二者都可以，企业可以根据自己的情况进行选择。比如很多企业特别是金融机构都会设有首席数据官（CDO），负责制定企业的信息治理计划，保证整个企业层面的信息可信度，很多时候首席数据官也会将大数据纳入其职责范围。

建立组织蓝图总共包括以下步骤：

定义数据治理章程：描述数据治理主要目标和关键流程图、关键利益相关方、角色、职责、决策权和成功的度量方式等。
定义数据治理的组织结构：通常建议在三层模式运行数据治理效果最佳，顶层为数据治理委员会（包括高级利益相关方），中间是数据治理工作组（包括负责定期治理数据的成员），底层是数据管理员工作组（负责数据的日常处理）。
建立数据治理委员会：由数据治理计划的主管发起人组成，该委员会负责数据治理的愿景和目标、并协调企业内各部门，掌控数据治理计划的总方向。该委员会可能包含首席信息官（CIO）、首席信息安全官（CISO）、首席风险官（CRO）、首席合规官（CCO）、首席隐私官（CPO）和首席数据官（CDO），还可能包括来自财务、法律、HR 团队以及各业务部门的代表等。
建立数据治理工作组：主要负责数据治理计划的日常运作并负责监督数据管理员工作组，该组组长通常由数据治理委员会成员兼任，如果存在首席数据官（CDO）常常会由该角色担任。
确定数据管理员：数据管理员负责处理每天具体的问题和事物。
定期召开数据监管委员会和工作组会议。

回页首

第九步：了解数据

想要成功地实施大数据治理计划，需要了解信息供应链中的各个环节的数据模型、主外键关系、数据分布情况、数据源之间的数据沿袭和转换逻辑等。针对狭义大数据，可以根据用例的实际情况详细了解该用例中信息供应链各个环节的详细情况，具体实施第九步了解数据时可以通过使用 IBM Information Server 相关组件减少工作量，提高工作效率。

InfoSphere Information Server V9.1（以下简称 IIS）主要用来帮助企业实现数据集成并构建健壮的信息架构，其由多个产品模块组成，这些模块可以一起部署也可以单独部署。IIS 提供了全方位数据整合的功能，使信息能够在企业内跨不同系统实现无缝共享。如图 3 所示，IIS 主要实现的功能有：了解、清理、变换、交付和执行统一元数据管理：

了解数据：IIS 可以帮助您自动发现信息内容和结构，并对其进行建模、定义和监管，以帮助您了解和分析信息的含义、关系和继承。通过 IIS 可以更好的了解数据源和关系，并定义业务规则来消除使用火扩散错误数据的风险。
清理数据：IIS 通过对数据执行标准化、验证、匹配和合并操作，支持信息质量和一致性管理。该平台通过匹配数据源之间或数据源内的记录，可以帮助您创建一个全面而准确的信息视图。
将数据转换为信息：IIS 转换并整合信息，确保其具有正确的含义，通过 ETL（抽取，转换和装入）提供大容量的复杂数据转换和移动能力，根据需要可以提供批处理或实时数据处理。
交付信息：IIS 允许对信息进行虚拟化和同步，允许转换规则发布为 service 并被多个应用部署和复用，支持 SOA 体系架构。
统一的元数据管理：IIS 在共享元数据存储库的基础上统一进行业务、操作和技术等领域元数据的管理，采用统一元数据基础架构，支持基于字段的影响分析和元数据的血缘分析。

图 3. IBM InfoSphere Information Server 信息服务器集成功能

IIS 对应的产品组件如图 4 所示，所有组件由一个全面的集成服务平台支持，提供统一的用户界面、统一的并行处理引擎、统一的元数据管理、共用的连接能力（可以连接各种信息源，无论是结构化还是非结构化）和共用的基础服务（比如用户管理、安全管理、日志记录和报告等）。IIS 包含四层：客户机、元数据存储库、服务和引擎，客户机包含 Information Server 控制台（面向任务的控制界面，比如创建作业调度）和 Information Server Web 控制台（主要用来浏览信息服务目录）两部分；元数据存储库主要由 Metadata Server 提供服务；服务层主要由 Information Services Director 提供，其本身是一组在 WAS 上运行的 EJB 程序，并将 IIS 组件任务生成为 EJB 会话 Bean，比如 DataStage 作业或 QualityStage 作业如果发布为服务就会生成为会话 Bean；引擎层是实际提供信息服务程序所在的位置，比如 DataStage、QualityStage 和 Federation Server 都在这里。

图 4. IBM InfoSphere Information Server 信息服务器产品组件

如图 5 所示，在 IIS 各个组件中我们可以使用 Business Glossary 来获取数据的业务视图，使用 Data Architect 定义数据模型，使用 Information Analyzer 来分析数据，使用 FastTrack 来指定数据关系和变换，使用 DataStage 进行数据转换并使用 QualityStage 进行数据标准化，使用 Metadata Server 进行统一元数据管理，并使用 Metadata Workbench 对公共元数据存储库中的信息进行查询、分析和报告，还可以使用 Information Services Director 发布 web 服务。

图 5. IBM InfoSphere Information Server 信息服务器各组件协作流程

回页首

InfoSphere Information Analyzer

InfoSphere Information Analyze（以下简称 IA）是一款数据质量分析工具软件，用来在项目初期对数据源进行数据质量分析，以便真正地了解源数据的结构、质量和数据分布等，提早发现数据的缺失、错误、重复和不一致等问题，为后面的数据复制、ETL 等过程提供支持，以便降低项目实施风险。通过使用 IA，项目开发人员可以方便的了解源数据的特性从而为 ETL、复制等制定合适的规则，确保项目的顺利进行。IA 的逻辑体系结构如图 6 所示：

图 6. IA 系统体系结构

IA 通过读取数据源的表结构 DDL 信息，对表中数据进行扫描、统计，并将统计结果存入自带的 IADB 数据库中。通过 IADB 中的各种信息，可以为用户提供各种数据质量分析结果。IA 数据质量分析功能主要包括：

强劲和可扩充的数据轮廓分析：

完全并行处理的系统架构，提供强大的数据处理能力。
针对全部分析任务，提供对字段、数据表和多数据表之间的抽样运行选项。
实现多个字段、主键/外键的灵活组合分析。
提供立刻或定时运行分析任务的选项。

与 IBM 数据服务器集成：

与 IBM QualityStage/DataStage 软件工具共享元数据。
支持 IBM Business Glossary 元数据录入和管理的软件工具。
通过分析结果，进行验证并可生成可供参考的映射表。

高安全性的分析架构：

以项目为基础，控制并允许对重要数据的访问。
支持以角色为基础，和以用户为基础的安全访问权限控制。

支持广泛数据库系统和平台：

通过 IBM-branded ODBC 驱动软件，连接全部符合业界标准数据库，也可连接 IBM 主机系统数据库。
支持全部开放操作系统平台，包括：AIX、Solaris、Red Hat Enterprise Linux AS、HP-UX 、SuSE Enterprise Linux、Microsoft Windows。

灵活分析机制：

支持多种分析逻辑流程组合。
支持多种层次分析，可选择从数据目标（Schema）、数据表（Table）、或指定字段（Column）作分析。
支持全部字段或部分数据抽样分析。
支持交互式分析数据。

标准元数据管理：

无需把源系统的数据传送和复制到本地数据库，仅对源数据作分析。
存放分析结果和对应元数据的数据库，是标准的关系型（RDBMS）数据库并支持 DB2、Oracle、SQL Server 等。
提供多达 40 种 out-of-the-box 分析报告，元数据库可开放给任何 BI 系统或报表工具系统，以共享分析结果数据。

IA 工具软件具体提供的功能有：

列分析：通过对源数据库表的列进行分析，帮助用户了解源数据的结构、内容、质量和准确性等，允许用户对具体的列进行钻取以便对该列进行特殊的质量控制，支持用户进行值域（某个属性正确值的集合）分析。
主键分析：通过对源数据库一个或多个表的所有候选列进行分析，帮用户找出表中哪些列适合做主键，以及哪些列不适合做主键等（比如存在大量重复记录）。
外健分析：检查表之间的内容和关系，帮助用户识别外键，并检查主键和外键之间的参照完整性。
跨域分析：检查表之间的内容和关系并进行分析，以确定列之间值的重叠以及表内和表间数据的冗余情况。
基准分析：帮助查看内容和数据结构随时间而发生的变化。
数据规则和指标：支持用户创建逻辑规则进行数据验证，验证规则分析可以延伸数据源或跨数据源的评估，以定义数据之间的关系。允许以多种方式表达验证规则。

回页首

InfoSphere Federation Server

InfoSphere Federation Server 提供了对同构和异构数据源的虚拟化集成，从而使应用程序可以访问和集成不同数据和内容源（就如同它们是单个资源一样）。InfoSphere Federation Server 执行此操作时与信息所在的位置无关，同时保留了数据和内容源的自主性和完整性。联邦系统是一个典型的分布式数据管理系统，通过联邦功能，我们可以透明实时的访问分布在企业各个竖井中的数据，包括同构和异构数据，数据源可以是各种关系型数据库和半结构化数据，比如 XML、Excel 等。只要对数据源具有足够的权限，就可以对源库表中的数据做增加、删除、更改和查询操作，在实际使用过程中，企业倾向于只拥有源库的查询权限，以便万一源库数据出现问题时责任比较清晰。

InfoSphere Federation Server V10.1 支持多种数据源，包括 DB2、DB2/390、DB2/400、Informix、Oracle、Sybase、MS SQL Server、postgreSQL 等多种关系型数据库，也包支持非关系型的半结构化数据源。联邦服务器（InfoSphere Federation Server）通过包装器（Wrapper）与各个数据源进行通信，针对各类数据源，联邦服务器提供专用的包装器实现对异构数据源的 SQL 处理，支持对异构数据库直接的数据类型和函数的转换。对主流关系型数据库（比如 DB2、Informix、Oracle、Sybase、MS SQL Server 等）包装器通过该数据库的客户端与该数据库进行交互，对开源关系型数据库通过 ODBC 驱动与其进行交互。对非关系型数据源，包装器直接进行数据访问。联邦服务器不需要在数据源端做任何更改，也不安装任何插件，只需要安装配置联邦服务器，即可实现实时的信息整合。联邦服务器的原理如下图 7 所示：

图 7. 联邦服务器原理

回页首

InfoSphere Replication Server

InfoSphere Replication Server V10.1（从 10.1 开始，将和 CDC 一起合并为 InfoSphere Data Replication）能跟踪源数据库的更新并将其中部分或全部更新复制到目标数据库，利用 Replication Server 提供的复制能力可以实现在不同数据库直接的数据复制。复制支持 1 个数据源对多个目标数据库，多个数据源对一个目标数据库，既可以单向复制，也可以双向复制，从而实现数据整合、业务分离、数据容灾的功能要求。

Replication Server 具体支持两种数据复制：SQL 复制和 Q 复制。SQL 复制可以在主流关系型数据库（同构或异构）之间实现数据复制，Q 复制是基于对数据源日志文件捕获对源表所作的更改，并通过 Websphere MQ 消息队列将已落实的更改传输至目的服务器，并将更改应用于目标表。这两种复制技术都能支持多种数据同步拓扑结构，提供数据同步监控、数据一致性校验和容错机制。

SQL 复制具体复制方式包括准实时复制、定时复制、双向复制、复制转发、增量复制等，复制范围可整表复制或表中部分行复制，可对复制对象进行简单转换、归并、拆分等操作。SQL 复制支持的数据源有 DB2 z/OS 版、DB2 for Linux，UNIX and Windows、DB2 i 版、Informix、Microsoft SQL Server、Oracle 和 Sybase，目的数据库除了上述源库以外还支持 Teradata。当数据源是 DB2 数据库时，Replication Server 通过读取数据库日志获取数据的更新，当数据源是非 DB2 数据库时，则通过触发器机制捕获源库的更新并存储到 CCD 表中，然后通过 Capture 服务器提取源库的更新信息，Apply 服务器获取 Capture 的结果后根据复制映射关系进行转换并按照一定的刷新周期应用到目标数据库。

Q 复制是一种高吞吐量、低延迟的数据同步方法，通过使用 Websphere MQ 的消息队列，在源数据库和目的数据库之间以及源系统和目标系统之间传递事务。通过捕获并同步数据变化的增量信息，使数据源和目标数据之间数据内容保持一致。与 SQL 复制相比，Q 复制对网络的要求不高，因为 Q 复制可以做到数据的异步复制（基于 MQ 的消息异步传输）。Q 复制目前支持的数据源有 DB2? z/OS 版、DB2 for Linux，UNIX and Windows、DB2 VSE & VM 服务器和 Oracle（10.2 和更高版本），目的数据库在上述源数据库中不支持 DB2 VSE & VM 服务器，对 Oracle 数据库没有版本限制，另外还支持 Informix、Microsoft SQL Server、Sybase 和 Teradata。Q 复制设计用于支持业务连续性、数据备份、工作负载分发和应用程序集成场景。Q 复制具有以下几个优点：

低延迟：通过与 Websphere MQ 的有效集成，使得对源表进行的修改一旦提交，并从日志中读取到这些修改，这些变化就会立即被发送出去。
对数据源影响小：最大程度减小对源数据库上的操作。
高吞吐量：Q Capture 程序始终可以跟踪在源表发生的快速变化，并且 Q Apply 程序使用多线程，使得它能够及时跟踪通信通道中的消息。
低网络流量：消息使用一种压缩格式在队列中传送，而且在发送数据的选项中允许选择传送最少量的数据。
异步性：消息队列使得 Q Apply 程序可以不连接源数据库或者源子系统就可以接收事务。如果 Q Capture 程序或者 Q Apply 程序停止，在程序可用后，需要进行处理的消息仍然存在于队列中。由于消息是永久的，所以数据源和目标即使在系统或设备故障的情况下仍可以保持同步。
可以对数据进行筛选，使得仅复制需要的数据。
通过调用存储过程方便的实现数据的转换，以适应不同应用的要求。

Q 复制技术是数据库表级的数据同步技术，可以灵活的指定需要同步的数据内容。比如，可指定某些表作为复制来源，指定一个或多个表作为每一张数据源表的复制目标；可配置复制源与复制目标间的数据映射关系，如选取数据源表中的某些列，或者用 SQL 语言的 where 子句进行过滤选取数据源表中符合 where 子句条件的某些行；可过滤数据源表上的 Delete 操作而只获取 Insert 和 Update 操作产生的数据增量。Q 复制技术可以支持各种灵活的数据同步配置拓扑结构。可以在远程服务器之间或者仅在一个单一的服务器上进行复制。可以选择进行单向复制，或者选择多向复制。其中，多向复制可以是双向的（对于管理备份系统十分有用），或者是对等复制（对于交易系统上的数据同步很有帮助）。

回页首

InfoSphere Change Data Capture

InfoSphere Change Data Capture V6.5（以下简称 CDC）是用来实现跨企业系统的（准）实时数据捕获和交付工具，能够在不同的业务系统之间（准）实时分发数据，为构建企业信息单一视图提供技术支撑，让业务人员可以及时了解企业内外的情况，从而改进业务流程，加速服务响应和捕捉转瞬即逝的市场机会。CDC 主要用来支持企业进行数据整合、系统业务分离（复制数据库到多个数据库，实现业务分离和工作负载均衡）、数据共享、信息采集和热备容灾等功能，其体系结构图如图 8 所示：

图 8. CDC 体系结构

CDC 具有以下功能：

基于日志的变更捕获数据变更，高性能

CDC 支持大数据量的复制环境，基于日志的变化进行数据捕获的方式，避免了对数据库的查询访问（也不需要对源数据库进行修改）从而减少了对业务系统（源数据库）的性能影响。CDC 只复制数据变更而不是表中所有数据，所以转移的数据更少，可以显著的提高可伸缩。

保证数据完整性

通过在源库和目标库直接同步变更信息，从而保证了数据的完整性。根据业务需要，还可以记录对系统的所有变更而不仅仅是更改后的最终结果，通过记录所有的增删改操作，可以满足审计和合规性需求。

简单易用，无需编程

CDC 提供了完整的图形化的用户界面来实现复制环境的配置和监控，无需编程。配置、管理和监控都是基于 Java 的统一图形界面，可以在同一屏幕内管理数据整合流程，自动映射，拖拽实现转换，集成事件日志、报警和统计报告等。复制过程中支持进行简单数据转换，比如数据的 lookup、数据计算、字段合并和拆分等功能。

跨平台，支持多种主流数据库，支持与平面文件集成

支持跨平台数据复制，支持 IBM System Z、System P、System I Series，支持 Intel/AMD 芯片，支持 HP RISC、HP Itanium 和 Sun SPARC 平台。支持 Z/OS、AIX、IBM i OS、Redhat、Suse、HP-UX、SUN Solaris、MS Windows 等操作系统平台。数据源支持 DB2 Z/OS、DB2 LUW、DB2 i、Informix、Oracle、Sybase 和 MS SQL Server 等主流数据库。除关系型数据库外，还支持文件、XML 和 ESB 等，有助于实现跨系统整合数据。

扩展能力强

通过和其它产品集成，CDC 可以提供更强大的功能，比如和 Federation Server 一起可以实现 ODBC 数据源之间的数据复制功能，和 DataStage 集成可以实现在数据复制的过程中对数据进行转换、清洗等。另外，在复制的不同阶段都有 User Exit 供扩展。

支持与消息队列集成

支持 MQ Series、JMS、TIBCO、WebMethods、BEA 等多种中间件平台。

准实时的捕捉数据变化

CDC 可以（准）实时地连续捕捉数据变化，支持快速响应业务的变化。和传统 ETL 工具相比，CDC 不需要批处理时间窗，可以在线连续地捕捉、转换和应用数据变更，不用为了装载更新数据而暂停系统。

支持多种复制方式

CDC 支持全量数据复制，持续增量复制，阶段性数据复制等，在复制过程中，支持一对一、一对多、多对一、双向、级联等多种方式复制。

回页首

结束语

本文详细介绍了大数据治理统一流程参考模型第四步“定义业务问题”、第五步“获得主管支持”、第六步“执行成熟度评估”、第七步“构建路线图”、第八步“建立组织蓝图”和第九步“了解数据”等内容，并简单介绍了 IBM 信息服务器中的 InfoSphere Information Analyze、InfoSphere Federation Server、InfoSphere Replication Server 和 InfoSphere Change Data Capture 等。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型第十步“定义度量值”、第十一步“主数据监管”以及 IBM 在主数据管理方面的产品介绍如 InfoSphere MDM Collaboration Server、InfoSphere MDM Standard Edition 和 InfoSphere MDM Advance Edition 等。

回页首