大数据治理——为业务提供持续的、可度量的价值

概述

面对我们身边每时每刻迅速增长的庞大数据，因为其数量大、速度快、种类多和准确性的特征，如何更好地利用大数据创造出有意义的价值，一直是我们探索的重要话题。而在这之前，就需要用科学正确的方法策略对大数据进行治理。大数据治理是指制定与大数据有关的数据优化、隐私保护与数据变现的政策，是传统信息治理的延续和扩展，也是大数据分析的基础，还是连接大数据科学和应用的桥梁，因此大数据治理是大数据再创高峰的“必修课”。下面我们将与您分享新鲜出炉的大数据治理方案。

大数据治理系列

本系列共分为七个部分，围绕大数据治理统一流程参考模型，并结合实际业务问题和IBM相应的产品解决方案展开叙述。

第一部分：大数据治理统一流程模型概述和明确元数据管理策略

为了更好地帮助企业进行大数据治理，笔者在IBM数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验，整理出了大数据治理统一流程参考模型。本文主要介绍了大数据治理的基本概念，以及结合图文并茂的方式讲解了大数据治理统一流程参考模型的前两步：“明确元数据管理策略”和“元数据集成体系结构”内容。

大数据治理概述

（狭义）大数据是指无法使用传统流程或工具在合理的时间和成本内处理或分析的信息，这些信息将用来帮助企业更智慧地经营和决策。而广义的大数据更是指企业需要处理的海量数据，包括传统数据以及狭义的大数据。（广义）大数据可以分为五个类型：Web和社交媒体数据、机器对机器（M2M）数据、海量交易数据、生物计量学数据和人工生成的数据。

● Web和社交媒体数据：比如各种微博、博客、社交网站、购物网站中的数据和内容。

● M2M数据：也就是机器对机器的数据，比如RFID数据、GPS数据、智能仪表、监控记录数据以及其他各种传感器、监控器的数据。

● 海量交易数据：是各种海量的交易记录以及交易相关的半结构化和非结构化数据，比如电信行业的CDR、3G上网记录等，金融行业的网上交易记录、corebanking记录、理财记录等，保险行业的各种理赔等。

● 生物计量学数据：是指和人体识别相关的生物识别信息，如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。

● 人工生成的数据：比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。

在各行各业中，随处可见因数量、速度、种类和准确性结合带来的大数据问题，为了更好地利用大数据，大数据治理逐渐提上日程。在传统系统中，数据需要先存储到关系型数据库/数据仓库后再进行各种查询和分析，这些数据我们称之为静态数据。而在大数据时代，除了静态数据以外，还有很多数据对实时性要求非常高，需要在采集数据时就进行相应的处理，处理结果存入到关系型数据库/数据仓库、MPP数据库、Hadoop平台、各种NoSQL数据库等，这些数据我们称之为动态数据。比如高铁机车的关键零部件上装有成百上千的传感器，每时每刻都在生成设备状态信息，企业需要实时收集这些数据并进行分析，当发现设备可能出现问题时及时告警。再比如在电信行业，基于用户通信行为的精准营销、位置营销等，都会实时的采集用户数据并根据业务模型进行相应的营销活动。

大数据治理的核心是为业务提供持续的、可度量的价值。大数据治理人员需要定期与企业高层管理人员进行沟通，保证大数据治理计划可以持续获得支持和帮助。相信随着时间的推移，大数据将成为主流，企业可以从海量的数据中获得更多的价值，而大数据治理的范围和严格程度也将逐步上升。为了更好地帮助企业进行大数据治理，笔者在IBM数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验，整理了大数据治理统一流程参考模型，整个参考模型分为必选步骤和可选步骤两部分。

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

如图1所示，大数据治理统一流程参考模型必要步骤分为两个方向：一条子线是在制定元数据管理策略和确立体系结构的基础上实施全面的元数据管理，另一条子线是在定义业务问题、执行成熟度评估的基础上定义数据治理路线图以及定义数值治理相关的度量值。在11个必要步骤的基础上，企业可以在7个可选步骤中选择一个或多个途径进行特定领域的数据治理，可选步骤为：主数据监管、（狭义）大数据监管、信息单一视图监管、运营分析监管、预测分析监管、管理安全与隐私以及监管信息生命周期。企业需要定期对大数据治理统一流程进行度量并将结果发送给主管级发起人。

图1大数据治理统一流程参考模型

第一步：明确元数据管理策略

在最开始的时候，元数据（MetaData）是指描述数据的数据，通常由信息结构的描述组成，随着技术的发展元数据内涵有了非常大的扩展，比如UML模型、数据交易规则、用Java，.NET，C++等编写的APIs、业务流程和工作流模型、产品配置描述和调优参数以及各种业务规则、术语和定义等[1]。在大数据时代，元数据还应该包括对各种新数据类型的描述，如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。元数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据主要包括业务规则、定义、术语、术语表、运算法则和系统使用业务语言等，主要使用者是业务用户。技术元数据主要用来定义信息供应链（Information Supply Chain，ISC）各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖性等，以及存储过程、函数、序列等各种对象。操作元数据是指应用程序运行信息，比如其频率、记录数以及各个组件的分析和其它统计信息等。

从整个企业层面来说，各种工具软件和应用程序越来越复杂，相互依存度逐年增加，相应的追踪整个信息供应链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中，元数据管理也逐渐从局部存储和管理转向共享。从总量上来看，整个企业的元数据越来越多，光现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业需要处理的数据类型越来越多。为了企业更高效地运转，企业需要明确元数据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据管理，并有步骤的提升其元数据管理成熟度。

为了实现大数据治理，构建智慧的分析洞察，企业需要实现贯穿整个企业的元数据集成，建立完整且一致的元数据管理策略，该策略不仅仅针对某个数据仓库项目、业务分析项目、某个大数据项目或某个应用单独制定一个管理策略，而是针对整个企业构建完整的管理策略。元数据管理策略也不是技术标准或某个软件工具可以取代的，无论软件工具功能多强大都不能完全替代一个完整一致的元数据管理策略，反而在定义元数据集成体系结构以及选购元数据管理工具之前需要定义元数据管理策略。

元数据管理策略需要明确企业元数据管理的愿景、目标、需求、约束和策略等，依据企业自身当前以及未来的需要确定要实现的元数据管理成熟度以及实现目标成熟度的路线图，完成基础本体、领域本体、任务本体和应用本体的构建，确定元数据管理的安全策略、版本控制、元数据订阅推送等。企业需要对业务术语、技术术语中的敏感数据进行标记和分类，制定相应的数据隐私保护政策，确保企业在隐私保护方面符合当地隐私方面的法律法规，如果企业有跨国数据交换、元数据交换的需求，也要遵循涉及国家的法律法规要求。企业需要保证每个元数据元素在信息供应链中每个组件中语义上保持一致，也就是语义等效（semantic equivalence）。语义等效可以强也可以弱，在一个元数据集成方案中，语义等效（平均）越强则整个方案的效率越高。语义等效的强弱程度直接影响元数据的共享和重用。

本体（人工智能和计算机科学）

本体（Ontology）源自哲学本体论，而哲学本体论则是源自哲学中“形而上学”分支。本体有时也被翻译成本体论，在人工智能和计算机科学领域本体最早源于上世纪70年代中期，随着人工智能的发展人们发现知识的获取是构建强大人工智能系统的关键，于是开始将新的本体创建为计算机模型从而实现特定类型的自动化推理。之后到了上世纪80年代，人工智能领域开始使用本体表示模型化时间的一种理论以及知识系统的一种组件，认为本体（人工智能）是一种应用哲学。

最早的本体（人工智能和计算机科学）定义是Neches等人在1991给出的：“一个本体定义了组成主题领域的词汇的基本术语和关系，以及用于组合术语和关系以及定义词汇外延的规则”。而第一次被业界广泛接受的本体定义出自Tom Gruber，其在1993年提出：“本体是概念化的显式的表示（规格说明）”。Borst 在1997年对Tom Gruber的本体定义做了进一步的扩展，认为：“本体是共享的、概念化的一个形式的规范说明”。在前人的基础上，Stude在1998年进一步扩展了本体的定义，这也是今天被广泛接受的一个定义：“本体是共享概念模型的明确形式化规范说明”。本体提供一个共享词汇表，可以用来对一个领域建模，具体包括那些存在的对象或概念的类型、以及他们的属性和关系[2]。一个简单的本体示例发票概念及其相互关系所构成的语义网络如图2所示：

图2简单本体（发票）示例

随着时间的推移和技术的发展，本体从最开始的人工智能领域逐渐扩展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。与哲学本体论类似，本体（人工智能和计算机科学）依赖某种类别体系来表达实体、概念、事件及其属性和关系。本体的核心是知识共享和重用，通过减少特定领域内概念或术语上的分歧，使不同的用户之间可以顺畅的沟通和交流并保持语义等效性，同时让不同的工具软件和应用系统之间实现互操作。

根据研究层次可以将本体的种类划分为“顶级本体”（top-level ontology）、应用本体（application ontology）、领域本体（domain ontology）和任务本体（task ontology），各个种类之间的层次关系如图3所示。

图3本体层次关系

● 顶级本体，也被称为上层本体（upper ontology）或基础本体（foundation ontology），是指独立于具体的问题或领域，在所有领域都适用的共同对象或概念所构成的模型，主要用来描述高级别且通用的概念以及概念之间的关系。

● 领域本体是指对某个特定的领域建模，显式的实现对领域的定义，确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解。领域本体所表达的是适合自己领域的术语的特定含义，缺乏兼容性，因而在其他领域往往不适用。在同一领域内，由于文化背景、语言差异、受教育程度或意识形态的差异，也可能会出现不同的本体。很多时候，随着依赖领域本体系统的扩展，需要将不同的领域本体合并为更通用的规范说明，对并非基于同一顶级本体所构建的本体进行合并是一项非常具有挑战的任务，很多时候需要靠手工来完成，相反，对那些基于同一顶级本体构建的领域本体可以实现自动化的合并。

● 任务本体是针对任务元素及其之间关系的规范说明或详细说明，用来解释任务存在的条件以及可以被用在哪些领域或环境中。是一个通用术语的集合用来描述关于任务的定义和概念等。

● 应用本体：描述依赖于特定领域和任务的概念及概念之间的关系，是用于特定应用或用途的本体，其范畴可以通过可测试的用例来指定。

从详细程度上来分，本体又可以分为参考本体（reference ontologies）和共享本体（share ontologies），参考本体的详细程度高，而共享本体的详细程度低。

本体（哲学）

哲学中的本体（ontology）也被称为存在论，源自哲学中“形而上学”分支，主要探讨存在的本质，也就是存在的存在。英文ontology实际上就是来源于希腊文“ον”（存在）和“λόγος”（学科）的组合。本体是由早期希腊哲学在公元前6世纪到公元前4世纪提出的“始基”延伸出来的。始基（Principle，又称本原）最早由泰勒斯（米利都学派）最早提出来，认为万物由水而生，其学生阿那克西曼德认为万物由一种简单的原质组成，该原质不是水[3]。而毕达哥拉斯（学派）认为“万物都是数”，数不仅被看作万物的本原，而且被看作万物的原型、世界的本体。后来巴门尼德（爱利亚学派）提出了“存在”的概念，认为存在才是唯一真正存在的真理，其创造了一种形而上学论证方式，之后的哲学一直到近时期为止，都从巴门尼德处接受了其“实体的不可毁灭性”。苏格拉底继承了巴门尼德的存在概念，主张“真正的善”并完善了巴门尼德弟子芝诺的辩证法，其学生柏拉图提出了“理念论”，认为只要若干个个体拥有一个共同的名字，它们就有一个共同的理念或形式。亚里士多德（柏拉图学生）总结了先哲们的思想，完成了《形而上学》，并将本体总结为：对世界上客观存在事物的系统的描述，即存在论，也就是最形而上学的知识。形而上学不是指孤立、静止之类的意思，而是指超越具体形态的抽象意思，是关于物质世界最普遍的、最一般的、最不具体的规律的学问。

第二步：元数据集成体系结构

在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。各个企业的元数据管理策略和元数据管理成熟度差别较大，因此元数据集成体系结构也多种多样。大体上元数据集成体系结构可以分为点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM（Common Warehouse Meta Model，公共仓库元模型）模型驱动的点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构等。

针对信息供应链中不同的组件，为了实现跨组件的元数据交换和集成，最开始人们采用点对点的方式进行，也就是每一对组件之间通过一个独立的元数据桥（metadata bridge）进行元数据交换，桥一般是双向的能够理解两个方向的元数据映射[4]。点对点的元数据集成体系结构帮助用户实现了跨企业的元数据集成和元数据交换，对提升信息化水平提供了巨大帮助。这种体系结构在应用过程中，也暴露了很多问题，比如元数据桥的构建工作量和耗时都非常大，对中间件厂商、应用厂商、集成商和用户来说都是一个巨大的挑战，而且构建元数据桥还必须具有所有者的元数据模型和接口的详细信息。构建完成的桥很多时候无法在构建其他元数据桥时进行重用，因此开发和维护费用大幅度增加，用户投资回报率（ROI）不高。以动态数据仓库为例，其点对点的元数据集成体系结构具体如图4所示，信息供应链各组件之间的空心箭头表示全部的数据流，实心箭头表示不同的元数据桥和与之关联的元数据流。

图4点对点的元数据集成体系结构

通过使用中央元数据存储库（central metadata repository）取代各个工具软件和应用程序之间的点对点连接方式，改成中央元数据存储库与各个工具软件和应用程序实现元数据交换的访问层（也是一种桥），可以有效降低总成本，减少建立点对点元数据桥的工作，提高投资回报率。信息供应链各组件可以从存储库访问元数据，不必与其他产品进行点对点交互。这种使用中央元数据存储库方式进行元数据集成的方式就是中央辐射式元数据体系结构（hub-and-spoke metadata architecture），具体如图5所示。由于特定的元数据存储库是围绕其自身的元模型、接口和交付服务建立的，所以仍需要建立元数据桥实现与ISC各组件的互相访问。

图5中央辐射式元数据体系结构

采用模型驱动的元数据集成方法（比如使用CWM）可以有效降低元数据集成的成本和复杂度，无论点对点元数据集成体系结构还是中央辐射式元数据集成体系结构都可以因此受益。在点对点体系结构中，通过使用基于模型的方法可以不必在每一对需要集成的产品之间构建元数据桥，每个产品只需要提供一个适配器（adapter）即可实现各个产品之间的元数据交换，适配器既了解公共的元模型也了解本产品元模型的内部实现。如图6所示，基于CWM模型驱动点对点元数据集成体系结构使用通用元模型，不再需要在各个产品间建立元数据桥，在各个产品之间通过适配器实现了语义等价性。

图6基于CWM模型驱动的点对点元数据集成体系结构

如图7所示，在基于模型驱动（比如CWM）的中央辐射式元数据体系结构中，中央存储库包含公共元模型和整个领域（domain）用到的该元模型的各个实例（模型）、存储库自身元模型及其实例、理解元模型（公共元模型和自身元模型）的适配器层，当然存储库也可以直接实现公共元模型的某些内部表示。

图7基于CWM模型驱动的中央存储库元数据集成体系结构

如图8所示，这种体系架构是基于CWM模型驱动的中央存储库元数据集成体系结构的一个变种，两个中央辐射式的拓扑结构通过各自的元数据存储库连接起来，也被称为分布式（Distributed）或联邦（Federated）体系结构。两个元数据存储库之间通过元数据桥连接，两个存储库使用相同的元模型和接口，也可以使用不同的元模型和接口。建立分布式元数据集成体系结构的原因有很多种，比如企业基于多个区域单独部署自己的应用，每个区域有自己的数据中心。

