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

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

书目

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

概述.........................................................2

大数据治理系列...............................................2

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

........................................................................................................2

其次部分：元数据集成体系结构..........................19

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

第四部分：大数据治理统一流程参考模型的第四步到第九步..50

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

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

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

概述

面对我们身边每时每刻快速增长的浩大数据，因为其数量大、速度快、

种类多和精确性的特征，如何更好地利用大数据创建出有意义的价值，始

终是我们探究的重要话题。而在这之前，就须要用科学正确的方法策略对

大数据进行治理。大数据治理是指制定与大数据有关的数据优化、隐私爱

护与数据变现的政策，是传统信息治理的持续和扩展，也是大数据分析的

基础，还是连接大数据科学和应用的桥梁，因此大数据治理是大数据再创

高峰的“必修课”。下面我们将与您共享簇新出炉的大数据治理方案。

大数据治理系列

本系列共分为七个部分，围绕大数据治理统一流程参考模型，并结合

实际业务问题和IBM相应的产品解决方案绽开叙述。

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

为了更好地帮助企业进行大数据治理，笔者在IBM数据治理统一流

程模型基础上结合在电信、金融、政府等行业进行大数据治理的阅历，整

理出了大数据治理统一流程参考模型。本文主要介绍了大数据治理的基本

概念，以与结合图文并茂的方式讲解了大数据治理统一流程参考模型的前

两步：“明确元数据管理策略”和“元数据集成体系结构”内容。

大数据治理概述

（狭义）大数据是指无法运用传统流程或工具在合理的时间和成本内

处理或分析的信息，这些信息将用来帮助企业更才智地经营和决策。而广

义的大数据更是指企业须要处理的海量数据，包括传统数据以与狭义的大

数据。（广义）大数据可以分为五个类型：Web和社交媒体数据、机器对

机器（M2M）数据、海量交易数据、生物计量学数据和人工生成的数据。

•Web和社交媒体数据：比如各种微博、博客、社交网站、购物网站中

的数据和内容。

•M2M数据：也就是机器对机器的数据，比如RFID数据、GPS数据、

智能仪表、监控记录数据以与其他各种传感器、监控器的数据。

•海量交易数据：是各种海量的交易记录以与交易相关的半结构化和非

结构化数据，比如电信行业的CDR、3G上网记录等，金融行业的网

上交易记录、corebanking记录、理财记录等，保险行业的各种理赔

等。

•生物计量学数据:是指和人体识别相关的生物识别信息，如指纹、DNA、

虹膜、视网膜、人脸、声音模式、笔迹等。

•人工生成的数据：比如各种调查问卷、电子邮件、纸质文件、扫描件、

录音和电子病历等。

在各行各业中，随处可见因数量、速度、种类和精确性结合带来的大

数据问题，为了更好地利用大数据，大数据治理渐渐提上日程。在传统系

统中，数据须要先存储到关系型数据库/数据仓库后再进行各种查询和分

析，这些数据我们称之为静态数据。而在大数据时代，除了静态数据以外,

还有很多数据对实时性要求特别高，须要在采集数据时就进行相应的处

理，处理结果存入到关系型数据库/数据仓库、MPP数据库、Hadoop平

台、各种NoSQL数据库等，这些数据我们称之为动态数据。比如高铁机

车的关键零部件上装有成百上千的传感器，每时每刻都在生成设备状态信

息，企业须要实时收集这些数据并进行分析，当发觉设备可能出现问题时

与时告警。再比如在电信行业，基于用户通信行为的精准营销、位置营销

等，都会实时的采集用户数据并依据业务模型进行相应的营销活动。

大数据治理的核心是为业务供应持续的、可度量的价值。大数据治理

人员须要定期与企业高层管理人员进行沟通，保证大数据治理安排可以持

续获得支持和帮助。信任随着时间的推移，大数据将成为主流，企业可以

从海量的数据中获得更多的价值，而大数据治理的范围和严格程度也将逐

步上升。为了更好地帮助企业进行大数据治理，笔者在IBM数据治理统

一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的阅历,

整理了大数据治理统一流程参考模型，整个参考模型分为必选步骤和可选

步骤两部分。

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

如图1所示，大数据治理统一流程参考模型必要步骤分为两个方向：

一条子线是在制定元数据管理策略和确立体系结构的基础上实施全面的

元数据管理，另一条子线是在定义业务问题、执行成熟度评估的基础上定

义数据治理路途图以与定义数值治理相关的度量值。在11个必要步骤的

基础上，企业可以在7个可选步骤中选择一个或多个途径进行特定领域的

数据治理，可选步骤为：主数据监管、（狭义）大数据监管、信息单一视

图监管、运营分析监管、预料分析监管、管理平安与隐私以与监管信息生

命周期。企业须要定期对大数据治理统一流程进行度量并将结果发送给主

