大数据治理系列教材X95【实用优质资料】

1、大数据治理一一为业务提供持续的、可度量的价值目录 TOC o 1-5 h z HYPERLINK l bookmark0 o Current Document 大数据治理一一为业务提供持续的、可度量的价值 1 HYPERLINK l bookmark2 o Current Document 概述2 HYPERLINK l bookmark4 o Current Document 大数据治理系列2第一部分：大数据治理统一流程模型概述和明确元数据管理策略 .2 HYPERLINK l bookmark19 o Current Document 第二部分：元数据集成体系结构 15 HYPERLINK

2、 l bookmark31 o Current Document 第三部分：实施元数据管理25 HYPERLINK l bookmark39 o Current Document 第四部分：大数据治理统一流程参考模型的第四步到第九步 36第五部分：定义度量值和主数据监管 53第六部分：大数据监管和信息单一视图监管 67第七部分：分析监管、安全与隐私管理和信息生命周期监管 80概述面对我们身边每时每刻迅速增长的庞大数据，因为其数量大、速度快、种类 多和准确性的特征，如何更好地利用大数据创造出有意义的价值， 一直是我们探 索的重要话题。而在这之前，就需要用科学正确的方法策略对大数据进行治理。 大数

3、据治理是指制定与大数据有关的数据优化、隐私保护与数据变现的政策，是 传统信息治理的延续和扩展，也是大数据分析的基础，还是连接大数据科学和应 用的桥梁，因此大数据治理是大数据再创高峰的 必修课”。下面我们将与您分享 新鲜出炉的大数据治理方案。大数据治理系列本系列共分为七个部分，围绕大数据治理统一流程参考模型， 并结合实际业 务问题和 旧M相应的产品解决方案展开叙述。第一部分：大数据治理统一流程模型概述和明确元数据管理策略为了更好地帮助企业进行大数据治理，笔者在 旧M数据治理统一流程模型 基础上结合在电信、金融、政府等行业进行大数据治理的经验， 整理出了大数据 治理统一流程参考模型。本文主要介绍了

4、大数据治理的基本概念， 以及结合图文 并茂的方式讲解了大数据治理统一流程参考模型的前两步：明确元数据管理策略”和无数据集成体系结构”内容。大数据治理概述（狭义）大数据是指无法使用传统流程或工具在合理的时间和成本内处理或 分析的信息，这些信息将用来帮助企业更智慧地经营和决策。而广义的大数据更 是指企业需要处理的海量数据，包括传统数据以及狭义的大数据。（广义）大数据可以分为五个类型：Web和社交媒体数据、机器对机器（M2M）数据、海量 交易数据、生物计量学数据和人工生成的数据。Web和社交媒体数据：比如各种微博、博客、社交网站、购物网站中的数据和内容。M2M数据：也就是机器对机器的数据，比如 RF

5、ID数据、GPS数据、智能仪 表、监控记录数据以及其他各种传感器、监控器的数据。海量交易数据：是各种海量的交易记录以及交易相关的半结构化和非结构化 数据，比如电信行业的 CDR 3G上网记录等，金融行业的网上交易记录、 corebanking记录、理财记录等，保险行业的各种理赔等。生物计量学数据：是指和人体识别相关的生物识别信息，如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。人工生成的数据：比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。在各行各业中，随处可见因数量、速度、种类和准确性结合带来的大数据问 题，为了更好地利用大数据，大数据治理逐渐提上日程。在传统系统中，数

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

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

8、上实施全面的元数据管理，另一条子线是在定义业务问题、执行成熟度评估的基础上定义数据治理路线图以及 定义数值治理相关的度量值。在11个必要步骤的基础上，企业可以在 7个可选 步骤中选择一个或多个途径进行特定领域的数据治理，可选步骤为：主数据监管、（狭义）大数据监管、信息单一视图监管、运营分析监管、预测分析监管、管理 安全与隐私以及监管信息生命周期。企业需要定期对大数据治理统一流程进行度 量并将结果发送给主管级发起人。11.D型萍11. M11.3） H唯2惊忸H时U.主数施由首1X2)AM13-31交雇12啰口大数隹监肯is W WM出单一视图1&朋第鼻图1大数据治理统一流程参考模型第一步：明确