图8分布式（联邦式）元数据集成体系结构

如图9所示，这种体系结构是分布式体系结构的变体，根存储库实现了元模型的公共部分（横跨整个企业），叶子存储库实现了一个或多个特定的公共元模型子集，并只保存这些自己所对应的元数据实例。特定客户可以主要访问其感兴趣的元数据所在的叶子存储库，也可以访问其它叶子存储库和根存储库。这种体系结构被称为层次或星型拓扑结构。

图9层次或星型元数据集成体系结构

结束语

本文详细介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和第二步“元数据集成体系结构”等内容。在第一步“明确元数据管理策略”中讲述了元数据的基本概念以及本体在人工智能/计算机科学和哲学中的含义。在第二步“元数据集成体系结构”讲述了元数据集成体系结构的六种示例，分别为：点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM模型驱动的点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构。在本系列文章的下一部分将继续介绍大数据治理统一流程参考模型第二步“元数据集成体系结构”，具体包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、OMG的模型驱动体系结构（ModelDrivenArchitecture，MDA）。

参考文献

[1] David Frankel Consulting,”Using Mode lDriven Architecture™to Manage Metadata”,P3;

[2] Fredrik Arvidssonand Annika Flycht-Eriksson,2008,OntologiesI,”Anontology provide a share dvocabulary,which can be used to modela domain,that is,the type of objects and/or concepts that exist,and their properties and relations”;

[3] 更多内容请参考:[专著]/(英)伯特兰.罗素/著孙绍武/主编<<西方哲学史>>;

[4] John Poole,Dan Chang,Douglas Tolbertand David Mellor,2002,Common Warehouse Metamodel,p18-32,p180-202;

[5] 本系列文章参考了Sunil Soares编写的《The IBM Data Governance Unified Process》和《Big data Governance》书中内容｡

第二部分：元数据集成体系结构

在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。元数据集成体系结构涉及到多个概念，如元模型、元-元模型、公共仓库元模型（CWM）等，本部分将继续介绍大数据治理统一流程参考模型第二步“元数据集成体系结构”的相关内容。

在本系列的第一篇文章中，我们主要介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和第二步“元数据集成体系结构”的六种示例等内容。大数据治理统一流程参考模型的第二步是“元数据集成体系结构”，具体包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、OMG的模型驱动体系结构（Model Driven Architecture，MDA）本文将对元数据集成体系结构包含的各种模型展开叙述。

大数据治理统一流程参考模型，第二步：元数据集成体系结构

元模型（Meta model）

模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型（Meta model）也就是模型的模型（或者元-元数据），是用来描述元数据的模型。

下面基于关系型表实体-关系（ER）模型举例说明什么是元模型。如图1所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必须有一个名字（字符串），一个表可以有1到多个列，每个列必须有一个名字（字符串）和数据类型（字符串）：

图1简单关系型表元模型

如果要创建一个关系型表模型，基于该表元模型创建一个实例即可，比如创建一个常见的雇员表Employees表模型，具体如图2所示，Employees表包含6个列，分别是编号、姓、名字、部门编号、经理编号和职位编号。

图2Employees表实例

比如在DB2中创建employees表，可以很容易的从employees表模型中得到相应的DDL语句，执行DDL语句时DB2会生成描述employees表的内部元数据并存储在目录（DB2内部的元数据存储库）中。

清单1 在DB2中创建employees表示例

Create table employees (

Id integer not null，

First_name String not null，

Last_name String not null，

Depart_ID Integer not null，

Manager_ID Integer not null，

Job_ID Integer not null

)

同样基于图1简单关系型表元模型创建另一个实例department表模型。department表包含2个列，分别是编号和部门名称，具体如图3所示。由于department表模型和employees表模型都是基于相同的公共元模型，其它工具和应用程序软件（了解关系型表的公共元模型）可以很容易理解department表和employees表，因为它们都是同一个元模型的实例。其它工具或应用程序通过调用导入映射（import mapping）将该department表模型或employees表模型翻译成自己内部的元数据实例。同样，也可以将该软件内部元数据翻译成一个与平台无关的形式化模型，也就是导出映射（export mapping），以便其他软件使用其专有的元数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结构[1]。

图3 department表实例

元-元模型（Meta-meta model）

元-元模型就是元模型的模型，有时也被称为本体（ontology），是模型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。

元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据（模型）则是一个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据）则是元数据（或者称为模型）的实例。元数据层次结构具体如表1所示，共分为4层，最高层L3是元-元模型，之下是L2元模型和L1模型/元数据，最底层是L0用户对象/用户数据：

表1 元数据层次结构

公共仓库元模型（CWM）概述

公共仓库元模型（Common Warehouse MetaModel，CWM）是被对象管理组织OMG（Object Management Group）采纳的数据仓库和业务分析领域元数据交换开放式行业标准，在数据仓库和业务分析领域为元数据定义公共的元模型和基于XML的元数据交换（XMI）。CWM作为一个标准的接口，可以帮助分布式、异构环境中的数据仓库工具，数据仓库平台和数据仓库元数据存储库之间轻松实现数据仓库和业务分析元数据交换。CWM提供一个框架为数据源、数据目标、转换、分析、流程和操作等创建和管理元数据，并提供元数据使用的世系信息[2]。

CWM是一个基于模型驱动方法的完整地描述数据仓库和业务分析领域的元模型，提供构建元数据所需的语法和语义，由若干个不相同又紧密相关的子元模型组成。CWM模型的目的是最大限度的重用对象模型（Object Model，UML的一个子集），并在可能的地方共享通用模型结构。如图4所示，CWM元模型使用包（package）和层次来简化管理的复杂度并便于理解，共包含21个单独的包，这些包被分为5个层次。对象模型层包含定义基本元模型的概念、关系和约束的包，其它CWM包都需要用到这些定义，对象模型层的包构成了其它CWM包所需要的基本元模型服务的全部集合。对象模型层主要包括核心包（Core package）、行为包（Behavioral package）、关系包（Relationships package）和实例包（Instance package）。

● 数据源层（Data Resources）：主要描述CWM元数据交换中既可作为源又可以作为目标的数据源的结构，本层含有的元模型主要描述面向对象的数据库和应用、关系型数据库、面向记录的数据源（如文件、记录数据库管理系统等）、多维数据库和XML数据源等。对于面向对象数据源，CWM一般情况下重用基本的对象模型（位于对象模型层），如果该数据源具有对象模型层无法处理的一些特征和功能时，可以通过定义一个扩展包来解决。

● 数据分析层（Data Analysis）：本层含有的元模型主要描述数据转换、在线分析处理OLAP、数据挖掘、信息可视化和业务术语等。

● 仓库管理层（Warehouse Management）：本层含有的元模型主要描述数据仓库处理和数据仓库操作。

图4 CWM1.1元模型

CWM1.1是在2003年3月发布的，与之相关的OMG组织规范还有MOF、UML和XMI。CWM使用统一建模语言（UML）定义公共元数据的模型（CWM元模型），使用可扩展标记语言（XML）生成CWM元数据交换规范（也就是XML元数据交换，XMI），使用CORBA接口定义语言（IDL）为访问CWM元数据生成编程语言API的规范（依赖MOF到IDL的映射）。

UML是一种规范化、可视化、描述明确、结构化和文档化的定义分布式对象系统的图形化语言。1996年，业内三种最杰出的面向对象建模语言：Grady Booch的Booch方法、Ivar Jacobson的面向对象软件工程（OOSE）和Jim Rumbaugh的对象建模技术（OMT）被统一起来发布，也就是UML0.9。2011年，UML2.4.1发布。CWM依赖于UML规范的前三个部分，即UML语义、UML符号向导和对象约束语言规范。UML语义定义UML元模型的语义，UML元模型是层次结构并以包为单位进行组织，每个包按照抽象语言（使用类图）、结构良好规则（采用OCL）和语义（采用英语）来定义。UML符号指定表达UML元模型语义的图形语法（例如类图）。对象约束语言规范定义对象约束语言（OCL）的句法、语义和语法，OCL是一种表述约束的形式化语言[3]。

● 构造块和结构良好规则：UML提供了组成构造块和结构良好规则的面向对象建模语言，基本的构造块包括模型元素（如类、对象、接口、组件、用例等）、关系（如关联、泛化、依赖等）和图（如类图、对象图、用例图等）等。

● UML可以为一个系统进行不同方面的建模，比如结构建模（又包括使用类图和对象图的静态结构建模、使用组件图和部署图实现建模）、用例建模和行为建模等。元数据建模只需要静态结构建模，静态结构的核心元素是类、对象、属性和操作。

● UML用包来将模型元素组织成语义上相关联的分组，每个包拥有其自己的模型元素，每个模型元素不能同时被多个包拥有。

UML在CWM中主要作为三种角色出现[4]：

1、UML作为和MOF等价的元-元模型。UML，或者部分对应MOF模型、UML符号和OCL的UML分别被用作建模语言、图形符号和约束语言，用来定义和表示CWM。

2、UML作为基础元模型。对象模型层（ObjectModel）与UML关系密切，是UML的一个子集。

3、UML用来作为面向对象元模型。

元对象框架（Meta Object Framework，MOF，本文以2.4.1版本为例）是一个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的分布式对象集成框架。此框架支持各种类型的元数据，还可以根据需求添加新类型的元数据。MOF包括MOF模型（定义建立元模型的建模元素和使用规则）、MOF反射接口（允许程序在不使用元模型指定接口时对元数据进行各种操作）和MOF到IDL的映射（定义MOF模型定义的元模型到CORBAIDL之间的标准映射）。MOF模型是以UML的概念和结构为基础，尤其是以UML的静态结构模型和模型管理为基础。MOF模型没有定义自己的图形符号和约束语言，而是采用UML的图形符号和OCL来实现。MOF模型也是层次结构，并以包为单位进行组织。

MOF支持各种类型的元数据，采用四层元数据体系结构（也就是OMG元数据体系结构）[5]，具体如表2所示，该体系架构将元数据（M1）视同为数据（M0），并对之进行形式化建模（即元模型，M2）。元模型（M2）使用元-元模型（M3）所提供的元建模结构来表示。表2表明MOF模型（元-元模型）、UML元模型、用户模型和用户对象/数据之间的关系。

表2 MOF四层元数据体系结构

XML元数据交换（XMI）是在工具软件、应用程序之间进行元数据交换的XML语言，整合了UML、MOF和XML三种技术，允许MOF元数据（即遵从MOF或基于MOF的元模型的元数据）以流或文件的形式按照XML的标准格式进行交换。XMI是OMG在元数据交换方面的标准之一，同时也是W3C认可的标准。本质上，XMI是W3C的XML和MOF之间，以及XML文档和MOF元数据之间的一对平行映射。2011年8月，XML发布了2.4.1。

CWM发展史

其实早在上世纪80年代末90年代初，很多企业就尝试使用一种元模型实现元数据集成以整合分布于各个业务竖井中的元数据，但最终失败了，因为很多的利益相关者各自拥有不同的观点，且需要不同的模型结构。1997年，OMG将UML采纳为标准，为CWM标准制定打下了第一个基础。同样在1997年，MOF被OMG采纳为标准，为CWM的产生打下了第二个基础。1999年初，OMG采纳XMI作为标准，为CWM的出现打下了第三个基础。1998年5月，IBM、ORACLE和Unisys向OMG提交了公共仓库元数据交换（Common Warehouse Metadata Interchange，CWMI）征求意见稿（RFP），同年9月OMG发布了该征求意见稿，经过8个公司（IBM、Unisys、Oracle、Hyperion、UBS、NCR、Genesis和Dimension EDI）2年半的努力和协作，OMG于2001年4月正式采纳CWM为标准。

在CWM发展的同时，其他一些元数据标准的制定也在进行中。最早在1993年，电子信息组织就发布了计算机辅助工程数据交换格式（CASE Data Interchange Format，CDIF）并得到了一定的认可。1995年10月，元数据联盟（Meta Data Coalition，MDC）成立，并与1996年4月发布了元数据交换规范1.0（Meta Data Interchange Specification，MDIS），与CWM相比，MDIS涉及的范畴少很多，且其规范和交换语言都是自身独有的。此时微软也在和其他一些合作者一起开发开放信息模型（Open Information Model，OIM），该模型于1996年10月成形，采用UML作为其规范语言。1998年11月，微软加入MDC并提交OIM标准，1999年7月MDC发布了OIMv1.0版本，由此业内面临着两种元数据集成规范的竞争局面，之后考虑到业内对CWM的认可，MDC于2000年9月决定终止其OIM后续工作，将其元数据标准归入到OMG中，从此CWM影响力和范围持续扩大并得到了业内的统一认可。

OMG的模型驱动体系结构（Model Driven Architecture，MDA）

OMG组织成立不久制定了对象管理体系结构（Object Management Architecture，OMA）参考模型，描述了OMG规范所遵循的概念化的基础结构。OMA是由对象请求代理（Object Request Broker，ORB）、对象服务、公共设施、域接口和应用接口等几个部分组成，其核心是对象请求代理（ORB）。对象请求代理（ORB）是公共对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）的核心组件，提供了识别和定位对象、处理连接管理、传送数据和请求通信所需的框架结构。OMA和CORBA被定位为软件框架，用来指导基于OMG规范的技术开发。

从1995年开始，OMG开始非正式的采用针对特定行业（“领域”，Domain）的技术规范，为了保持扩张重点，OMG在2001年正式采用第二个框架，模型驱动体系架构（Model Driven Architecture，MDA）。与OMA和CORBA不一样，MDA不是部署分布式系统的框架，而是在软件开发中基于模型驱动的方法。为了实现MDA，OMG随后制定了一系列标准如UML、MOF、XMI和CWM等，解决了MDA的模型建立、扩展、交换等几个方面的问题。模型驱动体系结构源自众所周知的和长期建立的思想：“将系统操作规范从系统利用底层平台能力的细节中分离出来”。MDA提供了一种方法（基于相关工具）来规范化一个平台独立的系统，为系统选择一个特定的实现平台，并把系统规范转换到特定的实现平台。MDA的首要三个目标是：可移植性、互操作性和可重用性。MDA三个视角（viewpoint）[6]分别是：

● 计算无关视角（Computation Independent Viewpoint）：侧重系统环境和系统需求；系统结构和流程细节被隐藏或尚未确定。其对应的是计算无关模型（Computation Independent Model，CIM）。

● 平台无关视角（Platform Independent Viewpoint）：侧重系统的操作，同时隐藏用于特定平台的必要细节。其对应的是平台无关模型（Platform Independent Model，PIM），PIM是抽出技术和具体工程细节之后的模型。

● 平台相关视角（Platform Specific Viewpoint）：结合平台无关系视角和系统所使用的特定平台细节。其对应的是平台相关模型（Platform Specific Viewpoint Model，PSM），PSM是包含技术和具体工程细节的模型。

OMG模型驱动体系结构如图5所示：

图5 OMG模型驱动体系架构

CWM元模型、规范以及生成的产品同MDA非常契合，从技术平台角度来说，所有的平台相关模型（CWMXML、CWMIDL和CWM Java等）都是自动地从平台无关模型（CWM元模型和规范）中产生的；从产品平台角度来说，平台相关模型（比如DB2、ORACLE、SQLSERVER等）都是人工从平台无关模型（CWM元模型和规范）中构造出来的。

结束语