管级发起人。

”i6.m

安全与隔私

12.1）委濠13.1）加分析核・

12偿.

依行管理员聂樨管理员(5总

义15.被测17.依管信息

单

大

12.2）大家〉i3.2）n-

救

挺

M同l

座

11.3）实籁12.3）实篇13.3）构*AT监

首

主欧掘管理

-W-

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

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

在最起先的时候，元数据（MetaData）是指描述数据的数据，通常

由信息结构的描述组成，随着技术的发展元数据内涵有了特别大的扩展,

比如UML模型、数据交易规则、用Java,.NET,C++等编写的APIs、

业务流程和工作流模型、产品配置描述和调优参数以与各种业务规则、术

语和定义等［1］。在大数据时代，元数据还应当包括对各种新数据类型的描

述，如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知

设备数据和各种监控设备数据等的描述等。元数据通常分为业务元数据、

技术元数据和操作元数据等。业务元数据主要包括业务规则、定义、术语、

术语表、运算法则和系统运用业务语言等，主要运用者是业务用户。技术

元数据主要用来定义信息供应链(InformationSupplyChain,ISC)

各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、

依靠性等，以与存储过程、函数、序列等各种对象。操作元数据是指应用

程序运行信息，比如其频率、记录数以与各个组件的分析和其它统计信息

等。

从整个企业层面来说，各种工具软件和应用程序越来越困难，相互依

存度逐年增加，相应的追踪整个信息供应链各组件之间数据流淌、了解数

据元素含义和上下文的需求越来越剧烈。在从应用议程往信息议程的转变

过程中，元数据管理也渐渐从局部存储和管理转向共享。从总量上来看，

整个企业的元数据越来越多，光现有的数据模型中就包含了成千上万的

表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业须

要处理的数据类型越来越多。为了企业更高效地运转，企业须要明确元数

据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据

管理，并有步骤的提升其元数据管理成熟度。

为了实现大数据治理，构建才智的分析洞察，企业须要实现贯穿整个

企业的元数据集成，建立完整且一样的元数据管理策略，该策略不仅仅针

对某个数据仓库项目、业务分析项目、某个大数据项目或某个应用单独制

定一个管理策略，而是针对整个企业构建完整的管理策略。元数据管理策

略也不是技术标准或某个软件工具可以取代的，无论软件工具功能多强大

都不能完全替代一个完整一样的元数据管理策略，反而在定义元数据集成

体系结构以与选购元数据管理工具之前须要定义元数据管理策略。

元数据管理策略须要明确企业元数据管理的愿景、目标、需求、约束

和策略等，依据企业自身当前以与将来的须要确定要实现的元数据管理成

熟度以与实现目标成熟度的路途图，完成基础本体、领域本体、任务本体

和应用本体的构建，确定元数据管理的平安策略、版本限制、元数据订阅

推送等。企业须要对业务术语、技术术语中的敏感数据进行标记和分类，

制定相应的数据隐私爱护政策，确保企业在隐私爱护方面符合当地隐私方

面的法律法规，假如企业有跨国数据交换、元数据交换的需求，也要遵循

涉与国家的法律法规要求。企业须要保证每个元数据元素在信息供应链中

每个组件中语义上保持一样，也就是语义等效(semanticequivalence)o

语义等效可以强也可以弱，在一个元数据集成方案中，语义等效(平均)

越强则整个方案的效率越高。语义等效的强弱程度干脆影响元数据的共享

和重用。

本体(人工智能和计算机科学)

本体(Ontology)源自哲学本体论,而哲学本体论则是源自哲学中“形

而上学”分支。本体有时也被翻译成本体论，在人工智能和计算机科学领

域本体最早源于上世纪70年头中期，随着人工智能的发展人们发觉学问

的获得是构建强大人工智能系统的关键，于是起先将新的本体创建为计算

机模型从而实现特定类型的自动化推理。之后到了上世纪80年头，人工

智能领域起先运用本体表示模型化时间的一种理论以与学问系统的一种

组件，认为本体（人工智能）是一种应用哲学。

最早的本体（人工智能和计算机科学）定义是Neches等人在1991

给出的：“一个本体定义了组成主题领域的词汇的基本术语和关系，以与

用于组合术语和关系以与定义词汇外延的规则”。而第一次被业界广泛接

受的本体定义出自TomGruber,其在1993年提出：“本体是概念化的

显式的表示（规格说明）"。Borst在1997年对TomGruber的本体

定义做了进一步的扩展，认为：“本体是共享的、概念化的一个形式的规

范说明”。在前人的基础上，Stude在1998年进一步扩展了本体的定义,

这也是今日被广泛接受的一个定义：“本体是共享概念模型的明确形式化

规范说明”。本体供应一个共享词汇表，可以用来对一个领域建模，具体

包括那些存在的对象或概念的类型、以与他们的属性和关系［2］。一个简洁

的本体示例发票概念与其相互关系所构成的语义网络如图2所示：

邮电通讯业定额发票

(50元)、

50元

是

发票w是，

♦\文化体育业定额发票

(50/C)

是

济南市服务业机打发票济南市服务业定额发票

(卷式)/

所在城市

济南市/

图2简洁本体(发票)示例

随着时间的推移和技术的发展，本体从最起先的人工智能领域渐渐扩

展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来

越多的学科。与哲学本体论类似，本体(人工智能和计算机科学)依靠某

种类别体系来表达实体、概念、事务与其属性和关系。本体的核心是学问

共享和重用，通过削减特定领域内概念或术语上的分歧，使不同的用户之

间可以顺畅的沟通和沟通并保持语义等效性，同时让不同的工具软件和应

用系统之间实现互操作。

依据探讨层次可以将本体的种类划分为“顶级本体”(top-level

ontology)、应用本体(applicationontology)N领域本体(domain

ontology)和任务本体(taskontology),各个种类之间的层次关系如图

3所示。

图3本体层次关系

・顶级本体，也被称为上层本体(upperontology)或基础本体

(foundationontology),是指独立于具体的问题或领域，在全部

领域都适用的共同对象或概念所构成的模型，主要用来描述高级别

且通用的概念以与概念之间的关系。

•领域本体是指对某个特定的领域建模，显式的实现对领域的定义，

确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等,

供应对该领域学问的共同理解。领域本体所表达的是适合自己领域

的术语的特定含义，缺乏兼容性，因而在其他领域往往不适用。在

同一领域内，由于文化背景、语言差异、受教化程度或意识形态的

差异，也可能会出现不同的本体。很多时候，随着依靠领域本体系

统的扩展，须要将不同的领域本体合并为更通用的规范说明，对并

非基于同一顶级本体所构建的本体进行合并是一项特别具有挑战的

任务，很多时候须要靠手工来完成，相反，对那些基于同一顶级本

体构建的领域本体可以实现自动化的合并。

•任务本体是针对任务元素与其之间关系的规范说明或具体说明，用

来说明任务存在的条件以与可以被用在哪些领域或环境中。是一个

通用术语的集合用来描述关于任务的定义和概念等。

・应用本体：描述依靠于特定领域和任务的概念与概念之间的关系，

是用于特定应用或用途的本体，其范畴可以通过可测试的用例来指

定。

从具体程度上来分，本体又可以分为参考本体（reference

ontologies）和共享本体（shareontologies）,参考本体的具体程度高，

而共享本体的具体程度低。

本体（哲学）

哲学中的本体（ontology）也被称为存在论，源自哲学中“形而上学”

分支，主要探讨存在的本质，也就是存在的存在。英文ontology事实上

就是来源于希腊文“ov”（存在）和“入6丫0勺”（学科）的组合。本体是

由早期希腊哲学在公元前6世纪到公元前4世纪提出的“始基”延长出来

的。始基（Principle,又称本原）最早由泰勒斯（米利都学派）最早提出

来，认为万物由水而生，其学生阿那克西曼德认为万物由一种简洁的原质

组成，该原质不是水［3］。而毕达哥拉斯（学派）认为“万物都是数”，数

不仅被看作万物的木原，而且被看作万物的原型、世界的木体°后来巴门

尼德（爱利亚学派）提出了“存在”的概念，认为存在才是唯一真正存在

的真理，其创建了一种形而上学论证方式，之后的哲学始终到近时期为止,

都从巴门尼德处接受了其“实体的不行毁灭性”。苏格拉底继承了巴门尼

德的存在概念，主见“真正的善”并完善了巴门尼德弟子芝诺的辩证法，

其学生柏拉图提出了“理念论”，认为只要若干个个体拥有一个共同的名

字，它们就有一个共同的理念或形式。亚里士多德（柏拉图学生）总结了

先哲们的思想，完成了《形而上学》，并将本体总结为：对世界上客观存

在事物的系统的描述，即存在论，也就是最形而上学的学问。形而上学不

是指孤立、静止之类的意思，而是指超越具体形态的抽象意思，是关于物

质世界最普遍的、最一般的、最不具体的规律的学问。

其次步：元数据集成体系结构

在明确了元数据管理策略后须要确定实现该管理策略所需的技术体

系结构，即元数据集成体系结构。各个企业的元数据管理策略和元数据管

理成熟度差别较大，因此元数据集成体系结构也多种多样。大体上元数据

集成体系结构可以分为点对点的元数据集成体系结构、中心辐射式元数据

体系结构、基于CWM（CommonWarehouseMetaModel,公共仓库

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

中心存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构

和层次/星型元数据集成体系结构等。

针对信息供应链中不同的组件，为了实现跨组件的元数据交换和集

成，最起先人们接受点对点的方式进行，也就是每一对组件之间通过一个

独立的元数据桥（metadatabridge）进行元数据交换，桥一般是双向的

能够理解两个方向的元数据映射［4］。点对点的元数据集成体系结构帮助用

户实现了跨企业的元数据集成和元数据交换，对提升信息化水平供应了巨

大帮助。这种体系结构在应用过程中，也暴露了很多问题，比如元数据桥

的构建工作量和耗时都特别大，对中间件厂商、应用厂商、集成商和用户

来说都是一个巨大的挑战，而且构建元数据桥还必需具有全部者的元数据

模型和接口的具体信息。构建完成的桥很多时候无法在构建其他元数据桥

时进行重用，因此开发和维护费用大幅度增加，用户投资回报率(ROD

不高。以动态数据仓库为例，其点对点的元数据集成体系结构具体如图4

所示，信息供应链各组件之间的空心箭头表示全部的数据流，实心箭头表

示不同的元数据桥和与之关联的元数据流。

Bridges

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

通过运用中心元数据存储库(centralmetadatarepository)取代

各个工具软件和应用程序之间的点对点连接方式，改成中心元数据存储库

与各个工具软件和应用程序实现元数据交换的访问层(也是一种桥)，可

以有效降低总成本，削减建立点对点元数据桥的工作，提高投资回报率。

信息供应链各组件可以从存储库访问元数据，不必与其他产品进行点对点

交互。这种运用中心元数据存储库方式进行元数据集成的方式就是中心辐

射式元数据体系结构(hub-and-spok6metadataarchitecture),具体

如图5所示。由于特定的元数据存储库是围绕其自身的元模型、接口和交

付服务建立的，所以仍须要建立元数据桥实现与ISC各组件的相互访问。

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

接受模型驱动的元数据集成方法(比如运用CWM)可以有效降低元

数据集成的成本和困难度，无论点对点元数据集成体系结构还是中心绵射

式元数据集成体系结构都可以因此受益。在点对点体系结构中，通过运用

基于模型的方法可以不必在每一对须要集成的产品之间构建元数据桥，每

个产品只须要供应一个适配器(adapter)即可实现各个产品之间的元数

据交换，适配器既了解公共的元模型也了解本产品元模型的内部实现。如

图6所示，基于CWM模型驱动点对点元数据集成体系结构运用通用元模

型，不再须要在各个产品间建立元数据桥，在各个产品之间通过适配器实

现了语义等价性。

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

如图7所示，在基于模型驱动（比如CWM）的中心辐射式元数据体

系结构中，中心存储库包含公共元模型和整个领域（domain）用到的该

元模型的各个实例（模型）、存储库自身元模型与其实例、理解元模型（公

共元模型和自身元模型）的适配器层，当然存储库也可以干脆实现公共元

模型的某些内部表示。

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

如图8所示，这种体系架构是基于CWM模型驱动的中心存储库元数

据集成体系结构的一个变种，两个中心辐射式的拓扑结构通过各自的元数

据存储库连接起来，也被称为分布式(Distributed)或联邦(Federated)

体系结构。两个元数据存储库之间通过元数据桥连接，两个存储库运用相

同的元模型和接口，也可以运用不同的元模型和接口。建立分布式元数据

集成体系结构的缘由有很多种，比如企业基于多个区域单独部署自己的应

用，每个区域有自己的数据中心。

CMM元数据交帙（基于

元欧格

存场对2

CMM元数据交换（基F

XIV1L或标准API调心—

/一星府

（多雄分析

投也统计

、,

飞次策普理,

（MDM^Hl

r创新吨用

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

如图9所示，这种体系结构是分布式体系结构的变体，根存储库实现

了元模型的公共部分（横跨整个企业），叶子存储库实现了一个或多个特

定的公共元模型子集，并只保存这些自己所对应的元数据实例。特定客户

可以主要访问其感爱好的元数据所在的叶子存储库，也可以访问其它叶子

存储库和根存储库。这种体系结构被称为层次或星型拓扑结构。

结束语

本文具体介绍了大数据治理的基本概念和统一流程参考模型，并阐述

了该模型的第一步“明确元数据管理策略”和其次步“元数据集成体系

结构”等内容。在第一步“明确元数据管理策略”中讲解并描述了元数据

的基本概念以与本体在人工智能/计算机科学和哲学中的含义。在其次步

“元数据集成体系结构”讲解并描述了元数据集成体系结构的六种示例，

分别为：点对点的元数据集成体系结构、中心辐射式元数据体系结构、基

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

中心存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构

和层次/星型元数据集成体系结构。在本系列文章的下一部分将接着介绍

大数据治理统一流程参考模型其次步“元数据集成体系结构”，具体包括

元模型、元-元模型、公共仓库元模型（CWM）、CWM发展史、OMG的

模型驱动体系结构(ModelDrivenArchitecture,MDA)o

参考文献

[1]DavidFrankelConsulting,UsingModeIDriven

Architecture™t©ManageMetadata”，P3;

[2]FredrikArvidssonandAnnika

Flycht-Eriksson,2008,0ntologiesl,“Anontologyprovidea

sharedvocabulary,whichcanbeusedtomodeladomain,that

is,thetypeofobjectsand/orconceptsthatexist,andtheir

propertiesandrelations”;

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

哲学史＞＞；

[4]JohnPoole,DanChang,DouglasTolbertandDavid

Mellor,2002,CommonWarehouse

Metamodel,p18-32,p180-202;

[5]本系列文章参考了SunilSoares编写的《TheIBMData

GovernanceUnifiedProcess»和«BigdataGovernance))书中内