9、元数据管理策略在最开始的时候，元数据（MetaData）是指描述数据的数据，通常由信息结构的描述组成，随着技术的发展元数据内涵有了非常大的扩展，比如UML模型、数据交易规则、用Java, .NET, C+瑶编写的APIs、业务流程和工作流模型、产 品配置描述和调优参数以及各种业务规则、术语和定义等1。在大数据时代，元数据还应该包括对各种新数据类型的描述，如对位置、名字、用户点击次数、 音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。元 数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据主要包括业 务规则、定义、术语、术语表、运算法则和系统使用业务语言等，主要使用者

10、是 业务用户。技术元数据主要用来定义信息供应链 (Information Supply Chain, ISC 各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖 性等，以及存储过程、函数、序列等各种对象。操作元数据是指应用程序运行信 息，比如其频率、记录数以及各个组件的分析和其它统计信息等。从整个企业层面来说，各种工具软件和应用程序越来越复杂， 相互依存度逐 年增加，相应的追踪整个信息供应链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中，元数据管理 也逐渐从局部存储和管理转向共享。从总量上来看，整个企业的元数据越来越多， 光

11、现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业需要处理的数据类型越来越多。 为了企业更高效 地运转，企业需要明确元数据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据管理，并有步骤的提升其元数据管理成熟度。为了实现大数据治理，构建智慧的分析洞察，企业需要实现贯穿整个企业的 元数据集成，建立完整且一致的元数据管理策略，该策略不仅仅针对某个数据仓 库项目、业务分析项目、某个大数据项目或某个应用单独制定一个管理策略，而是针对整个企业构建完整的管理策略。元数据管理策略也不是技术标准或某个软 件工具可以取代的，无论软件工具功能多强大都不能完

12、全替代一个完整一致的元 数据管理策略，反而在定义元数据集成体系结构以及选购元数据管理工具之前需 要定义元数据管理策略。元数据管理策略需要明确企业元数据管理的愿景、目标、需求、约束和策略等，依据企业自身当前以及未来的需要确定要实现的元数据管理成熟度以及实现 目标成熟度的路线图，完成基础本体、领域本体、任务本体和应用本体的构建，确定元数据管理的安全策略、版本控制、元数据订阅推送等。企业需要对业务术 语、技术术语中的敏感数据进行标记和分类，制定相应的数据隐私保护政策，确保企业在隐私保护方面符合当地隐私方面的法律法规，如果企业有跨国数据交换、元数据交换的需求，也要遵循涉及国家的法律法规要求。 企业需要

13、保证每个元数 据元素在信息供应链中每个组件中语义上保持一致，也就是语义等效（ semantic equivalence） 0语义等效可以强也可以弱，在一个元数据集成方案中，语义等效（平均）越强则整个方案的效率越高。语义等效的强弱程度直接影响元数据的共 享和重用。本体（人工智能和计算机科学）本体（Ontology）源自哲学本体论，而哲学本体论则是源自哲学中形而上学”分支。本体有时也被翻译成本体论，在人工智能和计算机科学领域本体最早 源于上世纪70年代中期，随着人工智能的发展人们发现知识的获取是构建强大 人工智能系统的关键，于是开始将新的本体创建为计算机模型从而实现特定类型 的自动化推理。之后到了

14、上世纪 80年代，人工智能领域开始使用本体表示模型 化时间的一种理论以及知识系统的一种组件，认为本体（人工智能）是一种应用哲学。最早的本体（人工智能和计算机科学）定义是 Neches等人在1991给出的： j个本体定义了组成主题领域的词汇的基本术语和关系，以及用于组合术语和关系以及定义词汇外延的规则而第一次被业界广泛接受的本体定义出自TomGruber,其在1993年提出：本体是概念化的显式的表示（规格说明）Borst在 1997年对Tom Gruber的本体定义做了进一步的扩展， 认为：本体是共享的、概 念化的一个形式的规范说明”。在前人的基础上，Stude在1998年进一步扩展了 本体的定

15、义，这也是今天被广泛接受的一个定义：本体是共享概念模型的明确形式化规范说明本体提供一个共享词汇表，可以用来对一个领域建模，具体 包括那些存在的对象或概念的类型、以及他们的属性和关系2。一个简单的本体示例发票概念及其相互关系所构成的语义网络如图2所示：岬电通讯业定额发票5()儿贷来品定额发票一兄T、文化体育业定额发察、(50 元)S-J济南市服务业机打发票济南市服务业定额发票(卷式)/,把城南所柜现M、*济南方/图2简单本体(发票)示例随着时间的推移和技术的发展，本体从最开始的人工智能领域逐渐扩展到图 书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。 与哲学本体论类似，本体

16、(人工智能和计算机科学)依赖某种类别体系来表达实 体、概念、事件及其属性和关系。本体的核心是知识共享和重用，通过减少特定 领域内概念或术语上的分歧，使不同的用户之间可以顺畅的沟通和交流并保持语 义等效性，同时让不同的工具软件和应用系统之间实现互操作。根据研究层次可以将本体的种类划分为顶级本体(top-level ontology)、应用本体(application ontology)、领域本体(domain ontology)和任务本体(taskontology),各个种类之间的层次关系如图 3所示。图3本体层次关系顶级本体，也被称为上层本体(upper ontology)或基础本体(foun

17、dation ontology),是指独立于具体的问题或领域，在所有领域都适用的共同对象 或概念所构成的模型，主要用来描述高级别且通用的概念以及概念之间的 关系。领域本体是指对某个特定的领域建模，显式的实现对领域的定义，确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领 域知识的共同理解。领域本体所表达的是适合自己领域的术语的特定含义， 缺乏兼容性，因而在其他领域往往不适用。在同一领域内，由于文化背景、 语言差异、受教育程度或意识形态的差异，也可能会出现不同的本体。很 多时候，随着依赖领域本体系统的扩展，需要将不同的领域本体合并为更 通用的规范说明，对并非基于同一顶级本体所

18、构建的本体进行合并是一项 非常具有挑战的任务，很多时候需要靠手工来完成，相反，对那些基于同 一顶级本体构建的领域本体可以实现自动化的合并。任务本体是针对任务元素及其之间关系的规范说明或详细说明， 用来解释 任务存在的条件以及可以被用在哪些领域或环境中。是一个通用术语的集 合用来描述关于任务的定义和概念等。应用本体：描述依赖于特定领域和任务的概念及概念之间的关系，是用于 特定应用或用途的本体，其范畴可以通过可测试的用例来指定。从详细程度上来分，本体又可以分为参考本体(reference ontologies)和共 享本体(share ontologies),参考本体的详细程度高，而共享本体的详细

19、程度低。本体(哲学)哲学中的本体（ontology）也被称为存在论，源自哲学中形而上学”分支,主要探讨存在的本质，也就是存在的存在。英文ontology实际上就是来源于希腊文存在）和“ZT ?”（学科）的组合。本体是由早期希腊哲学在公元前6世纪到公元前4世纪提出的 始基”延伸出来的。始基（Principle,又称本原）最 早由泰勒斯（米利都学派）最早提出来，认为万物由水而生，其学生阿那克西曼 德认为万物由一种简单的原质组成，该原质不是水3。而毕达哥拉斯（学派）认为万物都是数”，数不仅被看作万物的本原，而且被看作万物的原型、世界的 本体。后来巴门尼德（爱利亚学派）提出了 存在”的概念，认为存在才

20、是唯一真 正存在的真理，具创造了一种形而上学论证方式，之后的哲学一直到近时期为止， 都从巴门尼德处接受了其 实体的不可毁灭性”。苏格拉底继承了巴门尼德的存在 概念，主张真正的善”并完善了巴门尼德弟子芝诺的辩证法，其学生柏拉图提出 了理念论”，认为只要若干个个体拥有一个共同的名字，它们就有一个共同的理 念或形式。亚里士多德（柏拉图学生）总结了先哲们的思想，完成了形而上学， 并将本体总结为：对世界上客观存在事物的系统的描述，即存在论，也就是最形而上学的知识。形而上学不是指孤立、静止之类的意思，而是指超越具体形态的 抽象意思，是关于物质世界最普遍的、最一般的、最不具体的规律的学问。第二步：元数据集成

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

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

23、为例，其点对点的元数据集成体系结构具体如图4所示,信息供应链各组件之间的空心箭头表示全部的数据流， 实心箭头表示不同的元数 据桥和与之关联的元数据流。，学推疗杆 】 数据伊眸n n同次第计IBridges图4点对点的元数据集成体系结构通过使用中央元数据存储库(central metadata repository)取代各个工具软 件和应用程序之间的点对点连接方式，改成中央元数据存储库与各个工具软件和 应用程序实现元数据交换的访问层(也是一种桥)，可以有效降低总成本，减少 建立点对点元数据桥的工作，提高投资回报率。信息供应链各组件可以从存储库 访问元数据，不必与其他产品进行点对点交互。这种使用中

24、央元数据存储库方式 进行元数据集成的方式就是中央辐射式元数据体系结构(hub-and-spoke metadata architecture),具体如图5所示。由于特定的元数据存储库是围绕其自 身的元模型、接口和交付服务建立的，所以仍需要建立元数据桥实现与ISC各组件的互相访问。采用模型驱动的元数据集成方法（比如使用CWM）可以有效降低元数据集成的成本和复杂度，无论点对点元数据集成体系结构还是中央辐射式元数据集成 体系结构都可以因此受益。在点对点体系结构中，通过使用基于模型的方法可以 不必在每一对需要集成的产品之间构建元数据桥，每个产品只需要提供一个适配 器（adapter）即可实现各个产品之

25、间的元数据交换，适配器既了解公共的元模 型也了解本产品元模型的内部实现。如图 6所示，基于CWM模型驱动点对点元 数据集成体系结构使用通用元模型，不再需要在各个产品间建立元数据桥， 在各 个产品之间通过适配器实现了语义等价性。cwv元数据交换适配器 （Addplur 图6基于CWM模型驱动的点对点元数据集成体系结构如图7所示，在基于模型驱动（比如 CWM）的中央辐射式元数据体系结构 中，中央存储库包含公共元模型和整个领域 （domain）用到的该元模型的各个实 例（模型）、存储库自身元模型及其实例、理解元模型（公共元模型和自身元模图7基于CWM模型驱动的中央存储库元数据集成体系结构如图8所示，

26、这种体系架构是基于CWM模型驱动的中央存储库元数据集成 体系结构的一个变种，两个中央辐射式的拓扑结构通过各自的元数据存储库连接 起来，也被称为分布式（Distributed）或联邦（Federated）体系结构。两个元数 据存储库之间通过元数据桥连接，两个存储库使用相同的元模型和接口， 也可以 使用不同的元模型和接口。建立分布式元数据集成体系结构的原因有很多种，比如企业基于多个区域单独部署自己的应用，每个区域有自己的数据中心。占L,阳匕V损意却才兀敢静宜恨拓于X，1l亚标准AFI牌用）F；世壮附 诙黑力整MU3 阳；期新山M,MDMHuh中，-限 AAE1cIWM1二归售tN*K取据H楮，图8

27、分布式（联邦式）元数据集成体系结构如图9所示，这种体系结构是分布式体系结构的变体，根存储库实现了元模 型的公共部分（横跨整个企业），叶子存储库实现了一个或多个特定的公共元模 型子集，并只保存这些自己所对应的元数据实例。 特定客户可以主要访问其感兴 趣的元数据所在的叶子存储库，也可以访问其它叶子存储库和根存储库。 这种体 系结构被称为层次或星型拓扑结构。结束语本文详细介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步 明确元数据管理策略”和第二步 无数据集成体系结构”等内容。在第 一步“明确元数据管理策略”中讲述了元数据的基本概念以及本体在人工智能/计算机科学和哲学中的含义。在

28、第二步 无数据集成体系结构”讲述了元数据集成 体系结构的六种示例，分别为：点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM模型驱动的点对点元数据集成体系结构、基于 CWM模 型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构。在本系列文章的下一部分将继续介绍大数 据治理统一流程参考模型第二步“元数据集成体系结构”，具体包括元模型、元- 元模型、公共仓库元模型（CWM）、CWM发展史、OMG的模型驱动体系结构 （ModelDrivenArchitecture, MDA）。参考文献David Frankel ConsultingU

29、sinMode lDriven Architecture?to Manage Metadata ,P3;Fredrik Arvidssonand Annika FlychtEriksson,2008,OntologiesI Anontdlogy 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更多内容请参考：专著/（英）伯特兰.罗素

30、/著孙绍武/主编西方哲学 史；John Poole,Dan Chang,Douglas Tolbertand David Mellor,2002,Common Warehouse Metamodel,p18-32,p180-202;本系列文章参考了 Sunil Soare却写的The IBM Data Governance Unified ProcesS 和 Big data Governance 书中内容？第二部分：元数据集成体系结构在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构， 即元数据集成体系结构。元数据集成体系结构涉及到多个概念，如元模型、元 - 元模型、公共仓库元

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

32、Meta model ）模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的 表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数 据。元模型（Meta model）也就是模型的模型（或者元-元数据）,是用来描述元 数据的模型。下面基于关系型表实体-关系（ER）模型举例说明什么是元模型。如图 1所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必须有一个名字（字符串），一个表可以有1到多个列，每个列必须有一个名字（字 符串）和数据类型（字符串）：图1简单关系型表元模型如

33、果要创建一个关系型表模型，基于该表元模型创建一个实例即可， 比如创 建一个常见的雇员表 Employees表模型，具体如图2所示，Employees表包含6 个列，分别是编号、姓、名字、部门编号、经理编号和职位编号。Entity Employees+ID： Integer+FirsJname: String +Last_name: String DepartJD: Integer +ManagerJD: Integer +Job_ID: Integer图2Employees表实例比如在DB2中创建employees表，可以很容易的从employees表模型中得至U 相应的DDL语句，执行DDL

34、语句时DB2会生成描述employees表的内部元数据 并存储在目录（DB2内部的兀数据存储库）中。清单1在DB2中创建employees表示例Create table employees (Id integer not null TOC o 1-5 h z 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表模型。

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

36、元数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结 构1。Entity Department+1D: Integer+name: String图3 department表实例元-元模型(Meta-meta model )元-元模型就是元模型的模型，有时也被称为本体(ontology),是模型驱动 的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依 照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实 例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据（模 型）则

37、是一个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据） 则是元数据（或者称为模型）的实例。元数据层次结构具体如表1所示，共分为4层，最高层L3是元-元模型，之下是L2元模型和L1模型/元数据，最底层是L0 用户对象/用户数据：表1元数据层次结构元层次名称示例L3元-元模型元类、元属性、元操作L2元模型类、属性、操作、构件L1模型/元数据实体-关系（ER图L0用户对象/用户数据交易数据、ODS数据、数据仓库数据、数据集巾数据、数据中心数据等公共仓库元模型（CWM）概述公共仓库元模型（Common Warehouse MetaModel, CWM）是被对象管理组 织OMG （Objec

38、t Management Group）采纳的数据仓库和业务分析领域元数据交 换开放式行业标准，在数据仓库和业务分析领域为元数据定义公共的元模型和基 于XML的元数据交换（XMI）。CWM作为一个标准的接口，可以帮助分布式、异 构环境中的数据仓库工具，数据仓库平台和数据仓库元数据存储库之间轻松实现 数据仓库和业务分析元数据交换。CWM提供一个框架为数据源、数据目标、转 换、分析、流程和操作等创建和管理元数据，并提供元数据使用的世系信息2。CWM是一个基于模型驱动方法的完整地描述数据仓库和业务分析领域的元 模型，提供构建元数据所需的语法和语义，由若干个不相同又紧密相关的子元模 型组成。CWM模型的

39、目的是最大限度的重用对象模型（Object Model, UML的 一个子集），并在可能的地方共享通用模型结构。如图4所示，CWM元模型使用包（package和层次来简化管理的复杂度并便于理解，共包含 21个单独的包， 这些包被分为5个层次。对象模型层包含定义基本元模型的概念、关系和约束的 包，其它CWM包都需要用到这些定义，对象模型层的包构成了其它 CWM包所 需要的基本元模型服务的全部集合。对象模型层主要包括核心包（Core package、 行为包 （Behavioral package、关系包 （Relationships package 和实例包 （Instance package）

40、。数据源层（Data Resources :主要描述CWM元数据交换中既可作为源又可 以作为目标的数据源的结构，本层含有的元模型主要描述面向对象的数据库 和应用、关系型数据库、面向记录的数据源（如文件、记录数据库管理系统 等）、多维数据库和XML数据源等。对于面向对象数据源，CWM一般情况下 重用基本的对象模型（位于对象模型层），如果该数据源具有对象模型层无 法处理的一些特征和功能时，可以通过定义一个扩展包来解决。数据分析层（Data Analysis）:本层含有的元模型主要描述数据转换、在线分 析处理OLAP数据挖掘、信息可视化和业务术语等。仓库管理层（Warehouse Managemen

41、t）:本层含有的元模型主要描述数据仓 库处理和数据仓库操作。ManagemertAnalysisTransformationOLAPData MiningInform JtionVisual ml0nBusiness NomenclatureResourceObject MedelRelationalRecordMuttidlmenslonalXMLFoundationBuflntctInfo rmatlcnDug TypesExpr”siQnand Ind吕m 叩立SNMdr。 DcploymtntObject Mod4l图4 CWM1.1元模型CWM1.1是在2003年3月发布的，与之相关

42、的 OMG组织规范还有MOF、 UML和XMI。CWM使用统一建模语言（UML）定义公共元数据的模型（CWM元 模型），使用可扩展标记语言（XML）生成CWM元数据交换规范（也就是 XML 元数据交换，XMI）,使用CORBAR口定义语言（IDD为访问CWM元数据生成 编程语言API的规范（依赖MOF至ij IDL的映射）。UML是一种规范化、可视化、描述明确、结构化和文档化的定义分布式对象系统的图形化语言。1996年，业内三种最杰出的面向对象建模语言：GradyBooch的Booch方法、Ivar Jacobson的面向对象软件工程（OOSE和Jim Rumbaugh 的对象建模技术（OMT

43、）被统一起来发布，也就是 UML0.9。2011年，UML2.4.1 发布。CWM依赖于UML规范的前三个部分，即UML语义、UML符号向导和对 象约束语言规范。UML语义定义UML元模型的语义，UML元模型是层次结构并 以包为单位进行组织，每个包按照抽象语言（使用类图）、结构良好规则（采用 OCL和语义（采用英语）来定义。UML符号指定表达UML元模型语义的图形 语法（例如类图）。对象约束语言规范定义对象约束语言（OCD的句法、语义 和语法，OCL是一种表述约束的形式化语言3。构造块和结构良好规则：UML提供了组成构造块和结构良好规则的面向对象建 模语言，基本的构造块包括模型元素（如类、对象

44、、接口、组件、用例等） 、关 系（如关联、泛化、依赖等）和图（如类图、对象图、用例图等）等。UML可以为一个系统进行不同方面的建模，比如结构建模（又包括使用类图和 对象图的静态结构建模、使用组件图和部署图实现建模）、用例建模和行为建模 等。元数据建模只需要静态结构建模，静态结构的核心元素是类、对象、属性 和操作。UML用包来将模型元素组织成语义上相关联的分组，每个包拥有其自己的模型 元素，每个模型元素不能同时被多个包拥有。UML在CWM中主要作为三种角色出现4:1、UML作为和MOF等价的元-元模型。UML,或者部分对应MOF模型、UML 符号和OCL的UML分别被用作建模语言、图形符号和约束

45、语言，用来定义和表 示 CWM。2、UML作为基础元模型。对象模型层（ObjectModel）与UML关系密切， 是UML的一个子集。3、UML用来作为面向对象元模型。元对象框架（Meta Object Framework , MOF,本文以2.4.1版本为例）是一 个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的 分布式对象集成框架。此框架支持各种类型的元数据，还可以根据需求添加新类型的元数据。MOF包括MOF模型（定义建立元模型的建模元素和使用规则）、 MOF反射接口（允许程序在不使用元模型指定接口时对元数据进行各种操作） 和MOF至ij IDL的映射（定义MOF模型

46、定义的元模型到 CORBAID之间的标准映 射）。MOF模型是以UML的概念和结构为基础，尤其是以 UML的静态结构模型 和模型管理为基础。MOF模型没有定义自己的图形符号和约束语言，而是采用 UML的图形符号和OCL来实现。MOF模型也是层次结构，并以包为单位进行组 织。MOF支持各种类型的元数据，采用四层元数据体系结构（也就是OMG元数 据体系结构）5,具体如表2所示，该体系架构将元数据（M1）视同为数据（M0）, 并对之进行形式化建模（即元模型， M2）。元模型（M2）使用元-元模型（M3） 所提供的元建模结构来表示。表 2表明MOF模型（元-元模型）、UML元模型、 用户模型和用户对象

47、/数据之间的关系。表2 MOF四层元数据体系结构描述示例M3MOF,i.e. the set of constructs used to define metamodelsMOF Class,MOF Attribute,MOFAssociation,etc .M2Metamodels,consisting of instances of MOF constructs.UML Class,UMLAssociation,UMLAttribute,UML State,UMLActivity,etc.CWM Table,CWM Column,etcM1Models,consisting of inst

48、ances of M2 metamodel constructs.Class “CustomeCiass “Account” Table“EmployTable “Vendoetc.M0Objects and data,i.e.instances ofM1 modelconstructsCustomer Jane Smith,Customer JoeJones,Account2989,Account2344,EmployeeA3949,Vendor 78988,etc.XML元数据交换（XMI）是在工具软件、应用程序之间进行元数据交换的 XML 语言，整合了 UML、MOF和XML三种技术，允

49、许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标准制定打下了第一个基础。同样在19

50、97年，MOF被OMG 采纳为标准，为CWM的产生打下了第二个基础。1999年初，OMG采纳XMI作 为标准，为CWM的出现打下了第三个基础。1998年5月，旧M、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发展的同时，其他

51、一些元数据标准的制定也在进行中。最早在1993年，电子信息组织就发布了计算机辅助工程数据交换格式(CASE Data InterchangeFormat, CD 并得到了一定的认可。1995年10月，元数据联盟(Meta Data Coalition, MDC)成立，并与1996年4月发布了元数据交换规范 1.0 (Meta Data Interchange Specification, MDIS),与 CWM 相比，MDIS 涉及的范畴少很多，且 其规范和交换语言都是自身独有的。此时微软也在和其他一些合作者一起开发开 放信息模型(Open Information Model , OIM),该

52、模型于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)参考模型，描述了 OM

53、G规范所遵循的概念化的基础结构。 OMA是由对象请求代理(Object Request Broker, ORB) 对象服务、公共设施、 域接口和应用接口等几个部分组成，其核心是对象请求代理(ORB)。对象请求代理(ORB)是公共对象请求彳t理体系结构( Common Object Request Broker Architecture, CORBA的核心组件，提供了识别和定位对象、处理连接管理、传 送数据和请求通信所需的框架结构。OMA和CORBAt定位为软件框架，用来指 导基于OMG规范的技术开发。从1995年开始，OMG开始非正式的采用针对特定行业(“领域”，Domain) 的技术规范，为

54、了保持扩张重点，OMG在2001年正式采用第二个框架，模型驱 动体系架构(Model Driven Architecture, MDA)。与 OMA和 CORBAT一样，MDA 不是部署分布式系统的框架，而是在软件开发中基于模型驱动的方法。为了实现MDA, OMG随后制定了一系列标准如 UML、MOF、XMI和CWM等，解决了 MDA 的模型建立、扩展、交换等几个方面的问题。模型驱动体系结构源自众所周知的 和长期建立的思想：将系统操作规范从系统利用底层平台能力的细节中分离出来”。MDA提供了一种方法(基于相关工具)来规范化一个平台独立的系统，为 系统选择一个特定的实现平台，并把系统规范转换到特

55、定的实现平台。MDA的首要三个目标是：可移植性、互操作性和可重用性。MDA三个视角(viewpoint) 6分别是：计算无关视角(Computation Independent Viewpoint):侧重系统环境和系 统需求；系统结构和流程细节被隐藏或尚未确定。其对应的是计算无关模 型(Computation Independent Model, CIM)。平台无关视角(Platform Independent Viewpoint):侧重系统的操作，同时 隐藏用于特定平台的必要细节。其对应的是平台无关模型( Platform Independent Model, PIM), PIM是抽出技术和

56、具体工程细节之后的模型。 平台相关视角(Platform Specific Viewpoint):结合平台无关系视角和系统 所使用的特定平台细节。其又t应的是平台相关模型( Platform SpecificViewpoint Model, PSM), PSM是包含技术和具体工程细节的模型。OMG模型驱动体系结构如图5所示:FinanceF/aixilactunngE-CommeroeTransporidtwnHealthcarec r图5 OMG模型驱动体系架构Model DrivenArchitecture*TelecomCWM元模型、规范以及生成的产品同MDA非常契合，从技术平台角度来说

57、， 所有的平台相关模型（CWMXML、CWMIDL和CWM Java等）都是自动地从平台 无关模型（CWM元模型和规范）中产生的；从产品平台角度来说，平台相关模 型（比如DB2、ORACLE SQLSERVER）都是人工从平台无关模型（CWM元模 型和规范）中构造出来的。结束语本文详细介绍了大数据治理统一流程参考模型第二步无数据集成体系结构”的后续内容，主要包括元模型、元-元模型、公共仓库元模型（CWM）、CWM发 展史、对象管理组织OMG的模型驱动体系结构（Model Driven Architecture, MDA）。 在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型的第三步：实

58、施元数据管理”，讲述在大数据时代如何实施元数据管理，如何使用元数据管理成熟度模型，以及IBM在元数据管理方面的产品：业务元数据管理工具 旧M Info Sphere Business Glossary、业务词汇表小工具 Info Sphere Business Glossary Anywhere 和技术元数据管理工具 Info Sphere Metadata Workbench参考文献1更多信息请参考 :OMG Model Driven Architecture :/mda/ ;OMG,Common Warehouse Metamodel(CWM)Specification v1.1,P44

59、;John Poole,Dan Chang,Douglas Tolbert and David Mellor,2002,Common Warehouse Metamodel,p48-53,p58-63 ;OMG,Common Warehouse Metamodel(CWM)Specification v1.1,P45 ;David Frankel Consulting, “ Using Model Driven Architecture? to Manage Metadata ,P46 ;OMG,2003,MDA Guide Version 1.0.1,p11-12,P15-16 ;第三部分：

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