本文详细介绍了大数据治理统一流程参考模型第二步“元数据集成体系结构”的后续内容，主要包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、对象管理组织OMG的模型驱动体系结构（Model Driven Architecture，MDA）。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型的第三步：“实施元数据管理”，讲述在大数据时代如何实施元数据管理，如何使用元数据管理成熟度模型，以及IBM在元数据管理方面的产品：业务元数据管理工具IBM Info Sphere Business Glossary、业务词汇表小工具Info Sphere Business Glossary Anywhere和技术元数据管理工具Info Sphere Metadata Workbench。

参考文献

[6] 更多信息请参考:OMG Model Driven Architecture :http://www.omg.org/mda/ ;

[7] OMG,Common Warehouse Metamodel(CWM)Specification v1.1,P44 ;

[8] John Poole,Dan Chang,Douglas Tolbert and David Mellor,2002,Common Warehouse Metamodel,p48-53,p58-63 ;

[9] OMG,Common Warehouse Metamodel(CWM)Specification v1.1,P45 ;

[10] David Frankel Consulting,”Using Model Driven Architecture™ to Manage Metadata”,P46 ;

[11] OMG,2003,MDA Guide Version 1.0.1,p11-12,P15-16 ;

第三部分：实施元数据管理

了解了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。本部分主要介绍大数据治理统一流程参考模型第三步“实施元数据管理”，元数据管理成熟度模型、IBM元数据管理相关工具等内容。

第三步：实施元数据管理

在明确了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。比如可以使用 IBM InfoSphere Business Glossary 进行业务元数据的管理，使用 IBM InfoSphere Metadata Workbench 作为元数据管理统一工具并进行图形化的元数据分析。

大数据扩大了数据的容量、速度和多样性，给元数据管理带来了新的挑战。在构建关系型数据仓库、动态数据仓库和关系型数据中心时进行元数据管理，有助于保证数据被正确地使用、重用并满足各种规定。同样，对大数据来说，元数据管理过程中出现的任何错误，都会导致数据重复、数据质量差和无法访问关键信息等问题[1]。随着大数据技术在企业中的应用越来越广泛，企业需要在原有的元数据管理策略中增加大数据相关的内容。通常，大数据分析是受用例驱动的，企业可以通过梳理大数据用例的方式逐步完善大数据的元数据管理。

针对大数据的业务元数据，依旧可以通过构建基础本体、领域本体、任务本体和应用本体等的方式来实现。通过构建基础本体，实现对级别且通用的概念以及概念之间关系的描述；通过构建领域本体，实现对于领域的定义，并确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解；通过构建任务本体，实现任务元素及其之间关系的规范说明或详细说明；通过构建应用本体，实现对特定应用的概念描述，其是依赖于特定领域和任务的。这样就通过构建各种本体，在整个企业范围提供一个完整的共享词汇表，保证每个元数据元素在信息供应链中每个组件的语义上保持一致，实现是语义等效。

为了实现信息供应链中各个组件元数据的交互和集成，大数据平台的元数据集成体系结构依然可以采用基于模型驱动的中央辐射式元数据体系结构。对大数据平台中的结构化数据的元数据管理可以遵循公共仓库元模型（CWM）构建元数据体系结构，以便方便的实现各个组件间元数据的交互；对大数据平台中的半结构化和非结构化数据的元数据管理，因为业内还没有通用的公共元模型，企业可以尝试采用基于自定义模型驱动的方式构建中央辐射式元数据体系结构。

简单来说，企业可以尝试以下步骤进行大数据的元数据管理：

1、考虑到企业可以获取数据的容量和多样性，应该创建一个体现关键大数据业务术语的业务定义词库（本体），该业务定义词库不仅仅包含结构化数据，还可以将半结构化和非结构化数据纳入其中。

2、及时跟进和理解各种大数据技术中的元数据，提供对其连续、及时地支持，比如 MPP 数据库、流计算引擎、Apache Hadoop/企业级 Hadoop、NoSQL 数据库以及各种数据治理工具如审计/安全工具、信息生命周期管理工具等。

3、对业务术语中的敏感大数据进行标记和分类，并执行相应的大数据隐私政策。

4、将业务元数据和技术元数据进行链接，可以通过操作元数据（如流计算或 ETL 工具所生成的数据）监测大数据的流动；可以通过数据世系分析（血缘分析）在整个信息供应链中实现数据的正向追溯或逆向追溯，了解数据都经历了哪些变化，查看字段在信息供应链各组件间转换是否正确等；可以通过影响分析可以了解具体某个字段的变更会对信息供应链中其他组件中的字段造成哪些影响等。

5、扩展企业现有的元数据管理角色，以适应大数据治理的需要，比如可以扩充数据治理管理者、元数据管理者、数据主管、数据架构师以及数据科学家的职责，加入大数据治理的相关内容。

在实施元数据管理的过程中，可以参照元数据管理的成熟度模型确定企业当前元数据管理所在层次，并根据业务需要制定路线图实现元数据管理水平的提升。元数据管理成熟度模型具体如图1所示：

图1 元数据管理成熟度模型

根据元数据管理的成熟度，大体可以分成6个级别，具体如图1所示：

● L0:初始状态

元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用，其他人如果想获得该元数据需要找到相应的人进行沟通获取。

● L1:从属于业务系统

在这个阶段，随着各个业务系统自动化构建完成，相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中，技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中，元数据之间互通互联困难，如果需要获取其他系统的元数据，除了调阅各种文档外，对分散在各种中间件和业务系统中的技术元数据需要通过桥（bridge）的方式实现互通互联。

● L2：元数据统一存储

元数据依然在局部产生和获取，但会集中到中央存储库进行存储，业务元数据会手工录入到中央存储库中，技术元数据分散在文档中的部分也通过手工录入到中央存储库中，而散落在各个中间件和业务系统中的技术元数据则通过桥（bridge）的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建，使得元数据在整个企业层面可被感知和搜索，极大地方便了企业获取和查找元数据。缺点是，元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的事情，而同一件事情则使用了多个不同的名字，有些没有纳入业务系统管理的元数据则容易缺失。元数据没有有效的权限管理，局部元数据更改后也不自动通知其他人。

● L3:元数据集中管理

在L2的基础上做了改进，增强了元数据的集中控制，局部业务单元或开发小组如不事先通知其他人，将无法对元数据进行修改。局部元数据的修改完成后将被广播给其他人。和其他中间件和应用系统的交互，仍然通过桥（bridge）的方式进行，中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。

● L4：元模型驱动管理

在L3的基础上，通过构建元模型以及元元模型，优化各业务单元之间的各种冲突和各种副本，创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构，用以对业务术语归类。和其他中间件和应用系统的交换，通过基于CWM的适配器方式进行连接。

● L5:元数据管理自动化

在L5元数据管理是高度自动化的，当逻辑层次元数据变更时，会被传播到物理层次，同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流，以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统（元模型），他们之间的关系可以通过知识本体进行推断，因此各个应用系统之间的数据格式的映射自动产生。

IBM InfoSphere Information Server 元数据管理组件介绍

IBM InfoSphere Information Server 可以帮助组织从分散在其系统中的各种复杂信息中获取更多价值。它让组织能够整合分散的数据，在需要的地方和时间，按顺序和关联关系把可信的信息交付给特定的人员、应用程序和流程。InfoSphere Information Server 帮助业务人员和 IT 人员进行协作，理解来自任何来源的任何类型的信息的含义、结构和内容。它可以显著提高在整个企业内一致且安全地清理、转换和交付信息的生产力和效率，这样就可以以新的方式访问和使用信息，从而促进创新、提高运营效率并降低风险。InfoSphere Information Server 让客户可以跨分析、运营和事务环境应用一致的可重复的流程以解决企业级数据问题，不受数据量、复杂性或延迟的限制。InfoSphere Information Server 的每个核心产品可以作为集成平台的一部分使用，也可以作为单独的集成产品使用。

这些产品由一个全面的集成服务平台支持，提供全程数据集成、元数据管理、任何数据源与任何平台上的任何应用程序之间的连接以及通过并行处理技术无限制地扩展。可以按任何配置部署这些功能以支持事件驱动或按时间表执行的处理。还可以通过 InfoSphere Information Services Director 交付基础设施“随需”使用 InfoSphere Information Server 数据集成功能，从而补充 Enterprise Application Integration(EAI)、Business Process Management(BPM)、Enterprise Information Integration(EII) 和 Application Servers 集成基础设施。

InfoSphere Information Server 提供一个全面的模块化解决方案，可以根据业务需求和客户预算扩展。客户既可以部署完整的 InfoSphere Information Server 以处理整个企业数据集成生命周期，也可以使用单独的集成产品并根据需要添加其他组件。这种灵活的方式让客户既可以通过完整的 InfoSphere Information Server 实现全面集成，也可以通过购买一个或更多组件的许可证实现部分集成，以后可以添加其他组件以创建单一的集成解决方案。InfoSphere Information Server 可以提高从事数据集成项目的开发团队的生产力，改进这些开发团队之间以及开发人员与提出需求的业务用户之间的协作，促进项目团队内部和之间的重用，这些都会产生价值。为 SAP、Oracle、PeopleSoft、Siebel、SalesForce.com 等公司的企业应用程序预先构建的接口扩展了 InfoSphere Information Server 的功能范围。这些包帮助公司通过企业数据仓库或 ERP 厂商业务智能化解决方案集成来自这些企业应用程序的数据，构建分析解决方案。

InfoSphere Information Server 提供一套统一的可单独购买的产品模块 (即套件组件)，可以解决多种类型的业务问题。可以跨项目重用信息检验、访问和处理规则，这会提高一致性、增强对数据的管控并提高 IT 项目的效率。

IBM Information Server 让企业能够实现 5 种关键的集成功能：

连接任何数据或内容，无论它驻留在什么地方：大型机或分布式系统，内部或外部；

● 了解并分析信息，理解数据源的内容、质量和结构，从而在整个企业中集成和传播数据之前全面了解数据；

● 清理数据，确保数据的质量和一致性，让公司可以访问任何个人或业务实体及其关系的权威且一致的视图；

● 转换大量数据，从而有效且高效地从原数据源向目标提供丰富的有针对性的信息；

● 交付数据，让人员、流程和应用程序可以像访问单一资源一样访问和集成不同类型的数据和内容，无论信息驻留在什么地方。

● 这些功能的基础是一个共用的元数据和并行处理基础设施，它为整个平台提供支持和自动化。产品组合中的每个产品还可以连接许多数据和内容源，能够通过多种机制交付信息。另外，可以通过便于发布的共享服务在面向服务架构中使用这些功能。IBM Information Server 提供：

● 最广泛的访问信息源的能力；

● 最全面的集成功能，包括联合、ETL、内联转换、复制和事件发布；

● 在使用这些功能的方式方面的灵活性，包括支持面向服务架构、事件驱动的处理、按时间表执行的批处理以及 SQL 和 Java 等标准 API 平台的功能广度和灵活性让它能够解决许多类型的业务问题，满足许多类型的项目的需求。这可以增加重用的机会，加快项目的速度，提高信息的一致性，增强信息治理。

IBM InfoSphere Information Server 由以下组件组成:

● 元数据服务

● InfoSphere Business Glossary

● InfoSphere Business Glossary Anywhere

● InfoSphere Metadata Workbench

● InfoSphere Information Analyzer

● IBM Information Server FastTrack

● InfoSphere QualityStage

● InfoSphere DataStage

● InfoSphere Information Services Director

● InfoSphere Change Data Delivery for Information Server

● InfoSphere Federation Server

元数据服务是 IBM Information Server 所基于的平台的组成部分。可以通过使用元数据服务访问数据以及完成分析、建模、清理和转换等数据集成任务。IBM Information Server 的主要元数据服务组件是 InfoSphere Business Glossary、InfoSphere Metadata Server 以及 InfoSphere MetaBrokers 和桥。

InfoSphere Business Glossary 是一个基于 web 的交互式工具，可以帮助用户创建、管理和共享业务词汇表和分类系统。业务词汇和技术信息资产保持一致可以促进业务和 IT 群体的协作，有助于更有效地治理数据。另外，这个工具的数据专员功能可以提升责任感，支持数据治理策略。

InfoSphere Metadata Workbench 允许以基于 web 的方式查看 IBM InfoSphere Information Server 和其他第三方应用程序生成和使用的信息资产。这个浏览工具可以提高对最重要的信息的信任程度。另外，InfoSphere Metadata Workbench 向 IT 人员提供健壮的查询功能和全面且灵活的数据世系报告，让他们可以深入了解环境中使用的数据，还可以监视数据集成活动。在处理数据集成项目中的变动时，强大的影响分析工具可以帮助数据分析师和开发人员做出更好的决策。

InfoSphere Business Glossary 介绍

Business Glossary 是用来管理和展示企业业务元数据的基于 Web 的交互式工具，支持用户创建、管理和共享业务词汇表和分类系统（基于主题领域的层次结构）。业务词汇表（业务元数据）包含与企业相关的词汇、词汇业务含义以及词汇与信息资产（技术元数据）的关系，可以有效帮助企业用户了解其业务元数据和技术元数据的对应的业务含义。Business Glossary 可以使所有用户协同管理业务元数据比如元数据定义、同义词、样例和分类等，并提供多种查询方式，比如报表、条件查询、影响分析等。

元数据应该由了解信息资产对业务的意义和重要性的人员进行管理。InfoSphere Business Glossary 设计用于协作授权，使用户能够共享关于数据的见解和体验。产品为用户提供关于数据资源的以下信息：

● 数据的商业意义和说明；

● 数据和流程的管家；

● 保证的业务等级；

● 获准使用的术语；

用户可根据可控词汇表定义的语义来组织并查找 InfoSphere Business Glossary，您可使用 Web 控制台来创建可控词汇表。IBM Business Glossary 业务术语管理分类如图2所示，通过业务术语管理可以实现：

● 定义权威性的含义；

● 增加对整个企业机构的业务理解；

● 建立职责和可追溯的制度；

● 描绘业务层次；

● 记录业务描述，例如缩写和同义词；

● 查找相关的信息资产；

● 鼓励使用、重用和更正业务术语；

● 让 IT 与业务目标更有效地结合；

● 提供业务内容与 IT 资产的对应联系；

● 建立职责和数据管控的政策。

图 2 IBM InfoSphere Business Glossary 业务术语管理分类

通过使用 Business Glossary 解决方案可以帮企业带来很多价值，比如：

● 获取业务术语并进行分类，基于 Web 的业务元数据生成、管理和共享；

● 把业务术语及其分类与 IT 资产关联，为信息技术资产提供业务环境；

● 识别数据使用者让业务术语可被访问，让每个用户可立刻访问有内涵的信息；

● 让 IT 项目向数据管理看齐，创建和管理业务术语及关系，同时链接到物理数据源。

● 加强业务与 IT 人员的通力合作，确立责任和义务，使 IT 部门的工作与业务部门的目标保持一致。