容。

其次部分：元数据集成体系结构

在明确了元数据管理策略后须要确定实现该管理策略所需的技术体

系结构，即元数据集成体系结构。元数据集成体系结构涉与到多个概念，

如元模型、元-元模型、公共仓库元模型（CWM）等，本部分将接着介绍

大数据治理统一流程参考模型其次步“元数据集成体系结构”的相关内

容。

在本系列的第一篇文章中，我们主要介绍了大数据治理的基本概念和

统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和

其次步“元数据集成体系结构”的六种示例等内容。大数据治理统一流程

参考模型的其次步是“元数据集成体系结构”，具体包括元模型、元-元模

型、公共仓库元模型（CWM）、CWM发展史、OMG的模型驱动体系结

构（ModelDrivenArchitecture,MDA）本文将对元数据集成体系结构

包含的各种模型绽开叙述。

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

元模型（Metamodel）

模型（Model）是用来描述特定的系统、过程、事物或概念的精确而

抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的

模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该

描述精确地描述了数据。元模型（Metamodel）也就是模型的模型（或

者元-元数据），是用来描述元数据的模型。

下面基于关系型表实体-关系（ER）模型举例说明什么是元模型。如

图1所示，一个简洁的关系型表元模型描述了如何定义一个关系型表，规

定了每个表必需有一个名字（字符串），一个表可以有1到多个列，每个

列必需有一个名字（字符串）和数据类型（字符串）:

图1简洁关系型表元模型

假如要创建一个关系型表模型，基于该表元模型创建一个实例即可，

比如创建一个常见的雇员表Employees表模型，具体如图2所示，

Employees表包含6个列，分别是编号、姓、名字、部门编号、经理编

号和职位编号。

«Entity»

Employees

+ID:Integer

+First_name:String

+Last_name:String

+DepartJD:Integer

+ManagerJD:Integer

+JobJD:Integer

图2Employees表实例

比如在DB2中创建employees表,可以很简洁的从employees表

模型中得到相应的DDL语句，执行DDL语句时DB2会生成描述

employees表的内部元数据并存储在书目（DB2内部的元数据存储库）

中。

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

Createtableemployees(

Idintegernotnull,

First_nameStringnotnull,

Last_nameStringnotnull,

Depart」DIntegernotnull,

ManagejIDIntegernotnull,

JobJDIntegernotnull

)

同样基于图1简洁关系型表元模型创建另一个实例department表模

型。department表包含2个列，分别是编号和部门名称，具体如图3所

示。由于department表模型和employees表模型都是基于相同的公共

元模型，其它工具和应用程序软件(了解关系型表的公共元模型)可以很

简洁理解department表和employees表，因为它们都是同一个元模型