Business Glossary 与 Information Server 其他组件以及第三方产品交互如图 3 所示，Business Glossary 负责对业务元数据进行管理，Metadata Server 作为中央共享元数据库负责存储业务、技术和操作元数据，Information Server 组件的各种开发和运行元数据将会自动存储在 Metadata Server 中，通过 import/export manager 还可以将第三方各种元数据与 Metadata Server 进行元数据交互，Metadata Server 还支持导入 CSV、XML、Glossary archive 和 InfoSphere Data Architect 等内容。Metadata Workbench 允许用户浏览、分析和管理在 Metadata Server 中的元数据并为企业用户提供信息供应链全程的数据流报告、数据沿袭和依赖性分析等。Information Server 其他组件（如 FastTrack/Information Analyzer/InfoSphere Data Architect 等）可以直接访问 Metadata Server 获取元数据，DataStage 和 QualityStage 可以通过 DataStage Connectors 访问 Metadata Server。如右下方所示，访问业务元数据的方法有多种，可以通过 Business Glossary 浏览器浏览和搜索词汇表，可以通过 Business Glossary Anywhere 客户机浏览词汇表内容并支持屏幕取词功能，可以通过 Business Glossary REST API（Representational State Transfer 应用程序编程接口）编写自己的程序来访问和修改业务词汇表内容，还可以通过 Business Glossary Client for Eclipse 插件让基于 Eclipse 的应用程序直接访问词汇表内容。Business Glossary 还支持与 Cognos BI 和 IBM Industry Models 等集成。

图 3 元数据管理体系结构图

InfoSphere Business Glossary Anywhere 介绍

IBM InfoSphere Business Glossary Anywhere 可以从在 Microsoft Windows 计算机上打开的任何文本文件直接访问业务词汇表。另外，InfoSphere Business Glossary Anywhere 附带 IBM InfoSphere Business Glossary Client for Eclipse 和 IBM InfoSphere Business Glossary REST API。

通过使用 IBM InfoSphere Business Glossary Anywhere，用户可以在执行其他基于计算机的任务的同时搜索业务词汇表，不会丢失上下文或分散注意力。用户可以通过鼠标或键盘操作在 Microsoft Windows 桌面上打开的文档中捕捉单词或短语，然后在业务词汇表内容中搜索它。用户不必另外打开并登录 InfoSphere Business Glossary，就可以使用大多数业务词汇表信息。

InfoSphere Metadata Workbench 介绍

IBM InfoSphere Metadata Workbench 是基于 Web 界面的元数据管理工具，对 Metada Server 中的业务元数据和技术元数据提供完整的管理并提供元数据的完整视图，提供多种元数据导入导出功能。InfoSphere Metadata Workbench 可以在整个数据集成项目中跟踪和维护信息的关系，从而提高 IT 对业务人员的透明性和 IT 的响应能力。使用 InfoSphere Information Server 产品中不同的模块用户，可以通过 InfoSphere Metadata Workbench 查看 InfoSphere Information Server 元数据存储库中的元数据和数据资产。Metadata Workbench 可以提供丰富的元数据分析，为整个信息供应链的元数据提供全程的数据流报告，提供基于字段或作业的数据沿袭（也就是数据世系分析或血缘分析）、影响分析和系统相关性分析等。例如某电信公司在前端展示工具 Cognos Report Studio 中展示的掉话率指标明显和实际不符，可以通过 Metadata Workbench 使用血缘分析上溯到数据源（数据仓库、ODS、ETL、网管系统、EOMS）并图形化的显示出该路径上的所有对象，方便查找在哪个环节出现问题。

数据流报告显示数据从最开始的业务系统（粒度到列级别）、复制、ETL、ODS 或数据仓库到前端展示报告或 Dashboad 完整的转移路径，包括其中对数据执行的处理的类型等。数据流报告方便业务人员了解信息的起源以及具体的转移过程，有助于进行数据世系分析，满足法律遵从性和可审计性需求。比如可以方便的找出前端展示报告中的某个字段的来源，某个 Datastage 作业将数据移动到什么位置等。数据世系分析可以跟踪整个企业的数据流（即便数据没有保存在 Metadata Server 中），可以通过创建扩展映射和扩展数据源来跟踪数据流，为数据流中的任何资产创建扩展的数据世系分析报告。

结束语

本文详细介绍了大数据治理统一流程参考模型的第三步：“实施元数据管理”，并详细讲述了在大数据时代如何实施元数据管理，随后介绍了元数据管理成熟度模型，帮助企业可以参考该模型衡量自己当前元数据管理水平，最后简单介绍了 IBM 在元数据管理方面的产品：业务元数据管理工具 IBM InfoSphere Business Glossary、业务词汇表小工具 InfoSphere Business Glossary Anywhere 和技术元数据管理工具 InfoSphere Metadata Workbench。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型第四步“定义业务问题”、第五步“获得主管支持”、第六步“执行成熟度评估”、第七步“构建路线图”、第八步“建立组织蓝图”和第九步“了解数据”等内容，并继续介绍 IBM 信息服务器中的 InfoSphere Information Analyze、InfoSphere Federation Server、InfoSphere Replication Server 和 InfoSphere Change Data Capture 等。InfoSphere Information Analyze 是一款数据质量分析工具软件，用来在项目初期对数据源进行数据质量分析，以便真正地了解源数据的结构、质量和数据分布等，提早发现数据的缺失、错误、重复和不一致等问题，为后面的数据复制、ETL 等过程提供支持，以便降低项目实施风险。

参考文献

[12] Sunil Soares,“Big Data Governance”, Part 7 ；

[13] 本章参考了 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），负责制定企业的信息治理计划，保证整个企业层面的信息可信度，很多时候首席数据官也会将大数据纳入其职责范围。

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

1、定义数据治理章程：描述数据治理主要目标和关键流程图、关键利益相关方、角色、职责、决策权和成功的度量方式等。

2、定义数据治理的组织结构：通常建议在三层模式运行数据治理效果最佳，顶层为数据治理委员会（包括高级利益相关方），中间是数据治理工作组（包括负责定期治理数据的成员），底层是数据管理员工作组（负责数据的日常处理）。

3、建立数据治理委员会：由数据治理计划的主管发起人组成，该委员会负责数据治理的愿景和目标、并协调企业内各部门，掌控数据治理计划的总方向。该委员会可能包含首席信息官（CIO）、首席信息安全官（CISO）、首席风险官（CRO）、首席合规官（CCO）、首席隐私官（CPO）和首席数据官（CDO），还可能包括来自财务、法律、HR 团队以及各业务部门的代表等。

4、建立数据治理工作组：主要负责数据治理计划的日常运作并负责监督数据管理员工作组，该组组长通常由数据治理委员会成员兼任，如果存在首席数据官（CDO）常常会由该角色担任。

5、确定数据管理员：数据管理员负责处理每天具体的问题和事物。

6、定期召开数据监管委员会和工作组会议。

第九步：了解数据

想要成功地实施大数据治理计划，需要了解信息供应链中的各个环节的数据模型、主外键关系、数据分布情况、数据源之间的数据沿袭和转换逻辑等。针对狭义大数据，可以根据用例的实际情况详细了解该用例中信息供应链各个环节的详细情况，具体实施第九步了解数据时可以通过使用 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 数据质量分析功能主要包括：

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

● 完全并行处理的系统架构，提供强大的数据处理能力。

● 针对全部分析任务，提供对字段、数据表和多数据表之间的抽样运行选项。

● 实现多个字段、主键/外键的灵活组合分析。

● 提供立刻或定时运行分析任务的选项。

2、与 IBM 数据服务器集成：

● 与 IBM QualityStage/DataStage 软件工具共享元数据。

● 支持 IBM Business Glossary 元数据录入和管理的软件工具。

● 通过分析结果，进行验证并可生成可供参考的映射表。

3、高安全性的分析架构：

● 以项目为基础，控制并允许对重要数据的访问。

● 支持以角色为基础，和以用户为基础的安全访问权限控制。

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

● 通过 IBM-branded ODBC 驱动软件，连接全部符合业界标准数据库，也可连接 IBM 主机系统数据库。

● 支持全部开放操作系统平台，包括：AIX、Solaris、Red Hat Enterprise Linux AS、HP-UX 、SuSE Enterprise Linux、Microsoft Windows。

5、灵活分析机制：

● 支持多种分析逻辑流程组合。

● 支持多种层次分析，可选择从数据目标（Schema）、数据表（Table）、或指定字段（Column）作分析。

● 支持全部字段或部分数据抽样分析。

● 支持交互式分析数据。

6、标准元数据管理：

● 无需把源系统的数据传送和复制到本地数据库，仅对源数据作分析。

● 存放分析结果和对应元数据的数据库，是标准的关系型（RDBMS）数据库并支持 DB2、Oracle、SQL Server 等。

● 提供多达 40 种 out-of-the-box 分析报告，元数据库可开放给任何 BI 系统或报表工具系统，以共享分析结果数据。

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

1、列分析：通过对源数据库表的列进行分析，帮助用户了解源数据的结构、内容、质量和准确性等，允许用户对具体的列进行钻取以便对该列进行特殊的质量控制，支持用户进行值域（某个属性正确值的集合）分析。

2、主键分析：通过对源数据库一个或多个表的所有候选列进行分析，帮用户找出表中哪些列适合做主键，以及哪些列不适合做主键等（比如存在大量重复记录）。

3、外健分析：检查表之间的内容和关系，帮助用户识别外键，并检查主键和外键之间的参照完整性。

4、跨域分析：检查表之间的内容和关系并进行分析，以确定列之间值的重叠以及表内和表间数据的冗余情况。

5、基准分析：帮助查看内容和数据结构随时间而发生的变化。

6、数据规则和指标：支持用户创建逻辑规则进行数据验证，验证规则分析可以延伸数据源或跨数据源的评估，以定义数据之间的关系。允许以多种方式表达验证规则。

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 具有以下功能：

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

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

2、保证数据完整性

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

3、简单易用，无需编程

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

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

支持跨平台数据复制，支持 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 等，有助于实现跨系统整合数据。

5、扩展能力强

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

6、支持与消息队列集成

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

7、准实时的捕捉数据变化

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

8、支持多种复制方式

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 等。

参考文献

[14] IBM 数据治理成熟度评估问卷样本请参考《IBM 数据监管统一流程》白皮书附录 D。

[15] 本章参考了 IBM 相关产品的信息中心、白皮书、方案建议书以及其他各种资料。

第五部分：定义度量值和主数据监管

数据治理需要全面的度量值或关键业务指标（KPI）来衡量和跟踪数据治理计划的进度，考核数据治理的效果。在大数据时代，通过建立大数据与主数据之间的映射关系可以有效地提高客户关系管理水平，提高客户满意度和忠诚度，提升销售业绩。本文主要介绍大数据治理统一流程参考模型的第十步“定义度量值”、第十一步“主数据监管”。

第十步：定义度量值

数据治理需要全面的度量值或关键业务指标（KPI）来衡量和跟踪数据治理计划的进度，考核数据治理的效果。定义度量值的步骤如下：

1、 根据业务需求，了解业务的整体 KPI。

2、 针对数据治理定义业务层面 KPI：比如税务部门核心征收管理业务都是围绕着纳税人进行的，每个纳税人都有自己的纳税人登记证号（且符合特定的编码规则），从省级地税层面来看，由于一些省份没有实现核心征管全省大集中或者实现了全省集中，但是核心征管相关的功能分散在多个系统中实现，纳税人登记证号存在多种不符合编码规则的现象（错误录入或虚假信息），可以将错误纳税人登记证号的纳税人记录的百分比作为数据治理 KPI。数据治理计划可以使用该度量值定期向数据治理工作组和数据治理委员会报告。

3、 针对数据治理定义技术性 KPI。

4、 建立用于数据治理成熟度评估的仪表盘。

第十一步：主数据监管

主数据（Master Data）是指在整个信息供应链中各个业务系统之间都需要共享的数据、业务规则和策略等。常见的主数据主要包括与客户（customers），供应商（suppliers），帐户（accounts）以及组织单位（organizational units）相关的数据。主数据管理（Master Data Management，MDM）描述了一组约束（规程）、方法和技术解决方案用来保证整个信息供应链内主题域（subject domain）和跨主题域相关主数据的完整一致性。主数据管理是应用流程的补充，为应用提供精确、完整的关键业务实体数据。

主数据管理是构建企业信息单一视图的重要组成部分，可以保证在整个企业范围内跨业务竖井协调和重用主数据。主数据管理不会创建新的数据或新的数据纵向结构，而是提供一种方法使企业能够有效地管理分布在整个信息供应链中的各种主数据（由信息供应链各业务系统产生）。MDM 可以帮助企业构建并维护贯穿整个信息供应链的主数据单一视图（Master Data Single View），提供主数据的质量管理（数据治理）和统一业务实体定义（元数据），简化并改进业务流程并提高业务响应速度。统一完整的元数据管理，特别是清晰的主题域划分、完善的元模型和元元模型有利于更好地管理主数据。

主数据管理问题的存在，是由企业业务发展的渐进性、IT 技术发展的渐进性、业务系统自下而上而不是自上而下、缺乏统一的数据治理和元数据管理共同造成的。正是由于这种渐进性，各企业的业务系统都大体经历了从无到有，从简单到复杂，直到形成了一个个业务竖井。从根本上来说，企业很难只用一个业务系统覆盖所有的业务，特别是大型跨国公司，同一个业务系统也可能会在不同的国家或地区部署多套，加上企业信息化建设缺少统一规划，从而造成了需要在各业务系统中共享的主数据被分散到了各个业务系统分别进行管理。分散管理的主数据由于不具备一致性、准确性和完整性，使得各个企业普遍存在着产品、供应商和订单管理不力的现象，解决这一问题的根本方法就是引入主数据管理。

在大数据时代，通过建立大数据与主数据之间的映射关系可以有效地提高客户关系管理水平，提高客户满意度和忠诚度，提升销售业绩，比如通过从微博、微信、交友网站以及 Call Center 语音记录中获取数据，进行更精确的客户流失建模，可以有效的提升客户流失预测的准确率，再比如从社交媒体、多媒体、电话语音记录等多种数据源获取数据用于客户细分、交叉销售、提升销售、客户维护挽留、客户偏好管理等，都可以有效地提升客户关系管理水平。

主数据监管是个持续的过程，企业领导者通过主数据监管管理其主数据的质量，定义准则、策略、流程、业务规则以及度量值，从而实现业务目标。主数据监管主要包括委派数据管理员、管理数据质量和实施主数据管理三部分。

图 1 IBM 数据管理成熟度

● 委派数据管理员：主要包括委派首席数据管理员、确定数据管理工作计划的配置（根据成熟度的不同，从低到高分为按 IT 系统、按组织和按主题区域调整数据管理工作，具体如图 1 所示）、确定每个数据领域的主管发起人以及为每个数据领域分配数据管理员等。

● 管理数据质量：通过使用度量、提高和证明企业数据质量和完整性的各种方法，提高主数据的质量，防止数据质量随着时间的推移而降低。数据质量包括数据标准化、匹配、存活力和长期的质量监控。数据治理组织需要制定用于确定高价值数据属性的策略和用于度量数据质量逐渐改善情况的机制。管理数据质量主要包括以下子步骤：

● 制定数据质量策略，包括高价值数据属性的确定；

● 建立数据质量基线；

● 构建业务案例；

● 清理数据；

● 长期监控数据质量。

● 实施主数据管理：建议企业可以参考以下步骤实施主数据管理：

● 确定业务问题、定义主数据的主题区域；

● 确定当前数据源，确定处理数据的系统和业务流程；

● 制定主数据监管制策略；

● 匹配相同源或多个源中的重复可疑项，创建新的主记录，链接多个源中的相关记录，检查唯一标识的重复项；

● 管理关系、层次结构、分组，设计和实施主数据管理解决方案；

● 提升主数据管理质量以便更好地支持大数据分析，如同很多企业利用主数据管理清洗即将装载进数据仓库的数据一样，企业同样需要高质量的主数据提升大数据分析；同样地，也可以利用大数据提高主数据的质量，如从半结构化、非结构化数据中提取数据丰富主数据等；