的实例。其它工具或应用程序通过调用导入映射(importmapping)将

该department表模型或employees表模型翻译成自己内部的元数据实

例。同样，也可以将该软件内部元数据翻译成一个与平台无关的形式化模

型，也就是导出映射(exportmapping),以便其他软件运用其专有的元

数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结

构⑴。

«Entity»

Department

+ID:Integer

+name:String

图3department表实例

元-元模型（Meta-metamodel）

元-元模型就是元模型的模型，有时也被称为本体（ontology）,是模

型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定

元模型必需依照肯定的形式化规则来建立，以便全部的软件工具都能够对

其进行理解。

元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模

型的实例，元模型比元一元模型更加精细，而元一元模型比元模型更加抽象。

元数据（模型）则是一个元模型的实例，遵守元模型的规定和约束。用户

对象（或用户数据）则是元数据（或者称为模型）的实例。元数据层次结

构具体如表1所示，共分为4层，最高层L3是元-元模型，之下是L2元

模型和L1模型/元数据，最底层是L。用户对象/用户数据：

表1元数据层次结构

元层次名称示例

L3元-元模型元类、元属性、元操作

L2元模型类、属性、操作、构件

L1模型/元数据实体-关系(ER)图

交易数据、ODS数据、数据仓

L0用户对象/用户数据库数据、数据集市数据、数据

中心数据等

公共仓库元模型(CWM)概述

公共仓库元模型(CommonWarehouseMetaModel,CWM)是被

对象管理组织OMG(ObjectManagementGroup)接受的数据仓库和

业务分析领域元数据交换开放式行业标准，在数据仓库和业务分析领域为

元数据定义公共的元模型和基于XML的元数据交换(XMI)。CWM作为

一个标准的接口，可以帮助分布式、异构环境中的数据仓库工具，数据仓

库平台和数据仓库元数据存储库之间轻松实现数据仓库和业务分析元数

据交换。CWM供应一个框架为数据源、数据目标、转换、分析、流程和

操作等创建和管理元数据，并供应元数据运用的世系信息［2］。

CWM是一个基于模型驱动方法的完整地描述数据仓库和业务分析领

域的元模型，供应构建元数据所需的语法和语义，由若干个不相同又紧密

相关的子元模型组成。CWM模型的目的是最大限度的重用对象模型

(ObjectModel,UML的一个子集)，并在可能的地方共享通用模型结构。

如图4所示，CWM元模型运用包(package)和层次来简化管理的困难

度并便于理解，共包含21个单独的包，这些包被分为5个层次。对象模

型层包含定义基本元模型的概念、关系和约束的包，其它CWM包都须要

用到这些定义，对象模型层的包构成了其它CWM包所须要的基本元模型

服务的全部集合。对象模型层主要包括核心包(Corepackage)、行为包

(Behavioralpackage)>关系包(Relationshipspackage)和实例包

(Instancepackage)o

•数据源层(DataResources):主要描述CWM元数据交换中既可作

为源又可以作为目标的数据源的结构，本层含有的元模型主要描述面

对对象的数据库和应用、关系型数据库、面对记录的数据源(如文件、

记录数据库管理系统等)、多维数据库和XML数据源等。对于面对对

象数据源，CWM一般状况下重用基本的对象模型(位于对象模型层)，

假如该数据源具有对象模型层无法处理的一些特征和功能时，可以通

过定义一个扩展包来解决。

•数据分析层(DataAnalysis):本层含有的元模型主要描述数据转换、

在线分析处理OLAP、数据挖掘、信息可视化和业务术语等。

•仓库管理层(WarehouseManagement):本层含有的元模型主要描

述数据仓库处理和数据仓库操作。

ManagementWarehouseProcessWarehouseOperation

DataInformationBusiness

AnalystsTransformationOLAP

MiningVisualizationNomenclature

ResourceObjectModelRelationalRecordMultidimensionalXML

Keys

BusinessTypeSoftware

FoundationDataTypesExpressionand

InformationMappingDeployment

Indexes

ObjectModel

图4CWM1.1元模型

CWM1.1是在2003年3月发布的，与之相关的OMG组织规范还

有MOF、UML和XMIoCWM运用统一建模语言（UML）定义公共元

数据的模型（CWM元模型），运用可扩展标记语言（XML）生成CWM

元数据交换规范（也就是XML元数据交换，XMI）,运用CORBA接口定

义语言（IDL）为访问CWM元数据生成编程语言API的规范（依靠MOF

到IDL的映射）。

UML是一种规范化、可视化、描述明确、结构化和文档化的定义分

布式对象系统的图形化语言。1996年，业内三种最杰出的面对对象建模

语言:GradyBooch的Booch方法、IvarJacobson的面对对象软件工

程（OOSE）和JimRumbaugh的对象建模技术（OMT）被统一起来发

布，也就是UML0.9o2011年，UML2.4.1发布。CWM依靠于UML

规范的前三个部分，即UML语义、UML符号向导和对象约束语言规范。

UML语义定义UML元模型的语义，UML元模型是层次结构并以包为单

位进行组织，每个包依据抽象语言（运用类图）、结构良好规则（接受OCL）

和语义（接受英语）来定义。UML符号指定表达UML元模型语义的图形

语法（例如类图）。对象约束语言规范定义对象约束语言（OCL）的句法、

语义和语法，0cL是一种表述约束的形式化语言［3］。

•构造块和结构良好规则：UML供应了组成构造块和结构良好规则的面对

对象建模语言，基本的构造块包括模型元素（如类、对象、接口、组件、

用例等）、关系（如关联、泛化、依靠等）和图（如类图、对象图、用例

图等）等。

•UML可以为一个系统进行不同方面的建模，比如结构建模（又包括运用

类图和对象图的静态结构建模、运用组件图和部署图实现建模）、用例建

模和行为建模等。元数据建模只须要静态结构建模，静态结构的核心元素