● 提高参考数据的质量（如各种代码）和一致性提升大数据治理水平；

● 在遵守隐私相关法规的前提下尝试将社交媒体数据和主数据进行关联。

图2 主数据管理成熟度

企业在实施主数据管理的过程中，可以参考主数据成熟度模型。如图 2 所示，主数据管理大体可以分成 6 个级别：

● L0 ：初始状态

主数据分散于各个业务系统中，每个业务系统独立管理和维护自己的关键数据，各系统间不共享这些信息，数据是不连通的。

● L1 ：列表模式

通过手工方式维护一个逻辑或物理的列表用来共享主数据，当各个系统或用户需要某些数据时可以索取该列表。列表的维护（增删改和冲突处理）由各部门工作人员通过一系列讨论和会议进行处理。相比 L0，虽然各部门依然独立维护各自关键数据，但已经开始使用列表方式维护一个松散的主数据列表，满足各部门的主数据需求。L1 模式下，由于缺乏集中的基于规则的主数据管理，在数据量比较小时列表管理的方式是可行的，但当数据量较大时，数据维护的成本会很高，效率比较低。

● L2 ：主数据统一存储

通过引入中央存储库实现主数据的自动存储管理（中央存储库中的数据还是按照各个业务系统分开存储的，没有统一整合在一起）。中央存储库此时也被称为主数据主机（Master Data Host），并通过一个“打包应用”（MDM 应用程序）对外提供数据访问功能，当需要对主数据进行增删改时，外部应用（请求发起端）将请求“打包应用”更新中央存储库中的数据，并调用数据所有者所在的应用（通过接口）来更新对应的数据。

在 L2 阶段，规则管理、主数据质量管理和变更管理都需要额外定制，打包应用并不提供相应功能，外部应用需要了解所有数据所有者的业务逻辑和数据结构等。比如当某外部应用（比如呼叫中心）需要增加一个客户，该外部应用将提交一个事务，请求中央存储库添加数据，并请求数据所有者增加一个客户条目，中央存储库添加完数据后将通知外部应用。在 L1 中，数据变更是基于手工模式，在 L2 中数据变更会自动完成（需要通过具体技术实现标准流程）。在 L2 阶段，各个外部应用需要能够了解基本的业务规则（元模型）以便访问主列表并与主列表进行交互，并且各个外部应用有责任坚持数据管理的原则和规程。

● L3 ：主数据统一管理

在此阶段，中央存储库将打破各业务部门组织疆界，使用各业务系统都能接受的统一数据标准（统一的元模型）建立和维护主数据。主数据的统一管理意味着构建了一个通用的面向所有业务的平台，此时中央存储库作为一个集线器（Hub）从多个业务系统整合主题域数据，使用集中和标准化的方法转换异构数据。对比 L2，L3 有以下改进：

在 L3 由于使用统一的数据标准，有效地解决了数据不一致的问题，避免了数据在不同的地方代表不同的含义，大大降低了外部应用访问数据的复杂性。主数据不再按照业务条块分开存储，而是按照主题域集中存储和管理，打破了各业务竖井的组织边界。

在 L3 阶段，外部应用仅仅需要和集线器交互进行数据的访问和增删改请求，不再需要支持源系统定位和操作逻辑，任何与数据所有者（源系统）数据相关的分布式细节都会被 MDM 集线器集中处理（集线器自动捕获主数据值的变更并同步各源系统相关数据）。

从 L3 开始支持一致性的主数据单一视图，开始应用数据质量规则进行数据清洗和错误纠正。

● L4 ：业务规则和策略支持

在此级别引入了对业务规则、流程和策略的支持，以保证主数据的完整性和相关性。比如医院通常会有多个应用系统来支持一个病人的护理，包括入院、房间和床位分配、监控设备、化验、身体检查以及其他程序。当病人准备出院时医院需要保证与该病人相关的所有活动和资源都被结清。这就要求主数据集线器不仅要提供病人的详细资料和所有基于房间（例如床位、监控设备、护理活动等）的详细信息，还要提供与该病人相关的诊疗、化验、身体检查和其他程序发生的费用列表。在 L4 阶段支持对规则和策略的扩展性支持，集线器以一个灵活可持续地方式支持任何面向业务的规则集合，例如一个商店经理更新一个产品的价格，主数据管理系统需要和一个可信系统（例如商品管理系统）进行协商以便让规则生效。L4 支持规则集中管理，规则本身和相关处理是可以分开的，MDM 集线器需要保证规则是集中应用的，即便这个规则是在集线器外居住的。

● L5 ：高度自动化

在 L5 阶段，主数据的管理是高度自动化的，当主数据记录详细资料被修改后，所有应用的相关数据元素都被更新，所有的消费应用和源系统访问的都是相同的数据实例（之前的级别中，主数据是由各系统产生而不是 MDM Hub 产生的），本质上构成了一个闭环的 MDM：所有的应用系统通过统一管理的主数据集成在一起。所有系统看起来都是事实的同一个版本。相比 L4，L5 意味着 MDM 不是在一个应用内被特殊设计或编码的，主数据传播和供应不需要源系统专门地开发或支持。所有应用都清楚地知道其并不拥有或控制主数据，仅仅使用数据来支持自己的功能和流程。L5 保证了一个一致的主数据主题域，定义“客户”和其他应用接受客户主数据业务规则变化实际上是一回事，移走了主数据的最后一个障碍：统一采用数据定义、授权使用和变更传播。

IBM 主数据管理（MDM）

IBM InfoSphere MDM 是当今市场上功能最强大的主数据管理（MDM）产品，处理完整范围的主数据管理需求和用例。为了给客户提供其 MDM 解决方案需求的最佳范围，提供了以下 4 个 IBM InfoSphere MDM 版本：Collaborative Edition、Standard Edition、Advanced Edition 以及 Enterprise Edition，其中 Enterprise Edition 版本包含了其它三个版本所有的功能。主数据管理与各个业务系统的关系与定位如图 3 所示：

图3 主数据管理与业务系统的关系与定位

InfoSphere MDM Collaboration Server

InfoSphere MDM Collaboration Server（MDMCS）在 V10 之前叫做 InfoSphere Master Data Management Server for Product Information Management（MDM Server for PIM），目前最新版本是 V10.1，该产品在 V6.0 之前的版本曾叫 WebSphere Product Center，是从 Trigo Technologies 公司（IBM 2004 年收购）的 Trigo Product Center 衍生而来的。MDMCS 是一个中间件，提供了高度可伸缩的企业产品信息（PIM）管理解决方案，用于建立企业内部和外部的产品和服务信息的单个、集成且一致的视图，帮助企业缩短销售时间，提高市场占有率和客户满意度，降低成本。通过使用 MDMCS 集中处理和优化产品数据，可以将有关的唯一内容传递给需要的业务系统、合作伙伴、客户以及个人，如图 4 所示，产品具体提供了以下功能：

● 灵活且可伸缩的存储库，用以管理产品单品、条目、位置、组织结构、贸易伙伴和贸易条款信息以及与这些信息建立链接。

● 帮助企业捕获、创建和管理主数据，为主数据提供建模工具。

● 具有灵活的数据模型和管理多层次结构的能力。

● 具有连接到离散系统的能力，支持与现有系统、各种应用程序、存储库集成，并保证主数据信息同步。

● 支持工作流程、可快速适应需求变化的业务流程。

● 支持与业务合作伙伴交换信息和保证信息同步。

● 具有一个细粒度化且易于扩展的安全性模型。

图 4 InfoSphere MDM Collaboration Server 功能

图5 InfoSphere MDM Collaboration Server 体系结构

如图 5 所示，MDMCS 采用基于组件的体系结构，其组件包括：核心组件、集成组件和协作组件。核心组件主要由 API 层、业务对象层、基础结构层和存储器层组成，在 API 层可以通过调用 Java API 扩展 Collaboration Server，可以使用搜索 API 在 Collaboration Server 中搜索信息，还可以使用脚本 API 来扩展 Collaboration Server 解决方案（在 Collaboration Server V6 之前，脚本 API 是扩展解决方案的唯一机制）；在业务对象层，可以使用数据对象对实例级别对象（可以是一天中执行操作最频繁的对象，如产品、SKU 和工作项等）进行建模、使用元数据对象为实现的结构（如目录和层次结构等）建模以及定义数据对象的结构（如定义项属性的规范）、使用用户建模对象来捕获企业的用户模型（比如用户的报告层次结构、角色、用户、数据访问特权和权限等）；在基础结构层，可以使用队列管理器往 Collaboration Server 外部发送文档、使用事件处理器在所有模块间分派事件、使用管理服务启停服务、使用 RMI 注册程序协调 RMI 服务间通信、使用调度程序服务执行调度作业（比如导入、导出和报告等）；在存储器层，可以使用 Collaborative Edition 存储库（PIM 存储库）基于一组物理数据库表持久保存业务对象，使用文档存储器（一组物理数据库表和文件系统位置）存储扩展内容和未组织的内容如订阅源文件、报告和导出作业输出等。

集成组件主要由门户网站框架、定制工具、导入/导出和 Web Service 组成，通过门户网站框架可以将 MDMCS 与 WebSphere Portal Server 集成在一起；通过定制工具可以在 Collaboration Edition 定制用户界面；可以使用“Web Service”调用标准 Web Service 请求；导入/导出负责获取入局数据（导入）和生成数据（导出）。

协作组件由工作流引擎、数据编写 UI 和导入/导出组成，工作流引擎主要处理工作流程中捕获的与业务对象相关的事件；数据编写 UI 提供一组用户界面屏幕用来与数据对象（实例级别业务对象）进行交互，以指定和丰富为它们提供的数据以及设置它们之间的关联；导入/导出负责获取入局数据（导入）以及生成数据（导出）。

InfoSphere MDM Standard Edition

InfoSphere MDM Standard Edition（MDMSE）在 V10 之前被称为 Initiate Master Data Service，是 Initiate 主数据管理的产品平台，Initiate 是一家专注于医疗卫生、政府等行业主数据管理产品和解决方案的软件公司，2010 年被 IBM 收购，并补充进 IBM 信息管理产品家族。MDMSE 是业内领先并被广泛应用的 MDM 软件，帮助政府、医疗、零售和金融等行业用户理解和信任其所拥有的数据，企业可以使用该解决方案来获得完整、实时、准确的主数据视图。MDMSE 产品以其灵活的数据模型，SOA 的标准架构，无侵略性、松耦合的集成方式，轻量级、易操作、快速实施部署等特点在政府和医疗领域的使用尤为突出。通过使用 MDMSE 可以快速识别和整合散落的人员、机构信息。MDMSE 提供了针对关键数据资产以及这些数据相互关系的单一视图，帮助企业快速集成现有同构或异构数据源和应用系统，对数据进行统一的转换、清洗、匹配和链接等操作清除数据的不一致和重复，丰富完善现有数据，保证数据的质量和完整性，提供真实可靠的主数据。MDMSE 平台体系结构如图 6 所示：

图6 MDMSE 平台体系结构

针对医疗卫生行业的病人主索引、居民健康档案、居民主信息记录等需求，MDMSE 可以快速形成 360 度视图，高效、准确识别和管理来自不同数据来源的人员、机构信息，消除重复和不一致的数据，解决在异构系统当中“居民”、“客户”、“病人”、“员工”、“组织机构”等面临的信息一致性、完整性和准确性问题。MDMSE Healthcare 主要包括以下功能：

Initiate Patient Hub: 实现了医疗卫生行业的病人主索引（Enterprise Master Patient Index，EMPI）解决方案，提供符合行业标准的病人信息模型并提供灵活的对外服务接口。

Initiate Provider Hub: 提供针对医疗卫生行业提供者的主数据管理，比如医生和医疗机构等，可以快速的与现有系统和数据源集成，准确匹配并关联不同的提供者，形成单一信息视图。

Initiate Exchange: 连接各种医护环境，为服务点提供随时获取信息的便利。

InfoSphere MDM Advance Edition

InfoSphere MDM Advance Edition（MDMAE）在 V10 之前被称为 InfoSphere MDM Server，主要用来实现和维护跨企业的单一版本的真实数据，消除信息竖井，控制企业内最重要最需要共享的信息资产。MDMAE 主要用于管理客户主数据，也可以管理合约和产品等，具体来说可以实现企业内重要的主数据实体，如客户、产品、供应商、员工、潜在客户、代理商、项目、产品捆绑、部件和协议等管理，实现主数据实体的单一视图，帮助用户减少信息错误，消除重复数据，提高企业运营效率。MDMAE 产品部署灵活迅速，其匹配和关联能力业内领先，并具有全面管控功能，可以满足行业内和行业间广泛的业务需求。企业可以使用该产品内嵌的智能和对数据的洞察力，提升销售能力，改进市场推广效果并提高财务运营能力。MDMAE 作为一个完整的主数据管理方案，可以帮助企业完成客户整合、客户管理、客户流程优化、以客户为中心的转型等短、中、远期业务目标。

MDMAE 是一个企业级应用，为参与人（Party）、产品（product）、账户（account）和位置（location）提供事实的单一版本，提供多渠道管理的环境，通过统一前后台系统提供客户信息的单一版本。Party 可以反映任何合法的实体，无论是个体还是组织；Product 既包括物理存在的货物，也可以是任何服务；Account 包括期限和条件，以及相关的各种关系；Location 既可以独立存在，也常常与其他主数据域共存；主数据管理需要关注的不仅仅是这些域，还包括它们之间的各种关系。MDMAE 使用基于组件的可扩展标记语言（XML）、J2EE 平台和 EJB 架构，以便快速和其他系统集成，并提供充分的灵活性和扩展性。如图 7 所示，面向服务体系架构 MDMAE 集成了强大功能，提供业务服务、通用服务、管理服务、业务逻辑与规则和扩展服务等。通过强大的数据管理功能用户可以建立可信信息，提供预先构建的数据集成和数据质量控制；通过业务服务组件，使用预先构建以及定制的业务服务与所有消费主数据的应用和业务流程交互，从不同领域（domains）集成数据；所有业务模型拥有一个相似的结构，包括控制器组件和相关的业务组件等；所有持久性事务（那些修改数据的事务）都由事务控制器处理，而所有的读取和搜索则由查找控制器（finder controller）处理。MDMAE 使用可扩展的数据模型支持多领域比如：Party、Product、Account 和 Location 等；用户可以自己创建定制领域，MDMAE 使用强约束建立和维护领域之间的关系。

图7 InfoSphere MDM Advance Edition 体系结构

结束语

本文详细介绍了大数据治理统一流程参考模型的第十步“定义度量值”、第十一步“主数据监管”，以及 IBM 在主数据管理方面的产品介绍，如 InfoSphere MDM Collaboration Server、InfoSphere MDM Standard Edition 和 InfoSphere MDM Advance Edition 等。在本系列文章的下一部分中将重点介绍大数据治理统一流程参考模型第十二步“（狭义）大数据监管”、第十三步“信息单一视图监管”、IBM 大数据产品 BigInsights 和 Streams 以及 IBM 大数据治理方面的产品 InfoSphere DataStage、InfoSphere QualityStage 等。

参考文献

[16] 本章参考了 IBM 相关产品的信息中心、白皮书、方案建议书以及其他各种资料。

第六部分：大数据监管和信息单一视图监管

在大数据时代，企业更需要数据治理，只有对海量数据进行治理，使其变得可信才能帮助企业获取准确、深入的洞察力。通过使用完整、及时、准确和一致的企业单一信息视图，企业高管们可以针对不同的情况及时采取措施，为了成功实现企业信息单一视图，对其进行监管就非常重要。本文将重点介绍大数据治理统一流程参考模型的第十二步“（狭义）大数据监管”、第十三步“信息单一视图监管”。