是类、对象、属性和操作。

•UML用包来将模型元素组织成语义上相关联的分组，每个包拥有其自己

的模型元素，每个模型元素不能同时被多个包拥有。

UML在CWM中主要作为三种角色出现⑷：

1、UML作为和MOF等价的元-元模型。UML,或者部分对应MOF

模型、UML符号和OCL的UML分别被用作建模语言、图形符号和约束

语言，用来定义和表示CWM。

2、UML作为基础元模型。对象模型层（ObjectModel）与UML关

系亲密，是UML的一个子集。

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

元对象框架（MetaObjectFramework,MOF,本文以2.4.1版本

为例）是一个以独立于平台的方式定义、操作、集成元数据和数据的、可

扩展、模型驱动的分布式对象集成框架。此框架支持各种类型的元数据，

还可以依据需求添加新类型的元数据。MOF包括MOF模型（定义建立

元模型的建模元素和运用规则）、MOF反射接口（允许程序在不运用元模

型指定接口时对元数据进行各种操作）和MOF至ijIDL的映射（定义MOF

模型定义的元模型到CORBAIDL之间的标准映射）。MOF模型是以UML

的概念和结构为基础，尤其是以UML的静态结构模型和模型管理为基础。

MOF模型没有定义自己的图形符号和约束语言，而是接受UML的图形符

号和OCL来实现。MOF模型也是层次结构，并以包为单位进行组织。

MOF支持各种类型的元数据，接受四层元数据体系结构（也就是

OMG元数据体系结构）[5],具体如表2所示，该体系架构将元数据（Ml）

视同为数据（M0）,并对之进行形式化建模（即元模型，M2）o元模型（M2）

运用元-元模型（M3）所供应的元建模结构来表示。表2表明MOF模型

（元-元模型）、UML元模型、用户模型和用户对象/数据之间的关系，

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

描述示例

MOF,i.e.thesetof

MMOFClass,MOFAttribute,MOF

constructsusedto

3Association,etc.

definemetamodels

Metamodels,consistinUMLClass,UMLAssociation,UML

MgofAttribute,UMLState,UML

2instancesofMOFActivity,etc.CWMTable,CWM

constructs.Column,etc.

Models,consistingofClass<<Customer,,,ClassuAccount

Minstances

1ofM2metamodelTable

constructs.aEmployee,,,Table,Vendor”，etc.

MObjectsandCustomerJaneSmith,CustomerJoe

0data,i.e.instancesofJones,Account

Mlmodelconstructs2989,Account2344,Employee

A3949,Vendor78988,etc.

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

提交了公共仓库元数据交换（CommonWarehouseMetadata

Interchange,CWMI）征求看法稿（RFP）,同年9月OMG发布了该征

求看法稿，经过8个公司（IBM、Unisys、Oracle、Hyperion、UBS、

NCR>Genesis和DimensionEDI）2年半的努力和协作，OMG于2001

年4月正式接受CWM为标准。

在CWM发展的同时，其他一些元数据标准的制定也在进行中。最早

在1993年，电子信息组织就发布了计算机协助工程数据交换格式(CASE

DataInterchangeFormat,CDIF)并得到了肯定的认可。1995年10

月，元数据联盟(MetaDataCoalition,MDC)成立，并与1996年4

月发布了元数据交换规范1.0(MetaDataInterchangeSpecification,

MDIS),与CWM相比，MDIS涉与的范畴少很多，且其规范和交换语言

都是自身独有的。此时微软也在和其他一些合作者一起开发开放信息模型

(OpenInformationModel,OIM),该模型于1996年10月成形，接

受UML作为其规范语言。1998年11月，微软加入MDC并提交OIM

标准，1999年7月MDC发布了OIMvl.O版本，由此业内面临着两种

元数据集成规范的竞争局面，之后考虑到业内对CWM的认可，MDC于

2000年9月确定终止其OIM后续工作，将其元数据标准归入到OMG中,

从今CWM影响力和范围持续扩大并得到了业内的统一认可。

OMG的模型驱动体系结构(ModelDrivenArchitecture,MDA)

OMG组织成立不久制定了对象管理体系结构(ObjectManagement

Architecture,OMA)参考模型，描述了OMG规范所遵循的概念化的

基础结构。OMA是由对象恳求代理(ObjectRequestBroker,ORB)>

对象服务、公共设施、域接口和应用接口等几个部分组成，其核心是对象

恳求代理(ORB)。对象恳求代理(ORB)是公共对象恳求代理体系结构

(CommonObjectRequestBrokerArchitecture,CORBA)的核心

组件，供应了识别和定位对象、处理连接管理、传送数据和恳求通信所需

的框架结构。OMA和CORBA被定位为软件框架，用来指导基于OMG

规范的技术开发。