第十二步：（狭义）大数据监管

在大数据时代，企业更需要数据治理，只有对海量数据进行治理，使其变得可信才能帮助企业获取准确、深入的洞察力。除了满足监管和风险管理要求外，企业通过对大数据来创造更多的业务价值，比如精细化管理、精准营销、反洗钱和反欺诈等，当然这一切的前提就是数据是可信的。如果基础数据不可靠，那么大多数企业的大数据计划要么会失败，要么效果会低于预期。大数据监管和主数据监管类似，同样包含三部分：委派数据管理员、（狭义）大数据质量管理和实施大数据管理三部分。

1、 委派数据管理员：主要包括委派首席数据管理员、确定数据管理工作计划的配置（根据成熟度的不同，从低到高分为按 IT 系统、按组织和按主题区域调整数据管理工作）、确定每个数据领域的主管发起人以及为每个数据领域分配数据管理员等。

2、 （狭义）大数据数据质量管理：相比传统数据的监管，由于大数据实时性要求高、容量大以及数据类型多样，其数据质量管理也有别于传统数据的质量管理。针对高价值的结构化数据企业通常会执行严格的、完全的数据治理流程，而大数据治理则要考虑投入产出的问题，因为基于目前数据的数量、速度和多样性，企业往往无法承担完全清理每部分数据所需的时间和资源，因为这不太经济。具体来说大数据质量管理与传统的数据质量管理存在以下区别：

● 传统的数据质量管理主要关注静态数据，而大数据治理除了静态数据以外，还要关注动态数据处理；

● 传统数据置信度较高，而（狭义）大数据中很多时候存在大量噪音数据，需要进行清除；

● 传统数据以结构化为主，而（狭义）大数据除了结构化数据，还包含大量的半结构化和非结构化数据；

● 传统数据的元数据管理完善，而（狭义）大数据本身受用例驱动，其元数据管理相应较差；

● 传统数据分析主要基于静态数据，而（狭义）大数据分析除了基于静态数据进行分析以外，还包括对动态数据进行实时分析。

● 企业可以参考以下步骤进行（狭义）大数据的质量管理：

● 在业务上与合作伙伴合作，建立并评估大数据质量的置信区间；

● 相比传统的数据质量管理以内部结构化数据为主不同，大数据项目很多时候会用到大量的外部数据，及时发现数据质量问题比以前困难很多。企业可以尝试在业务上与合作伙伴合作，尝试创建数据质量模型，包含关键的数据元素、数据质量问题和业务规则。比如企业 AAA 基于互联网数据进行产品方面的舆情分析，对采自微博的数据进行以下处理，如果微博记录中包含了“@AAA”以及一件该公司产品，那么置信度为 99%（高置信度），如果该微博记录仅包含“@AAA”，那么置信度为 75%（较高置信度），如果微博记录中只包含 AAA，那么置信度为 50%（中等置信度），如果微博记录来自黑名单中的用户，则置信度为 0。

● 利用半结构化和非结构化数据，提高人口稀疏的结构化数据质量；

● 通过流计算技术对动态数据进行实时处理，剔除噪音数据，提高数据质量，最后将输出结构作为静态数据存储到 Hadoop 平台、MPP 数据库、关系型数据库/数据仓库或各种 NoSQL 数据库中，无需将中间结果进行保存。

3、 实施大数据管理：实施大数据解决方案需要采取务实的态度以及渐进式的方式，首先需要识别业务需求，然后确定基础架构、数据源以及各种 KPI 指标，通过从内部和外部数据源提取新的洞察，帮助企业获得实际效果后再进一步扩大应用范围，根据企业大数据战略进一步升级其基础架构。针对狭义大数据的治理，企业通常需要制定一个合适的大数据治理策略，具体包括以下内容：

● 审核确定大数据治理的业务案例（大数据分析是受用例驱动的）；

● 通过实施完善的元数据管理，建立大数据的类别信息；

● 建立大数据与主数据之间的映射关系，比如在满足隐私以及相关政策的情况下，将社交媒体数据和主数据进行关联；

● 识别企业内与大数据相关的关键业务流程，针对业务流程中的关键步骤制定相应的大数据治理策略；

● 对流数据进行实时分析处理，只将最终要保留的结果进行存储，废弃中间结果和噪音数据；

● 对重点数据实现质量控制；

● 关注大数据生命周期管理，对访问频率较低的数据进行归档，删除没有必要存储的数据等；

● 企业必须建立符合法律规范的隐私策略，防止大数据的误用、滥用。

IBM BigInsights 3.0 介绍

IBM 在 Hadoop 开源框架的基础上进行了大量的开发和扩展，陆续将丰富的高级文本分析（Advanced Text Analytics Toolkit，研发代码 SystemT）、机器学习（Machine Learning Toolkit，研发代码 SystemML）、GPFS File Place Optimizer（GPFS-FPO）、IBM LZO 压缩、针对 Jaql 的 R 模块扩展、改进的工作负载调度（Intelligent Scheduler）、自适应 MapReduce（Adaptive MapReduce）、基于浏览器的可视化工具（BigSheets）、大规模索引、搜索解决方案构建框架（BigIndex）、大规模并行处理 SQL 引擎（MPP SQL Engine，IBM Big SQL）等纳入到 InfoSphere BigInsights 中，并增强了高可用性、可扩展性、安全性、性能、易用性、监控和告警等，通过支持 LDAP 身份验证增强安全性（另外还能够提供可插拔身份验证支持，支持 Kerberos 等其他协议），构建了一个完整的企业级大数据平台。该平台为开发人员提供了全面的开发和运行时环境来构建高级分析应用程序，为企业用户提供了完善的分析工具来分析大数据，从而使与大数据分析相关的时间价值曲线变平。

IBM Big SQL 3.0 是一个大规模并行处理 SQL 引擎（MPP SQL Engine），可以直接部署在物理的 HDFS 集群上。通过使用一个低延时并行执行基础架构，并将处理操作放在数据所在的节点，Big SQL 3.0 实现了 native 方式的 Hadoop 数据访问，包括读和写操作。Big SQL 3.0 数据库基础架构提供一个所有数据的逻辑视图（通过 Hive 元数据管理），查询编译视图，以及为最优的 SQL 处理提供优化和运行时环境。针对复杂嵌套的决策支持查询，Big SQL 3.0 专门做了优化处理。Big SQL 3.0 接口完全支持 SQL 2011 标准，支持存储过程，用户自定义函数，广泛的数据类型，JDBC/ODBC 接口等。

Big SQL 所有的数据都保持原有的格式存储在 Hadoop 集群中，Big SQL 对数据的格式没有特殊的要求，Hadoop 表的定义是由 Hive Metastore 定义和共享的，使用 Hadoop 的标准目录。Big SQL 共享 Hive 接口进行物理读取，写入和理解 Hadoop 中存储的数据。简单的来说，Big SQL 中没有任何的数据存储，数据是存放在 Hadoop 集群中的，在 Big SQL 中定义的表实际上是一个在 Hive 中定义的表。通过 Apache HCatalog，Hive 中定义的表可以作为很多工具的有效数据源。最终，任何 Hadoop 应用程序都可以访问这些大规模共享的分布式文件系统中的简单文件。Big SQL 既可以运行在 POWER Linux (Red Hat) 上，也可以运行在 x64 Linux 上，如 Red Hat 和 SUSE Linux。

更多内容请参考：

IBM Big SQL 3.0 新功能系列，第一部分：大规模并行处理 SQL 引擎（MPP SQL Engine）Big SQL 3.0 介绍

IBM Big SQL 3.0 新功能系列，第二部分：IBM InfoSphere BigInsights 3.0 环境搭建

IBM Big SQL 3.0 新功能系列，第三部分： Big SQL 3.0 测试环境初始化

IBM Big SQL 3.0 新功能系列，第四部分： 小数据量下 TEXTFILE 存储格式 Big SQL 和 Hive External 表查询对比

IBM Big SQL 3.0 新功能系列，第五部分：大数据量下 TEXTFILE 格式的 Big SQL 和 Hive External 表查询对比

IBM Big SQL 3.0 新功能系列，第六部分：各种存储格式下 Big SQL 和 Hive 查询对比

企业级大数据存储、分析平台：IBM InfoSphere BigInsights 3.0 新功能介绍

IBM InfoSphere Streams 介绍

IBM InfoSphere Streams 是一个并行和高效的低延迟流计算平台（毫秒级延迟，甚至低至微秒级），可以即时处理、过滤和分析流数据，流数据可以是结构化、半结构化或非结构化数据（如文本、音频、视频、图像、传感器、数字、GPS 数据、日志、交易记录和呼叫详细记录等各种类型数据）。InfoSphere Streams 支持连续、快速地分析大量移动中的数据，加速业务洞察和决策制定。如图 1 所示，InfoSphere Streams 包含应用程序的编程语言 Steams Processing Language（SPL）和集成开发环境（IDE），以及可在单个主机或一组分布式主机上执行应用程序的运行时系统。SPL 提供一种语言和运行时框架来支持流式方法应用程序。用户可以创建应用程序，无需了解较低级别的特定于流的操作。SPL 提供大量内置运算符、导入 InfoSphere Streams 外部数据和导出系统外部结果的功能，以及通过用户定义的运算符扩展底层系统的工具。许多 SPL 内置运算符提供功能强大的关系函数，如连接和聚合。Streams Studio IDE 包括用于编写和创建 InfoSphere Streams 应用程序的可视化表示的工具。

图1 Streams 体系结构

InfoSphere Steams 可以在多种硬件平台上进行扩展，最高可扩展到 125 个节点（线性的可扩展性），支持动态部署新的分析应用，通过 JVM 共享从而最大限度的减少内存使用。通过在数据进入视野就进行分析，企业可以即时对事件和趋势进行响应，改善业务成果。通过 Steams，可以跨多个流获得洞察力，融合多个流获得新的洞察力，还支持将需要的数据保存后进行深入分析等。InfoSphere Streams 作为支持流计算快捷实时数据分析开发平台，提供对流数据（结构化和非结构化）的实时分析能力，支持海量多数据源，提供高性能处理和敏捷开发，支持流动数据加分析的模式从海量数据中挖掘出有用的信息。另外，InfoSphere Streams 和 BigInsights 共享同一个 Advanced Text Analytics Toolkit，可以在整个大数据平台中实现技能和代码的重用。

如图 2 所示，在 Streams 流计算过程中最小处理单元是 Processing Element（PE），可以配置 PE 动态地在多个服务器间动态负载均衡，根据工作负载需要进行动态资源调配，也可以指定让 PE 运行的服务器。

图2 Streams 运行环境

第十三步：信息单一视图监管

过去很长一段时间，企业应用主要围绕业务展开，形成了一个个分立的应用，而分立的应用导致了一个个的静态竖井。这些竖井（信息孤岛）之间缺乏沟通，每个竖井只能提供片面的信息，而不是全局的单一视图。这些孤立的竖井使得高管们对公司只有有限的洞察力，无法准确预见到将要发生的事情。缺少企业信息的单一视图，往往意味着营收损失，客户满意度下降和市场开拓乏力等等。例如，一个全球性的大公司一般拥有多个业务部门，并且在全球很多地方设有分部，其客户信息和业务合作伙伴信息分散在多个业务系统中，每个部门甚至每个分部都拥有自己的客户关系管理系统。即便在同一个部门，客户信息也可能分散在计费、订单和客服中心中，因此公司无法获得关于其客户的足够信息以便更有效地服务客户或开拓市场。更好的客户服务和更高的目标要求，驱动了对客户信息单一视图的需求。再例如银行受理一笔贷款申请，由于没有足够的历史数据支撑，无法准确判读借款人的风险评级情况，很多时候只能依据借款人提供的当前时点的资料进行主观判断，假如该借款人另一个不同的账户过去有拖欠付款记录，而且没有被正确标识，那么客户可能会收到不恰当的良好记录，而银行也会因此增加风险。当银行给客户提供贷款时，公司需要准确的知道不同客户能给公司带来的价值和相应的风险。如果对客户缺乏足够的了解，那么就无法准确地了解和他们相关的风险敞口，而公司就可能会低估该风险敞口或给予客户过于宽松的信贷条件。

为了解决业务竖井，消除信息孤岛，信息架构需要从以项目为基础转向以灵活架构为基础，动态地为应用提供整合的信息（可信的全景信息），即信息随需应变（Information On Demand，IOD）。通过一个灵活的信息架构，用户可以在需要的时间和地点拿到准确、一致、完整和及时的数据。信息随需应变提供战略性的框架和解决方案，提供带有上下文、可供信任的信息来优化业务过程，提高生产力。IOD 的结果是什么？就是信息被有效利用，从而驱动企业的业务变革，即信息引领变革（Information-Led Transformation）。通过使用完整、及时、准确和一致的企业单一信息视图，企业高管们可以针对不同的情况及时采取措施，如通过实时准确的财务信息视图，CFO 可以获得核心财务比率以便评估业绩并采取必要的补救措施。为了成功实现企业信息单一视图，对其进行监管就非常重要。信息单一视图监管同样包含三个部分：委派数据管理员、管理数据质量和实施信息单一视图三部分。

IBM InfoSphere DataStage

InfoSphere DataStage 是一款功能强大的基于图形化的 ETL 工具，可以从各种不同的数据源（可以是 ODS，数据库/数据仓库/数据集市/MPP 数据库，Hadoop 平台等不同数据源）中抽取并转换数据，并将其加载到各种目标系统（可以是 ODS，数据库/数据仓库/数据集市/MPP 数据库，Hadoop 平台，各种应用程序等）中，可以大量节省信息集成所需的工作量，降低项目集成风险。DataStage 可以批量或实时地（和 CDC 结合）处理大容量数据，在每个作业中几乎可以和无限的异构数据源连接（连接器采用 Information Server 通用连接器）。

InfoSphere Datastage 具有以下特点：

● 完全图形化的设计工具，作业设计、开发、调试和维护非常容易；图形化的工作流，支持条件路径和错误处理，支持 Email 通知等；作业可重用性高；顺序开发，并行执行。

● 支持各种数据源连接，作业可以访问企业应用程序，关系数据库（如 DB2、Oracle、 Informix、Sybase、Microsoft SQL Server 以及 ODBC 等），ERP 或 CRM 数据库，数据仓库和文件集（SAS 数据集、XML、平面文件、Cobol 复合文件等），Hadoop 平台等。

● DataStage 实现了与 HDFS 和 GPFS-FPO 的全面集成，可以充分利用集群架构的优势将所有批量数据并行地写入同一文件。通过使用 DataStage 集成，各种 Hadoop 平台可以方便地实现与传统结构化数据源的数据交换。DataStage 除了改进与 HDFS 相关的集成，还新增了与通用 MapReduce 作业相关的集成，和各种 Hadoop 平台进行了紧密结合。

● 提供全面的内置函数库帮助实现数据流的无代码可视化设计，减少开发时间和学习难度，提高准确性和可靠性。

● 高性能可伸缩处理架构，充分支持并行处理且不需要更改设计，作业可运行于任意并行度，只需要变更配置文件（也就是增减并行度不需要修改编译作业），可线性扩展性能。

● 支持批处理或实时数据处理（通常需要和 InfoSphere Data Replication 配合）。

● 统一的元数据模型，支持 CWM 元数据模型，可以追踪管理 ETL 过程中的元数据及其变化。

● 支持团队开发和协作。

如图 3 所示，DataStage 由客户端工具，引擎和共用存储库组成，DataStage 和 QualityStage 共用图形化用户界面。DataStage 客户端工具又包括 DataStage and QualityStage Designer，DataStage and QualityStage Director 和 DataStage and QualityStage Administrator 三部分。Designer 是用来创建 DataStage 作业的图形用户界面，在 Designer 中每个作业可以指定数据源，目标数据源和所需转换等，通过编译作业最终生成可执行程序。Director 是用来检验、调度、运行和监视 DataStage 序列的界面，Administrator 是管理界面（比如设置用户，日志记录和创建项目等）。引擎部分包括并行引擎和服务引擎，并行引擎使用 Information Server 共用的并行引擎功能来执行 DataStage 并行作业，服务引擎包括 Information Server 共用的元数据服务和连接器等。共用存储库用来存储 DataStage 各阶段所需的元数据，包括项目元数据，操作性元数据和设计元数据等。

图3 DataStage 体系结构图

直观易用的开发和维护环境

Datastage 提供了全面的图形化设计、管理和维护工具，帮助用户优化构建、升级和管理数据整合架构时的速度、灵活性和效率，丰富的功能组件减少了用户学习周期，简单化了管理和优化了开发资源的使用，减少了数据整合应用的开发和维护周期。

Datastage 任务设计采用数据流的概念，一个完整的数据流程（Datastage 作业）由一系列功能组件（Stage）组合而成，具体从数据源 Stage 开始，中间经过一系列的转换和清洗，最后加载到目标数据源。Datastage Designer 使用户可以灵活地以各种方式构建作业：从上到下、从下到上、从中间开始。一个完整的数据流图如图 4 所示：

图4 Datastage 数据流图示例

Datastage 内嵌的扩展 Stage 提供了数据整合过程中 80%以上的最常用的处理逻辑，基于组件架构和扩展内嵌组件类库的 DataStage 支持组件的复用，方便用户整合第三方软件工具和遗留应用。DataStage 提供多种机制帮助用户建立自定义的 Stage：

● Wrapped --允许并行执行一个顺序程序。

● Build --允许自动并行执行自定义 Stage 的 C 语言表达式。

● Custom 提供了完整的 C++ API，来开发复杂和扩展的 Stage。

企业级实施和管理

DataStage 提供图形化的作业定序器，帮助用户指定作业的顺序，顺序中可以包含控制信息以便用户根据作业执行结果采取不同的行动。作业顺序支持 DataStage 作业、例行程序、执行命令（操作系统命令）、电子邮件通知、等待文件、运行异常获得、作业顺序的检查点、重新启动选项、环回阶段、用户表达式和变量、中止异常活动等活动类型。通过 DataStage 提供的资源预估功能，用户可以估算 ETL 任务过程中每个处理阶段所需的系统资源，比如 CPU、内存、磁盘等。通过 DataStage 提供的图形化监控工具，可以直接从设计的数据流图上得知 ETL 每个阶段运行情况，可以生成任务时间性和性能分析图，分解作业查看各 Stage 处理使用的时间，洞察时间线上的瓶颈。DataStage 提供基于 Web 浏览器的监控平台，用来显示当前服务器的运行状态，如 CPU 利用率、内存和磁盘使用情况以及 ETL 任务的运行状态等。

高扩展的体系结构，具备线性扩充能力

如图 5 所示，DataStage 体系结构具有高扩展性，通过管道并行（Pipeline parallelism）或分区并行（Partition parallelism）可以获得高吞吐量和性能，通过支持对称多处理（SMP）和大规模并行处理（MPP）等具备线性扩充能力。

● 管道并行：举例说明，在具有三个以上处理器的系统上运行 Job 时，读取 stage 将在一个处理器上开始并将读取的数据填充管道（Pipeline），当管道中存在数据之后，转换 stage 会在另一个处理器上开始，处理数据并开始填充另一个管道，当另一个管道可用时，写入目标数据库的 stage 会在第三个处理器上开始并立即开始写操作。这样，三个 stage 会同时运行，而不是串行运行。

● 分区并行：通过将数据分割到多个单独的集合（数据分区）中并行执行，充分利用多个处理器高效运行，每个处理器处理所有数据中的一个子集（数据分区），job 完成后可以将所有数据分区重新收集起来写入单一数据源。

图5 Datastage 并行

IBM InfoSphere QualityStage

QualityStage 是一款功能强大的数据清洗工具，可以和 DataStage 无缝集成，通过使用数学概率算法匹配重复的数据记录，自动地把数据（比如客户地址、电话号码、传真、电子邮箱等）转换为经过检验的标准格式，可以消除现有数据源中的重复内容，从而确保数据的唯一性、准确性和一致性。通过可视化的用户界面，可以定义复杂的匹配和留存逻辑以确保干净、标准化和不重复的信息装入到目的端。QualityStage 使用和 DataStage 相同的基础设施导入导出数据、设计、部署和运行作业以及生成报告。

QualityStage 主要包括以下功能：

● 数据调查：帮助了解数据质量和期望达到的数据清洗标准等，为数据标准化提供一些参考信息。

● 数据标准化：帮助将名字、电话号码和地址等常用客户信息标准化，也可根据行业数据做定制，标准化行业数据信息。

● 数据匹配：基于数据的标准化，数据被切割成统一格式的，多个小的信息单元，将小的信息单元用于匹配权重计算，将大大提高匹配概率和准确性。

● 数据留存：将多条匹配或者说重复的数据，交叉组合形成最优的候选数据提供给用户，甚至可以补足一些缺失字段等。

比如我们需要对包含地址信息的字段进行清洗并重新生成新记录，匹配的原理就是将相似的数据根据地址字段分组，然后在数据分组内通过比较计算权重判断哪些数据可能重复，具体如图 6 所示：

图6 数据清洗示例

通过减少重复的客户记录并建立客户家庭档案等，企业可以显著提高客户识别能力并减少市场运营成本。比如某国电信公司，拥有总用户数 2 千万，不同系统的相同客户信息写法不一致，很多信息缺失或者录入错误。该电信公司后来通过使用 QualityStage 将各种信息，如姓名、生日、地址、电话、ID 等进行标准化，然后根据概率算法进行匹配并生成统一的客户视图。结果该电信公司每个月少发 30 万封信，从而每年节省了 200 万美金。

结束语

本文详细介绍了大数据治理统一流程参考模型的第十二步“（狭义）大数据监管”、第十三步“信息单一视图监管”、IBM 大数据产品 BigInsights 和 Streams 以及 IBM 大数据治理方面的产品 InfoSphere DataStage、InfoSphere QualityStage 等。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型第十四步“运营分析监管”、第十五步“预测分析监管”、第十六步“管理安全与隐私”、第十七步“监管信息生命周期”和第十八步“度量结果”，以及 IBM Cognos BI、SPSS Modeler、Guardium、Optim Data Growth Management 和 Optim Test Data Management 等内容。

参考文献

[17] 本章参考了 IBM 相关产品的信息中心、白皮书、方案建议书以及其他各种资料。

第七部分：分析监管、安全与隐私管理和信息生命周期监管

过度的管理数据会带来成本的极大增加，需要在满足业务需求以及法律法规的前提下制定明确的保留时间表，积极采用压缩技术进行大数据的存储从而降低存储成本。此外，如何进行个人隐私保护也是是各个行业在大数据时代面临的一个巨大挑战。本文将介绍大数据治理统一流程参考模型的第十四步“运营分析监管”、第十五步“预测分析监管”、第十六步“管理安全与隐私”、第十七步“监管信息生命周期”和第十八步“度量结果”等内容。

第十四步：运营分析监管

无用的数据会造成前端 KPI 指标的失效，也就是所谓的“无用输入产生无用输出”。不同的部门使用不一致的数据制作报告给企业带来了额外的困扰，IT 并非始终了解数据仓库或数据集市中的数据并清楚的知道正在使用哪些报告。企业可以通过实施商业智能能力中心（BICC）解决这些问题，BICC 是指将具有关联规程、知识领域、经验和技能的人员聚集在一起的组织结构，目的是在整个组织内增进专业技能。BICC 也称为卓越运营中心（COE）、能力中心或知识中心，具体包括以下子步骤：

● 定义 BICC 的目标；

● 准备 BICC 的业务案例；

● 确定 BICC 的组织结构；

● 商定 BICC 的关键功能。

第十五步：预测分析监管

预测分析监管主要负责对商业理解、数据理解、数据准备、建立模型模型评估和模型部署过程所涉及的数据、规程、领域经验和模式等进行监管，保证数据的一致性和准确性，是实现预测分析、构建创新型应用的重要基础。企业同样可以通过实施商业智能能力中心（BICC）来解决这些困难。

第十六步：管理安全与隐私

在大数据时代，如何进行个人隐私保护是各个行业面临的一个巨大挑战。比如电信运营商通过全球定位系统（GBS）信号跟踪个人位置信息进行位置营销，或者将该信息出售给第三方进行广告促销推送过程中一旦被滥用，就有可能对人身安全造成侵害。再比如电力行业，电力企业通过部署智能电表可以准实时的采集最终用户的电力使用情况，这些数据如果没有进行妥善保管，一旦被泄露就有可能对最终用户的安全造成损害（比如窃贼根据用户电表使用数据确认用户何时不在家）。

自 1890 年哈佛大学法学院教授路易斯•布兰迪斯和塞缪尔•沃伦在《哈佛法学评论》上发表了《隐私权》的论文，将隐私定义为“让人独处的权利”以来，隐私权的保护经历了一个漫长的发展过程，目前我国的法律尚未确立隐私权可作为独立的民事权利的地位。对隐私权采取了间接保护的方式，关于隐私权保护的规定分散于多部法律法规中，如 1997 年颁布的新刑法蕴含了对公民隐私权的保护，例如刑法第二百四十五条规定的“非法搜查罪”和非法入侵住宅罪”：非法搜查他人身体、住宅，或者非法侵入他人住宅的，处三年以下有期徒刑或者拘役。再比如刑法第二百五十二条规定的“侵犯通信自由罪”：隐匿、毁弃或者非法开拆他人信件，侵犯公民通信自由权利，情节严重的，处一年以下有期徒刑或者拘役。而国外网络隐私权的保护区分为两种基本的模式：一种以美国为代表的行业自律模式；另一种以欧盟为代表的以法律规制为主导的模式。在欧洲，目前欧盟正在制定统一的数据保护法规，将用来取代 28 个不同的欧盟成员国各自的数据保护国家法律，并有可能在 2015 年实施。在欧洲数据保护指令中将个人数据定义为： 与任何已经识别或者可识别的自然人（数据主体）有关的任何信息。可识别的个人，是指能被直接或间接识别的个体，特别是参考身份证件号码或针对其身体、生理、经济、文化或社会身份等一个或多个因素可识别的个体 [3]。在 2000 年 12 月美国商业部和欧盟签署了安全港协议，用于协调美国企业出口以及欧洲公民的个人信息数据如名字和住址等。

简单来说，企业可以尝试以下步骤进行大数据的隐私管理：

1、 定义和发现敏感的大数据，并在元数据库中将敏感大数据进行标记和分类；

2、 在收集、存储和使用个人数据时需要严格执行所在地关于隐私方面的法律法规，并制定合理的数据保留/处理政策，遵循公司法律顾问和首席隐私官的建议；

比如欧盟数据保护指令中规定个人享有遗忘权，如果个人不希望自己的信息被收集且法律也不支持组织保留这些信息时，组织需要将个人数据从系统中删除。证明需要保留此类数据的责任在组织而不是个人。同时在欧盟保护指令中明确要求组织保留个人数据需要明确的告知个人其信息如何被使用以及使用期限，并获得个人的明确同意后方可保留这些数据。

1、 在存储和使用过程中对敏感大数据进行加密和反识别处理；

比如美国联邦贸易委员会（FTC）提议针对收集的个人数据，企业需要采取合理措施进行反识别处理，在以反识别的方式保留和处理数据时需要采取措施防止再次识别个人数据，企业向第三方提供数据时要禁止第三方尝试再次识别个人数据。

1、 由于世界是互通互联的，个人数据在跨国流动过程中需要严格遵守相关国家法律规定；

2、 加强对系统特权用户的管理，防止特权用户访问敏感大数据；

3、 自动执行合规性工作流过程，保护非生产环境中的敏感大数据，监控应用程序欺诈行为，防止网络攻击。

第十七步：监管信息生命周期

信息生命周期监管是指用于信息架构、分类、收集、使用、归档、保留和删除的基于策略的系统方法。针对传统数据的信息生命周期监管，可以尝试以下步骤来实现：

● 建立信息架构；

● 建立数据库大小和存储架构基线；

● 发现业务对象；

● 对数据分类和定义服务级别；

● 归档数据和非结构化内容；

● 为管理测试数据制定策略；

● 定义合法发现电子文档的策略；

● 分析内容。

在大数据时代，过度管理数据会带来成本的极大增加，需要在满足业务需求以及法律法规的前提下制定明确的保留时间表，对实时流数据进行管理识别出哪些数据是有价值的哪些数据需要被永久保存，积极采用压缩技术进行大数据的存储从而降低存储成本，在符合业务和法律法规要求的前提下对不需要的大数据进行合理的处置。

第十八步：度量结果

通过持续的监控数据治理度量值，保证了数据的质量和信息供应链各模块更好地运行。度量值是在步骤 10 中设置的，又在之后的可选步骤中做了进一步的设置，本步骤主要针对这些度量值进行监控，及时向数据治理工作组和数据治理委员会报告进度。

IBM Cognos BI

如图 1 所示，IBM Cognos BI 平台是一个多层次结构，具体包括：展现层、Web 层、应用层和数据层，不同层次之间可以采用防火墙进行分隔。

● 展现层：包含基于 Web。Windows 客户端和移动客户端三种，通过 Web 方式用户可以访问所有的 Cognos BI 功能（即席查询、专业报表、多维分析、仪表盘和记分卡等），且不需要安装任何插件。Cognos 支持在移动终端上运行，支持 iphone、ipad、windows mobile、symbian、blackberry 等移动平台。Cognos BI 支持与 MS OFFICE 无缝融合。OLAP 分析模块 Cognos 还提供了客户端方式，用户可以灵活选择浏览器模式或客户端模式。

● Web 层：主要部署 Cognos 的网关程序，网关程序可以部署在 Apache/IBM HTTP SERVER/IIS 或其他中间件上，用户通过浏览器访问时访问请求首先发送到网关，网关再发送给 BI Server 进行处理。

● 应用层：即席查询、多维分析、报表统计、内容管理和内容服务等都被定义为服务，不同服务间通过 Cognos BI Bus（不同 Services 间通信的公共协议）进行交互。

● 数据层：包含 BI 平台支持的各种数据源（关系型数据库、多维数据仓库和企业级应用等），Cognos 支持多数据源，但是它是在统一的元数据基础之上支持的。

图1 Cognos BI 体系结构

如图 2 所示，Framework Manager 是构建 Cognos BI 应用程序的基础，负责对来自数据集市（或关系型数据库以及应用系统的数据源）的数据结构进行建模，在这些数据模型的基础之上可以进行即席查询（Query Studio）和报表统计（Report Studio）的开发，也可以基于这些模型进一步进行 OLAP 多维分析建模（使用 Transformer）并最终生成 PowerCubes 数据立方体，基于 PowerCubes 可以进行各种应用程序开发如多维分析（Analysis Studio）以及即席查询（Query Studio）和报表统计（Report Studio）等，最终的应用程序用户可以通过 Web 浏览器进行访问。