从1995年起先，OMG起先非正式的接受针对特定行业(“领域”，

Domain)的技术规范，为了保持扩张重点，OMG在2。。1年正式接受

其次个框架，模型驱动体系架构(ModelDrivenArchitecture,MDA)。

与OMA和CORBA不一样，MDA不是部署分布式系统的框架，而是在

软件开发中基于模型驱动的方法。为了实现MDA,OMG随后制定了一系

列标准如UML、MOF、XMI和CWM等，解决了MDA的模型建立、扩

展、交换等几个方面的问题。模型驱动体系结构源自众所周知的和长期建

立的思想：”将系统操作规范从系统利用底层平台实力的细微环节中分别

出来”。MDA供应了一种方法(基于相关工具)来规范化一个平台独立

的系统，为系统选择一个特定的实现平台，并把系统规范转换到特定的实

现平台。MDA的首要三个目标是：可移植性、互操作性和可重用性。MDA

三个视角(viewpoint)[6]分别是：

•计算无关视角(ComputationIndependentViewpoint):侧重系

统环境和系统需求；系统结构和流程细微环节被隐藏或尚未确定。

其对应的是计算无关模型(ComputationIndependentModel,

CIM)O

•平台无关视角(PlatformIndependentViewpoint)：侧重系统的

操作，同时隐藏用于特定平台的必要细微环节。其对应的是平台无

关模型（PlatformIndependentModel,PIM）,PIM是抽出技术

和具体工程细微环节之后的模型。

•平台相关视角（PlatfonnSpecificViewpoint）:结合平台无关系

视角和系统所运用的特定平台细微环节。其对应的是平台相关模型

（PlatformSpecificViewpointModel,PSM）,PSM是包含技

术和具体工程细微环节的模型。

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

图5OMG模型驱动体系架构

CWM元模型、规范以与生成的产品同MDA特别契合，从技术平台

角度来说，全部的平台相关模型（CWMXML、CWMIDL和CWMJava

等）都是自动地从平台无关模型（CWM元模型和规范）中产生的；从产

品平台角度来说，平台相关模型（比如DB2、ORACLE、SQLSERVER

等）都是人工从平台无关模型（CWM元模型和规范）中构造出来的°

结束语

本文具体介绍了大数据治理统一流程参考模型其次步“元数据集成

体系结构”的后续内容，主要包括元模型、元-元模型、公共仓库元模型

(CWM)、CWM发展史、对象管理组织OMG的模型驱动体系结构

(ModelDrivenArchitecture,MDA)0在本系列文章的下一部分将重

点介绍大数据治理统一流程参考模型的第三步：“实施元数据管理”，讲

解并描述在大数据时代如何实施元数据管理，如何运用元数据管理成熟度

模型，以与IBM在元数据管现方面的产品：业务元数据管理工具IBMInfo

SphereBusinessGlossary、业务词汇表小工具InfoSphereBusiness

GlossaryAnywhere和技术元数据管理工具InfoSphereMetadata

Workbencho

参考文献

[1]更多信息请参考：OMGModelDrivenArchitecture:;

[2]OMG,CommonWarehouseMetamodel(CWM)Specification

vl.l,P44;

[3]JohnPoole,DanChang,DouglasTolbertandDavid

Mellor,2002,CommonWarehouseMetamodel,p48-53,p58-63;

[4]OMG,CommonWarehouseMetamodel(CWM)Specification

vl.l,P45;

[5]DavidFrankelConsulting,vUsingModelDriven

Architecture™toManageMetadata”,P46;

⑹OMG,2003,MDAGuideVersion1.0.l,pl1-12,P15-16;

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

了解了元数据管理策略和元数据集成体系结构之后，企业可以依据须

要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据管

理制度进行全面的元数据管理。本部分主要介绍大数据治理统一流程参考

模型第三步“实施元数据管理”，元数据管理成熟度模型、出M元数据管

理相关工具等内容。

第三步：实施元数据管理

在明确了元数据管理策略和元数据集成体系结构之后，企业可以依据

须要选择合适的业务元数据和技术元数据管理工具，并制定相应的元数据

管理制度进行全面的元数据管理。比如可以运用IBMInfoSphere

BusinessGlossary进行业务元数据的管理，运用IBMInfoSphere

MetadataWorkbench作为元数据管理统一工具并进行图形化的元数据

分析。

大数据扩大了数据的容量、速度和多样性，给元数据管理带来了新的

挑战。在构建关系型数据仓库、动态数据仓库和关系型数据中心时进行元

数据管理，有助于保证数据被正确地运用、重用并满足各种规定。同样，

对大数据来说，元数据管理过程中出现的任何错误，都会导致数据重复、

数据质量差和无法访问关键信息等问题|1］。随着大数据技术在企业中的应

用越来越广泛，企业须要在原有的元数据管