图2 Cognos 开发步骤

如图 3 所示，Cognos BI 应用程序可以使用 ROLAP 和 MOLAP（基于 Powercube）两种方式进行多维分析，简单的查询和报表也可以基于关系型模型进行。

图3 Cognos BI 应用程序层次结构

IBM SPSS Modeler

数据挖掘（Data Mining）也被称为数据采矿，通过对海量历史数据进行建模和搜索，以便从中发现隐藏其中的有特殊关联性或有价值的潜在信息以及模式等。数据挖掘引擎则是提供数据挖掘建模和评估的工具，通常提供可视化数据准备、建模、评估和部署，引擎内部包含丰富的数据挖掘模型。在数据挖掘之前需要明确挖掘的目标以及成功标准（包括主观标准和客观标准），以便建模完成后进行评估；建模过程中需要防止过滤训练造成预测不准现象；另外还需要清楚，数据挖掘有其适用的范围，不是无所不能的，需要尽量避免出现数据捕捞或数据挖泥（Data dredging，Data fishing）现象，因为很多数据之间总会有碰巧情况存在，数据挖泥通常指挖掘出实际上不存在的但看起来不错的模式，比如预测下一期彩票中奖号码等。

如图 4 所示，根据 CRISP-DM（CRoss-Industry Standard Process for Data Mining，跨行业数据挖掘标准流程），预测模型构建一般包含六个步骤：商业理解、数据理解、数据准备、建立模型、模型评估和部署发布，其中的箭头表示这些阶段间最重要和最频繁使用的依赖关系。CRISP-DM 模型比较灵活，可根据需要灵活进行选择，比如银行打算进行反洗钱监测，则很多情况下需要在没有具体建模目标的情况下对海量数据进行筛选，此时重点是数据探索和数据展现为主而不是建模，以便揭示可以的财务数据模式。更多内容请参考 IBM SPSS Modeler CRISP-DM 帮助。

图4 CRISP-DM 流程

IBM SPSS Modeler（以下简称 Modeler）是业内领先的数据挖掘工具，由一系列组件（工具）构成，通过使用这些工具企业可以快速建立预测性模型并应用于商业活动，从而改进决策过程。Modeler 是参照 CRISP-DM 模型设计而成，支持从数据到更优商业成果的整个数据挖掘过程，提供了各种借助机器学习、人工智能和统计学的建模方案。通过建模选项板中的方法，用户可以根据数据生成新的信息以及开发预测模型。每种方法各有所长，可以通过试用多种方法以及方法间的嵌套、加权外加评估等解决特定类型的问题。使用 Modeler 进行预测分析，通过对当前条件和未来事件进行可靠的推理，从而将数据转化为有效的措施。

SPSS Modeler 有两个版本：SPSS Modeler Professional 和 SPSS Modeler Premium。两个版本都可以通过图形化的方式进行各种数据交互从而了解数据、通过对各种数据源支持实现数据准备、集成各种算法、交互式模型和方程浏览器等进行建模和评估、通过 SQL 或 PMML（针对预测模型的基于 XML 的标准格式）导出模型或利用 IBM SPSS 协作和部署服务实现创新分析管理、流程自动化和部署功能等，共同包含的算法有：

● 异常检测 － 使用一种基于群集的算法检测不寻常的记录

● Apriori － 带有高级评估功能的流行关联发现算法

● 贝叶斯网络 － 图形概率模型

● C&RT、C5.0、CHAID 和 QUEST － 决策树算法，包括交互树构建

● CARMA － 关联算法，支持多个结果

● Cox 回归 － 计算某个事件的可能发生时间

● Decision List － 交互式规则构建算法

● Factor/PCA、Feature Selection － 数据简化算法

● K-Means、Kohonen、Two Step、Discriminant、支持向量机（SVM）－ 群集和分割算法

● KNN － 最近邻居建模和评分算法

● Logistic 回归 － 用于二进制结果

● 神经网络 － 多层感知器，带有逆向传播学习法和径向基本函数网络

● 回归、线性、GenLin（GLM）、广义线性混合模型（GLMM）－ 线性方程建模

● 自学响应模型（SLRM）－ 带增量学习功能的贝叶斯模型

● Sequence － 顺序关联算法，用于对顺序敏感的分析

● 支持向量机（Support Vector Machine）－ 准确建模广泛数据集的高级算法

● 时间序列 － 生成并自动选择时间序列预测模型

SPSS Modeler Premium 在数据准备、对特定文本的了解和准备工作和文本链接分析等方面有很多增强，具体可以参考 IBM 官方网站。

另外，SPSS Modeler 服务器版还具有以下独特的特性：

● 使用领先的数据库技术，通过数据库内挖掘在数据库中创建模型，并充分利用高性能的数据库实现。

● 通过 SQL 推回功能来推动数据转换，并将建模算法直接选入到运行数据库中。

● 通过 IBM SPSS Modeler Server Scoring Adapter 在数据库内对数据评分，显著提高性能。

● 利用高性能硬件（包括 IBM System z 机器）更快实现解决方案，通过并行执行流和多个模型实现更好的 ROI。

● 通过安全套接字层（SSL）加密，在 SPSS Modeler 客户端和 SPSS Modeler 服务器之间安全地传输敏感数据。

● 针对 IBM InfoSphere 的数据库内挖掘算法：关联、群集、决策树、Logistic 回归、Naive Bayes、回归、序列、时间序列。

● 针对 IBM Netezza 的数据库内挖掘算法：Bayes Net、决策树、分群法、广义线性、K-Means、KNN、线性回归、Naive Bayes、PCA、回归树、时间序列。

● 针对 Microsoft SQL 服务器的数据库内挖掘算法：关联规则、群集、决策树、线性回归、Naive Bayes、回归、神经网络、序列群集、时间序列。

● 针对 Oracle 的数据库内挖掘算法：自适应贝叶斯、Apriori、人工智能（AI）、决策树、一般线性模型（GLM）、KMeans、最小描述长度（MDL）、Naive Bayes、非负矩阵分解、O-Cluster（正交分区群集）、支持向量机。

通过 IBM SPSS Analytic Server（IAS），实现与 Hadoop 的整合

如图 5 所示，通过 IBM SPSS Analytic Server（IAS），用户可以方便的在 SPSS Modeler 客户端或者 SPSS Analyitc Catalyst 中基于 Hadoop 中的数据进行数据挖掘建模。IBM SPSS Analytic Server 是处于客户应用程序和 Hadoop 集群中间的数据分析引擎。用户通过使用 SPSS Modeler 客户端或者 SPSS Analyitc Catalyst，将各种分析请求发送给 SPSS Analytic Server，SPSS Analytic Server 将协调作业将其运行在 Hadoop 集群并将结果返回给客户端应用程序。

图5 IAS 体系结构

通过 SPSS Modeler 和 Cognos BI 协作，实现深入的分析洞察

通过运营分析（Cognos BI），企业所有用户可以发现大量有价值信息，通过定制的页面各种用户都可以在适当的时间获得合适的信息，通过记分卡和仪表盘，企业各级管理人员可以掌控业务进度，通过各种统计报表、即席查询、离线报表决策者可以深入了解业务状况，通过 Cognos Mobile 用户可以以移动方式访问各种报表和查询，通过协作功能，企业各业务条块人员可以紧密结合与协作。运营分析为用户制定下一步规划提供了支持。预测分析（SPSS Modeler）通过对过去海量数据进行建模和探索，找出过去未知的潜在的规律和模式，通过预测未来可能发生的事件为用户提供预测能力。通过将预测分析和运营分析相结合，从而实现业务分析洞察的基础上增加预测未来的能力，为企业更好的决策提供帮助，获取深入的分析洞察。比如银行业务经理通过记分卡和仪表盘发现一些银行的理财产品销售量在不断下降，分析报告显示，部分客户选择了其他银行的理财产品，通过使用 SPSS Modeler 进行客户流失分析，找出客户流失的关键因素以及可能流失的高价值客户，从而制定合理的客户维护挽留计划，降低高端客户流失率，另一方面通过交叉销售和提升销售，进一步扩展理财产品的销售量，从而提高银行营收。

IBM Guardium

IBM Guardium 是解决整个数据库安全与合规周期问题的解决方案，其对数据库的性能影响几乎为零，不需要依赖数据库本地日志或审计工具，也不需要对数据库做任何变更，避免了传统数据库审计方式对数据库性能的影响。IBM Guardium 采用统一的 Web 控制台、后端数据存储和工作流自动化系统，可以方便的寻找和分类企业数据库中的敏感信息，评估数据库的漏洞和配置缺陷，确保配置已锁定和变更追踪，获得对所有数据库活动细粒度化的 100%可视性，监控和执行各项安全策略，自动化整合合规审计流程，创建单一集中的审计库和易扩展至分布到世界各地的数据中心，实现从保护单个数据库到保护成千上万个数据库的转变。

图6 Guardium 统一解决方案

如图 6 所示：IBM Guardium 是当前解决整个数据库安全与合规/审计问题的唯一方案，从四个方面满足了企业数据安全及审计要求：

● 发现&分类：在一个个业务竖井中，分散着大量的敏感数据，这些敏感数据通常不容易被发现和保护，为了保护敏感信息，控制风险，满足合规要求，企业需要能够发现和分类这些敏感数据。Guardium 提供数据库自动搜索和信息分类功能，识别敏感数据的存储位置，并可以定制分类标签来执行特定的安全策略以便保护敏感信息。

● 评估&加固：通过扫描整个数据库体系结构，搜索漏洞，并基于实时和历史数据对数据库安全状态进行评估。Guardium 预置了一个综合测试库（基于业界最佳实践和特定平台漏洞），可通过订阅服务定期更新，并支持自定义测试。评估模块会标记与合规相关的漏洞。

● 审计&报表：可帮助用户创建覆盖所有数据库活动的连续、详细的追踪记录，并进行实时的语境分析和过滤从而实现主动控制，生成细粒度的审计记录。生成的结果报表使所有数据库活动详细可见，而且由于审计发生在数据库服务器之外，不会对数据库服务器造成额外的性能压力。

● 监控&执行：通过可定制的细粒度的实时数据库安全和变更控制策略防止特权用户进行非法或可疑访问，抵挡欺诈用户和外来者的入侵，识别使用通用账号（透过应用系统）更改后天数据库的应用账号行为。该解决方案无需 DBA 参与，而是由信息安全专员负责维护。

在 Guardium 中，新增了对 Hadoop 的支持，通过使用 IBM Guardium，用户可以获取有针对性的、可操作的信息，极大地简化了用户审计过程。通过定义安全策略，用户可以指定需要保存什么数据以及如何应对策略违规。数据事件直接写入 Guardium 收集器，特权用户甚至都没有机会访问并隐藏他们的踪迹。开箱即用的报告可以让用户立即开始快速运行 Hadoop 监控，而且这些报告可以很容易通过定制来符合用户的审计需求。IBM Guardium 主要使用探测器（称为 S-TAP，用于软件）对 Hadoop 进行监控，无需依赖 Hadoop 的审计日志即可监控所有相关操作，无需对系统软件或应用程序进行任何更改。IBM Guardium 对 Hadoop 监控的事件包括：

● 会话和用户信息。

● HDFS 操作 – 命令（cat、tail、chmod、chown、expunge，等等）。

● MapReduce 作业 - 作业、操作、权限。

● 异常，比如授权故障。

● Hive / HBase 查询 - 改变、计数、创建、删除、获取、放置、列出，等等。

InfoSphere Optim Data Growth Management

归档是一个自动化智能流程，可将依然存在价值但却不使用或不经常访问的数据放置在合适的存储层中，同时，还能够在一个特定的保持时段中保存、搜索和检索数据，满足合规性、业务价值或文化/传统需求。IBM Optim 数据归档解决方案可以帮助企业对数据进行自动分类的存储资源管理并构建合理的分层的存储硬件环境，提供先进的数据检索和分析工具对不同类型的数据进行处理，提供数据的可用性和管理效率，从根源上解决数据增长问题。Optim Data Growth Management 通过归档事务处理的历史记录，并以安全和成本节省的方式存储这些记录，减少了生产库的数据量，提高了生产系统的速度，其体系结构如图 7 所示：

图7 InfoSphere Optim Data Growth Management 体系结构

InfoSphere Optim Test Data Management

传统的测试数据管理方法有克隆（Cloning）和复制（由几条数据复制成几百万条）等，由于质量管理、测试和开发等都需要测试数据，采用克隆的方式会加大 DBA 的工作负担，耗时、 直接影响开发测试进度，消耗大量系统资源，生产系统往往无法承担在线备份所带来的系统开销，同时在克隆过程中还存在对敏感数据的保护不足等问题。采用复制的方式简单易行，缺点是数据无法准确反映业务特点，测试结果和实际有出入。IBM Optim 测试数据管理和隐私数据保护解决方案提供一系列的工具和服务，从生产环境抽取出符合业务逻辑的数据集合，帮助用户迅速构建大小适中的测试、开发、培训环境，并保护隐私数据的安全性。

● 提供条件与抽样等方式，获取大小合适的的测试数据集。

● 在数据抽取、加载或离线阶段，均可制定变形规则，实现隐私数据的可靠保护，并确保变形后数据的完整性。

● 抽取或变形后的数据可加载到任意类型的目标数据库中（如从 Oracle 中抽取数据，变形后，在 DB2 中加载、创建原始数据环境）。

● 通过格式化压缩文件保留数据的各种版本（结构与 DDL），可实现在异构环境中恢复或获取数据定义。

● 格式化压缩文件独立存储，可在测试、开发过程中反复加载，不对生产环境造成新的压力。

Optim 测试数据管理流程如图 8 所示，除了提供的标准功能外，企业可以根据自身特点自定义管理流程：

● 测试数据的供数管理，定义数据从生产环境到测试环境的过程；

● 数据请求管理，定义了项目组申请测试数据的标准流程；

● 密钥管理，定义了数据变形算法密钥的管理过程；

● 环境准备规定测试数据加载所需准备的环境参数等等。

图8 OPTIM 测试数据管理流程

Optim 提供完善的测试数据生成，敏感数据转义、变形和转换组件，可通过一组内置变形函数实现客户敏感数据的替换、变形并保持准确语义以产生精确的测试数据集。通过对敏感信息进行变形，用户可以有效实现隐私数据保护，满足各种法规的隐私保护要求。

结束语

本文详细介绍了大数据治理统一流程参考模型第十四步“运营分析监管”、第十五步“预测分析监管”、第十六步“管理安全与隐私”、第十七步“监管信息生命周期”和第十八步“度量结果”，以及 IBM Cognos BI，SPSS Modeler，Guardium，Optim Data Growth Management 和 Optim Test Data Management 等产品介绍。

综上所述，在各行各业中，随处可见因数量、速度、种类和准确性结合带来的大数据问题，为了更好地利用大数据，大数据治理逐渐提上日程。大数据治理的核心是为业务提供持续的、可度量的价值。大数据治理人员需要定期与企业高层管理人员进行沟通，保证大数据治理计划可以持续获得支持和帮助。相信随着时间的推移，大数据将成为主流，企业可以从海量的数据中获得更多的价值，而大数据治理的范围和严格程度也将逐步上升。

参考文献

本章参考了 IBM 相关产品的信息中心、白皮书、方案建议书以及其他各种资料。

[18]

本文来源：https://www.2haoxitong.net/k/doc/489e99ce5bcfa1c7aa00b52acfc789eb162d9ed3.html