聪明文档网

聪明文档网

最新最全的文档下载
当前位置: 首页> 大数据治理系列教材

大数据治理系列教材

时间:2020-09-10    下载该word文档

大数据治理——为业务提供持续的、可度量的价值 目录
大数据治理——为业务提供持续的、可度量的价值 ..... 1 概述 ............................................ 3 大数据治理系列 .................................. 3
第一部分:大数据治理统一流程模型概述和明确元数据治理策略 ........................................ 3
第二部分:元数据集成体系结构 ................ 24 第三部分:实施元数据治理 ................... 42 第四部分:大数据治理统一流程参考模型的第四步到第九步 ........................................... 63
第五部分:定义度量值和主数据监管 ............ 91
1 / 160

第六部分:大数据监管和信息单一视图监管 ..... 113 第七部分:分析监管、安全与隐私治理和信息生命周期监管 .......................................... 136


2 / 160

概述
面对我们周围每时每刻迅速增长的庞大数据,因为其数量大、速度快、种类多和准确性的特征,如何更好地利用大数据制造出有意义的价值,一直是我们探究的重要话题。而在这之前,就需要用科学正确的方法策略对大数据进行治理。大数据治理是指制定与大数据有关的数据优化、隐私爱护与数据变现的政策,是传统信息治理的连续和扩展,也是大数据分析的基础,依旧连接大数据科学和应用的桥梁,因此大数据治理是大数据再创高峰的“必修课”。下面我们将与您分享新奇出炉的大数据治理方案。 大数据治理系列
本系列共分为七个部分,围绕大数据治理统一流程参考模型,并结合实际业务问题和IBM相应的产品解决方案展开叙述。
第一部分:大数据治理统一流程模型概述和明确元数据治理策略
为了更好地关心企业进行大数据治理,笔者在IBM数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验,整理出了大数据治理统一流程参考模型。本文要紧3 / 160

介绍了大数据治理的差不多概念,以及结合图文并茂的方式讲解了大数据治理统一流程参考模型的前两步:“明确元数据治理策略”和“元数据集成体系结构”内容。
大数据治理概述
(狭义)大数据是指无法使用传统流程或工具在合理的时刻和成本内处理或分析的信息,这些信息将用来关心企业更智慧地经营和决策。而广义的大数据更是指企业需要处理的海量数据,包括传统数据以及狭义的大数据。(广义)大数据能够分为五个类型:Web和社交媒体数据、机器对机器(M2M)数据、海量交易数据、生物计量学数据和人工生成的数据。
Web和社交媒体数据:比如各种微博、博客、社交网站、购物网站中的数据和内容。
M2M数据:也确实是机器对机器的数据,比如RFID数据、GPS数据、智能仪表、监控记录数据以及其他各种传感器、监控器的数据。
海量交易数据:是各种海量的交易记录以及交易相关的半结构化和非结构化数据,比如电信行业的CDR3G上网记录等,金融行业的网上交易记录、corebanking记录、理财记录等,4 / 160

保险行业的各种理赔等。
生物计量学数据:是指和人体识不相关的生物识不信息,如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。 人工生成的数据:比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。
在各行各业中,随处可见因数量、速度、种类和准确性结合带来的大数据问题,为了更好地利用大数据,大数据治理逐渐提上日程。在传统系统中,数据需要先存储到关系型数据库/数据仓库后再进行各种查询和分析,这些数据我们称之为静态数据。而在大数据时代,除了静态数据以外,还有专门多数据对实时性要求特不高,需要在采集数据时就进行相应的处理,处理结果存入到关系型数据库/数据仓库、MPP数据库、Hadoop平台、各种NoSQL数据库等,这些数据我们称之为动态数据。比如高铁机车的关键零部件上装有成百上千的传感器,每时每刻都在生成设备状态信息,企业需要实时收集这些数据并进行分析,当发觉设备可能出现问题时及时告警。再比如在电信行业,基于用户通信行为的精准营销、位置营销等,都会实时的采集用户数据并依照业务模型进行相应的营销活动。
5 / 160

大数据治理的核心是为业务提供持续的、可度量的价值。数据治理人员需要定期与企业高层治理人员进行沟通,保证大数据治理打算能够持续获得支持和关心。相信随着时刻的推移,数据将成为主流,企业能够从海量的数据中获得更多的价值,大数据治理的范围和严格程度也将逐步上升。为了更好地关心企业进行大数据治理,笔者在IBM数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验,整理了大数据治理统一流程参考模型,整个参考模型分为必选步骤和可选步骤两部分。
大数据治理统一流程参考模型
如图1所示,大数据治理统一流程参考模型必要步骤分为两个方向:一条子线是在制定元数据治理策略和确立体系结构的基础上实施全面的元数据治理,另一条子线是在定义业务问题、行成熟度评估的基础上定义数据治理路线图以及定义数值治理相关的度量值。在11个必要步骤的基础上,企业能够在7个可选步骤中选择一个或多个途径进行特定领域的数据治理,可选步骤为:主数据监管、(狭义)大数据监管、信息单一视图监管、运营分析监管、预测分析监管、治理安全与隐私以及监管信息生6 / 160

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

1大数据治理统一流程参考模型
第一步:明确元数据治理策略
在最开始的时候,元数据MetaData是指描述数据的数据,通常由信息结构的描述组成,随着技术的进展元数据内涵有了特不大的扩展,比如UML模型、数据交易规则、用Java.NETC++等编写的APIs、业务流程和工作流模型、产品配置描述和调优参数以及各种业务规则、术语和定义等[1]。在大数据时代,7 / 160

元数据还应该包括对各种新数据类型的描述,如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。元数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据要紧包括业务规则、定义、术语、术语表、运算法则和系统使用业务语言等,要紧使用者是业务用户。技术元数据要紧用来定义信息供应链(Information Supply ChainISC)各类组成部分元数据结构,具体包括各个系统表和字段结构、属性、出处、依靠性等,以及存储过程、函数、序列等各种对象。操作元数据是指应用程序运行信息,比如其频率、记录数以及各个组件的分析和其它统计信息等。
从整个企业层面来讲,各种工具软件和应用程序越来越复杂,相互依存度逐年增加,相应的追踪整个信息供应链各组件之间数据流淌、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中,元数据治理也逐渐从局部存储和治理转向共享。从总量上来看,整个企业的元数据越来越多,光现有的数据模型中就包含了成千上万的表,同时还有更多的模型等着上线,同时随着大数据时代的来临,企业需要处理的数据类型越来越多。为了企业更高效地运转,企业需要明确元数据治8 / 160

理策略和元数据集成体系结构,依托成熟的方法论和工具实现元数据治理,并有步骤的提升其元数据治理成熟度。
为了实现大数据治理,构建智慧的分析洞察,企业需要实现贯穿整个企业的元数据集成,建立完整且一致的元数据治理策略,该策略不仅仅针对某个数据仓库项目、业务分析项目、某个大数据项目或某个应用单独制定一个治理策略,而是针对整个企业构建完整的治理策略。元数据治理策略也不是技术标准或某个软件工具能够取代的,不管软件工具功能多强大都不能完全替代一个完整一致的元数据治理策略,反而在定义元数据集成体系结构以及选购元数据治理工具之前需要定义元数据治理策略。
元数据治理策略需要明确企业元数据治理的愿景、目标、求、约束和策略等,依据企业自身当前以及以后的需要确定要实现的元数据治理成熟度以及实现目标成熟度的路线图,完成基础本体、领域本体、任务本体和应用本体的构建,确定元数据治理的安全策略、版本操纵、元数据订阅推送等。企业需要对业务术语、技术术语中的敏感数据进行标记和分类,制定相应的数据隐私爱护政策,确保企业在隐私爱护方面符合当地隐私方面的法律法规,假如企业有跨国数据交换、元数据交换的需求,也要遵循9 / 160

涉及国家的法律法规要求。企业需要保证每个元数据元素在信息供应链中每个组件中语义上保持一致,也确实是语义等效semantic equivalence。语义等效能够强也能够弱,在一个元数据集成方案中,语义等效(平均)越强则整个方案的效率越高。语义等效的强弱程度直接阻碍元数据的共享和重用。
本体(人工智能和计算机科学)
本体(Ontology)源自哲学本体论,而哲学本体论则是源自哲学中“形而上学”分支。本体有时也被翻译成本体论,在人工智能和计算机科学领域本体最早源于上世纪70年代中期,随着人工智能的进展人们发觉知识的猎取是构建强大人工智能系统的关键,因此开始将新的本体创建为计算机模型从而实现特定类型的自动化推理。之后到了上世纪80年代,人工智能领域开始使用本体表示模型化时刻的一种理论以及知识系统的一种组件,认为本体(人工智能)是一种应用哲学。
最早的本体(人工智能和计算机科学)定义是Neches等人1991给出的:“一个本体定义了组成主题领域的词汇的差不多术语和关系,以及用于组合术语和关系以及定义词汇外延的规则”。而第一次被业界广泛同意的本体定义出自Tom Gruber10 / 160

其在1993年提出:“本体是概念化的显式的表示(规格讲明)”。Borst 1997年对Tom Gruber的本体定义做了进一步的扩展,认为:“本体是共享的、概念化的一个形式的规范讲明”。在前人的基础上,Stude1998年进一步扩展了本体的定义,这也是今天被广泛同意的一个定义:“本体是共享概念模型的明确形式化规范讲明”。本体提供一个共享词汇表,能够用来对一个领域建模,具体包括那些存在的对象或概念的类型、以及他们的属性和关系[2]。一个简单的本体示例发票概念及其相互关系所构成的语义网络如图2所示:


11 / 160

2简单本体(发票)示例
随着时刻的推移和技术的进展,本体从最开始的人工智能领域逐渐扩展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。与哲学本体论类似,本体(人工智能和计算机科学)依靠某种类不体系来表达实体、概念、事件及其属性和关系。本体的核心是知识共享和重用,通过减少特定领域内概念或术语上的分歧,使不同的用户之间能够顺畅的沟通和交流并保持语义等效性,同时让不同的工具软件和应用系统之间实现互操作。
照研究层次能够将本体种类划分为级本体top-level ontology、应用本体(application ontology领域本体(domain ontology)和任务本体(task ontology各个种类之间的层次关系如图3所示。

3本体层次关系
12 / 160


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

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

任务本体是针对任务元素及其之间关系的规范讲明或详细讲明,用来解释任务存在的条件以及能够被用在哪些领域
13 / 160

或环境中。是一个通用术语的集合用来描述关于任务的定义和概念等。

应用本体:描述依靠于特定领域和任务的概念及概念之间的关系,是用于特定应用或用途的本体,其范畴能够通过可测试的用例来指定。
从详细程度上来分,本体又能够分为参考本体(reference ontologies)和共享本体(share ontologies,参考本体的详细程度高,而共享本体的详细程度低。
本体(哲学)
哲学中的本体ontology也被称为存在论,源自哲学中“形而上学”分支,要紧探讨存在的本质,也确实是存在的存在。英ontology实际上确实是来源于希腊文“ον”(存在)和“λόγος”(学科)的组合。本体是由早期希腊哲学在公元6世纪到公元前4世纪提出的“始基”延伸出来的。始基Principle,又称本原)最早由泰勒斯(米利都学派)最早提出来,认为万物由水而生,其学生阿那克西曼德认为万物由一种简单的原质组成,该原质不是水[3]。而毕达哥拉斯(学派)认为“万物差不多上数”,数不仅被看作万物的本原,而且被看作14 / 160

万物的原型、世界的本体。后来巴门尼德(爱利亚学派)提出了“存在”的概念,认为存在才是唯一真正存在的真理,其制造了一种形而上学论证方式,之后的哲学一直到近时期为止,都从巴门尼德处同意了其“实体的不可毁灭性”。苏格拉底继承了巴门尼德的存在概念,主张“真正的善”并完善了巴门尼德弟子芝诺的辩证法,其学生柏拉图提出了“理念论”,认为只要若干个个体拥有一个共同的名字,它们就有一个共同的理念或形式。亚里士多德(柏拉图学生)总结了先哲们的思想,完成了《形而上学》并将本体总结为:对世界上客观存在事物的系统的描述,即存在论,也确实是最形而上学的知识。形而上学不是指孤立、静止之类的意思,而是指超越具体形态的抽象意思,是关于物质世界最普遍的、最一般的、最不具体的规律的学问。
第二步:元数据集成体系结构
在明确了元数据治理策略后需要确定实现该治理策略所需的技术体系结构,即元数据集成体系结构。各个企业的元数据治理策略和元数据治理成熟度差不较大,因此元数据集成体系结构也多种多样。大体上元数据集成体系结构能够分为点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWMCommon 15 / 160

Warehouse Meta Model,公共仓库元模型)模型驱动的点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式(联邦式)元数据集成体系结构和层次/星型元数据集成体系结构等。
针对信息供应链中不同的组件,为了实现跨组件的元数据交换和集成,最开始人们采纳点对点的方式进行,也确实是每一对组件之间通过一个独立的元数据桥(metadata bridge)进行元数据交换,桥一般是双向的能够理解两个方向的元数据映射[4]点对点的元数据集成体系结构关心用户实现了跨企业的元数据集成和元数据交换,对提升信息化水平提供了巨大关心。这种体系结构在应用过程中,也暴露了专门多问题,比如元数据桥的构建工作量和耗时都特不大,对中间件厂商、应用厂商、集成商和用户来讲差不多上一个巨大的挑战,而且构建元数据桥还必须具有所有者的元数据模型和接口的详细信息。构建完成的桥专门多时候无法在构建其他元数据桥时进行重用,因此开发和维护费用大幅度增加,用户投资回报率(ROI)不高。以动态数据仓库为例,其点对点的元数据集成体系结构具体如图4所示,信息供应链各组件之间的空心箭头表示全部的数据流,实心箭头表示不同16 / 160

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

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


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


6基于CWM模型驱动的点对点元数据集成体系结构 如图7所示,在基于模型驱动(比如CWM)的中央辐射式元数据体系结构中,中央存储库包含公共元模型和整个领域domain)用到的该元模型的各个实例(模型)、存储库自身元模型及事实上例、理解元模型(公共元模型和自身元模型)的适配器层,因此存储库也能够直接实现公共元模型的某些内部表示。
19 / 160


7基于CWM模型驱动的中央存储库元数据集成体系结构 如图8所示,这种体系架构是基于CWM模型驱动的中央存储库元数据集成体系结构的一个变种,两个中央辐射式的拓扑结构Distributed)或联邦(Federated)体系结构。两个元数据存储库之间通过元数据桥连接,两个存储库使用相同的元模型和接口,也能够使用不同的元模型和接口。建立分布式元数据集成体系结构的缘故有专门多种,比如企业基于多个区域单独部署自己的应用,每个区域有自己的数据中心。
20 / 160


8分布式(联邦式)元数据集成体系结构
如图9所示,这种体系结构是分布式体系结构的变体,根存储库实现了元模型的公共部分(横跨整个企业),叶子存储库实现了一个或多个特定的公共元模型子集,并只保存这些自己所对21 / 160

应的元数据实例。特定客户能够要紧访问其感兴趣的元数据所在的叶子存储库,也能够访问其它叶子存储库和根存储库。这种体系结构被称为层次或星型拓扑结构。

9层次或星型元数据集成体系结构
结束语
本文详细介绍了大数据治理的差不多概念和统一流程参考模型,并阐述了该模型的第一步“明确元数据治理策略”和第二步“元数据集成体系结构”等内容。在第一步“明确元数据治理策略”中讲述了元数据的差不多概念以及本体在人工智能/计算机科学和哲学中的含义。在第二步“元数据集成体系结构”讲述了元数据集成体系结构的六种示例,分不为:点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM模型驱动的22 / 160

点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式(联邦式)元数据集成体系结构和层/星型元数据集成体系结构。在本系列文章的下一部分将接着介绍大数据治理统一流程参考模型第二步“元数据集成体系结构”具体包括元模型、-元模型、公共仓库元模型CWMCWM进展史、OMG的模型驱动体系结构ModelDrivenArchitectureMDA
参考文献
[1] David Frankel Consulting,”Using Mode lDriven Architectureto 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] 多内容请参考:[专著]/(伯特兰.罗素/著孙绍武/<<西方哲学史>>; 23 / 160

[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等,本部分将接着介绍大数据治理统一流程参考模型第二步“元数据集成体系结构”的相关内容。
在本系列的第一篇文章中,我们要紧介绍了大数据治理的差不多概念和统一流程参考模型,并阐述了该模型的第一步“明确元数据治理策略”和第二步“元数据集成体系结构”的六种示例等内容。大数据治理统一流程参考模型的第二步是“元数据集成体系结构”,具体包括元模型、元-元模型、公共仓库元模型CWMCWM进展史、OMG的模型驱动体系结构(Model Driven 24 / 160

ArchitectureMDA)本文将对元数据集成体系结构包含的各种模型展开叙述。
大数据治理统一流程参考模型,第二步:元数据集成体系结
元模型(Meta model
模型(Model)是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师能够用概要设计的形式建立一个应用系统的模型。本质上来讲,元数据是数据的形式化模型,是数据的抽象描述,该描述准确地描述了数据。元模型Meta model)也确实是模型的模型(或者元-元数据),是用来描述元数据的模型。
下面基于关系型表实体-关系(ER)模型举例讲明什么是元模型。如图1所示,一个简单的关系型表元模型描述了如何定义一个关系型表,规定了每个表必须有一个名字(字符串),一个表能够有1到多个列,每个列必须有一个名字(字符串)和数据类型(字符串)
25 / 160


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

2Employees表实例
比如在DB2中创建employees表,能够专门容易的从employees表模型中得到相应的DDL语句,执行DDL语句时DB226 / 160

会生成描述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

1department表模型。department表包含2个列,分不是编号和部门名称,具体如图3所示。由于department表模型和employees表模型差不多上基于相同的公共元模型,其它工具和应用程序软(了解关系型表的公共元模型)能够专门容易理解department表和employees表,因为它们差不多上同一个元模型的实例。它工具或应用程序通过调用导入映射(import mapping)将该27 / 160

department表模型或employees表模型翻译成自己内部的元数据实例。同样,也能够将该软件内部元数据翻译成一个与平台无关的形式化模型,也确实是导出映射(export mapping,以便其他软件使用其专有的元数据。这种基于公共元模型的集成方法确实是模型驱动的元数据集成体系结构[1]

3 department表实例
-元模型(Meta-meta model
-ontology,是模型驱动的元数据集成体系结构的基础,其定义了描述元模型的语言,规定元模型必须依照一定的形式化规则来建立,以便所有的软件工具都能够对其进行理解。
-元模型比元模型具有更高的抽象级不,一个元模型是一个元-元模型的实例,元模型比元-元模型更加精细,而元-元模型比元模型更加抽象。元数据(模型)则是一个元模型的实例,28 / 160

遵守元模型的规定和约束。用户对象(或用户数据)则是元数据(或者称为模型)的实例。元数据层次结构具体如表1所示,共分为4层,最高层L3是元-元模型,之下是L2元模型和L1模型/元数据,最底层是L0用户对象/用户数据:
1 元数据层次结构
元层名称
L3 L2 L1 -元模型 元模型 模型/元数据 用户对象/用户数L0
数据中心数据等
公共仓库元模型(CWM)概述
公共仓库元模型(Common Warehouse MetaModelCWM)是被对象治理组织OMGObject Management Group)采纳的数据仓库和业务分析领域元数据交换开放式行业标准,在数据仓库和业务分析领域为元数据定义公共的元模型和基于XML的元数据交换(XMICWM作为一个标准的接口,能够关心分布式、异构环境中的数据仓库工具,数据仓库平台和数据仓库元数据存储库29 / 160 仓库数据、数据集市数据、元类、元属性、元操作 类、属性、操作、构件 实体-关系(ER)图 交易数据、ODS数据、数据示例


之间轻松实现数据仓库和业务分析元数据交换。CWM提供一个框架为数据源、数据目标、转换、分析、流程和操作等创建和治理元数据,并提供元数据使用的世系信息[2]
CWM是一个基于模型驱动方法的完整地描述数据仓库和业务分析领域的元模型,提供构建元数据所需的语法和语义,由若干个不相同又紧密相关的子元模型组成。CWM模型的目的是最大限度的重用对象模型(Object ModelUML的一个子集),并在可能的地点共享通用模型结构。如图4所示,CWM元模型使用包package)和层次来简化治理的复杂度并便于理解,共包含21个单独的包,这些包被分为5个层次。对象模型层包含定义差不多元模型的概念、关系和约束的包,其它CWM包都需要用到这些定义,对象模型层的包构成了其它CWM包所需要的差不多元模型服务的全部集合。对象模型层要紧包括核心包Core package行为包Behavioral package关系包Relationships package和实例包(Instance package
数据源层(Data Resources:要紧描述CWM元数据交换中既可作为源又能够作为目标的数据源的结构,本层含有的元模型要紧描述面向对象的数据库和应用、关系型数据库、面向30 / 160

记录的数据源(如文件、记录数据库治理系统等)、多维数据库和XML数据源等。关于面向对象数据源,CWM一般情况下重用差不多的对象模型(位于对象模型层),假如该数据源具有对象模型层无法处理的一些特征和功能时,能够通过定义一个扩展包来解决。
数据分析层(Data Analysis:本层含有的元模型要紧描述数据转换、在线分析处理OLAP、数据挖掘、信息可视化和业务术语等。
仓库治理层(Warehouse Management:本层含有的元模型要紧描述数据仓库处理和数据仓库操作。

4 CWM1.1元模型
CWM1.1是在20033月公布的,与之相关的OMG组织规范还有MOFUMLXMICWM使用统一建模语言(UML)定义公共31 / 160

元数据的模型(CWM元模型),使用可扩展标记语言(XML)生成CWM元数据交换规范(也确实是XML元数据交换,XMI使用CORBA接口定义语言(IDL)为访问CWM元数据生成编程语言API的规范(依靠MOFIDL的映射)
UML是一种规范化、可视化、描述明确、结构化和文档化的定义分布式对象系统的图形化语言。1996年,业内三种最杰出的面向对象建模语言:Grady BoochBooch方法、Ivar Jacobson的面向对象软件工程(OOSE)和Jim Rumbaugh的对象建模技术OMT)被统一起来公布,也确实是UML0.92011年,UML2.4.1公布。CWM依靠于UML规范的前三个部分,即UML语义、UML号向导和对象约束语言规范。UML语义定义UML元模型的语义,UML元模型是层次结构并以包为单位进行组织,每个包按照抽象语言(使用类图)、结构良好规则(采纳OCL)和语义(采纳英语)来定义。UML符号指定表达UML元模型语义的图形语法(例如类图)。对象约束语言规范定义对象约束语言(OCL)的句法、语义和语法,OCL是一种表述约束的形式化语言[3] 构造块和结构良好规则:UML提供了组成构造块和结构良好规则的面向对象建模语言,差不多的构造块包括模型元素(如类、32 / 160

对象、接口、组件、用例等)、关系(如关联、泛化、依靠等)和图(如类图、对象图、用例图等)等。
UML能够为一个系统进行不同方面的建模,比如结构建模(又包括使用类图和对象图的静态结构建模、使用组件图和部署图实现建模)、用例建模和行为建模等。元数据建模只需要静态结构建模,静态结构的核心元素是类、对象、属性和操作。 UML用包来将模型元素组织成语义上相关联的分组,每个包拥有其自己的模型元素,每个模型元素不能同时被多个包拥有。
UMLCWM中要紧作为三种角色出现[4]
1UML作为和MOF等价的元-元模型。UML,或者部分对应MOF模型、UML符号和OCLUML分不被用作建模语言、图形符号和约束语言,用来定义和表示CWM
2UML作为基础元模型。对象模型层ObjectModelUML关系紧密,是UML的一个子集。
3UML用来作为面向对象元模型。
元对象框架(Meta Object FrameworkMOF,本文以2.4.1版本为例)是一个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的分布式对象集成框架。此框架支33 / 160

持各种类型的元数据,还能够依照需求添加新类型的元数据。MOF包括MOF模型(定义建立元模型的建模元素和使用规则)MOF反射接口(同意程序在不使用元模型指定接口时对元数据进行各种操作)和MOFIDL的映射(定义MOF模型定义的元模型到CORBAIDL之间的标准映射)MOF模型是以UML的概念和结构为基础,尤其是以UML的静态结构模型和模型治理为基础。MOF型没有定义自己的图形符号和约束语言,而是采纳UML的图形符号和OCL来实现。MOF模型也是层次结构,并以包为单位进行组织。
MOF支持各种类型的元数据,采纳四层元数据体系结构(也确实是OMG元数据体系结构)[5],具体如表2所示,该体系架构将元数据M1视同为数据M0并对之进行形式化建模(即元模型,M2。元模型(M2)使用元-元模型(M3)所提供的元建模结构来表示。表2表明MOF模型(元-元模型)UML元模型、用户模型和用户对象/数据之间的关系。
2 MOF四层元数据体系结构 描述

MMOF,i.e. the set of 3 constructs used to 示例
MOF Class,MOF Attribute,MOF Association,etc . 34 / 160

define metamodels Metamodels,consistiM2 ng of instances of MOF constructs. Models,consisting nt”
M1
of instances
Table
of M2 metamodel “Employee”,Table“Vendor”,econstructs. tc.
Objects and M0
data,i.e.instances of M1 modelconstructs Customer Jane Smith,Customer Joe Jones,Account 2989,Account2344,Employee A3949,Vendor 78988,etc. UML Class,UMLAssociation,UML Attribute,UML State,UML Activity,etc.CWM Table,CWM Column,etc. Class“Customer”,Class“AccouXML元数据交换(XMI)是在工具软件、应用程序之间进行元数据交换的XML语言,整合了UMLMOFXML三种技术,同MOF元数据(即遵从MOF或基于MOF的元模型的元数据)以流或文件的形式按照XML的标准格式进行交换。XMIOMG在元数据交换方面的标准之一,同时也是W3C认可的标准。本质上,XMIW3CXMLMOF之间,以及XML文档和MOF元数据之间的一对平行映射。20118月,XML公布了2.4.1
35 / 160

CWM进展史
事实上早在上世纪80年代末90年代初,专门多企业就尝试使用一种元模型实现元数据集成以整合分布于各个业务竖井中的元数据,但最终失败了,因为专门多的利益相关者各自拥有不同的观点,且需要不同的模型结构。1997年,OMGUML采纳为标准,为CWM标准制定打下了第一个基础。同样在1997年,MOFOMG采纳为标准,为CWM的产生打下了第二个基础。1999初,OMG采纳XMI作为标准,为CWM的出现打下了第三个基础。19985月,IBMORACLEUnisysOMG提交了公共仓库元数据交换(Common Warehouse Metadata InterchangeCWMI征求意见稿(RFP,同年9OMG公布了该征求意见稿,通过8个公司(IBMUnisysOracleHyperionUBSNCRGenesisDimension EDI2年半的努力和协作,OMG20014月正式采纳CWM为标准。
CWM进展的同时,其他一些元数据标准的制定也在进行中。最早在1993年,电子信息组织就公布了计算机辅助工程数据交换格式(CASE Data Interchange FormatCDIF)并得到了一定的认可。199510月,元数据联盟(Meta Data Coalition36 / 160

MDC)成立,并与19964月公布了元数据交换规范1.0Meta Data Interchange SpecificationMDIS,与CWM相比,MDIS涉及的范畴少专门多,且其规范和交换语言差不多上自身独有的。现在微软也在和其他一些合作者一起开发开放信息模型(Open Information ModelOIM,该模型于199610月成形,采纳UML作为其规范语言。199811月,微软加入MDC并提交OIM标准,19997MDC公布了OIMv1.0版本,由此业内面临着两种元数据集成规范的竞争局面,之后考虑到业内对CWM的认可,MDC20009月决定终止其OIM后续工作,将其元数据标准归入到OMG中,从此CWM阻碍力和范围持续扩大并得到了业内的统一认可。
OMG的模型驱动体系结构(Model Driven ArchitectureMDA
OMGObject Management ArchitectureOMA)参考模型,描述了OMG规范所遵循的概念化的基础结构。OMA是由对象请求代理(Object Request BrokerORB、对象服务、公共设施、域接口和应用接口等几个部分组成,其核心是对象请求代理(ORB。对象请求代37 / 160

ORB是公共对象请求代理体系结构Common Object Request Broker ArchitectureCORBA)的核心组件,提供了识不和定位对象、处理连接治理、传送数据和请求通信所需的框架结构。OMACORBA被定位为软件框架,用来指导基于OMG规范的技术开发。
1995年开始,OMG开始非正式的采纳针对特定行业(“领域”Domain)的技术规范,为了保持扩张重点,OMG2001Model Driven ArchitectureMDA。与OMACORBA不一样,MDA不是部署分布式系统的框架,而是在软件开发中基于模型驱动的方法。为了实现MDAOMG随后制定了一系列标准如UMLMOFXMICWM等,解决了MDA的模型建立、扩展、交换等几个方面的问题。模型驱动体系结构源自众所周知的和长期建立的思想:“将系统操作规范从系统利用底层平台能力的细节中分离出来”。MDA提供了一种方法(基于相关工具)来规范化一个平台独立的系统,为系统选择一个特定的实现平台,并把系统规范转换到特定的实现平台。MDA的首要三个目标是:可移植性、互操作性和可重用性。MDA三个视角(viewpoint[6]分不是:
38 / 160


计算无关视角(Computation Independent Viewpoint侧重系统环境和系统需求;系统结构和流程细节被隐藏或尚未确定。其对应的是计算无关模型(Computation Independent ModelCIM

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

平台相关视角(Platform Specific Viewpoint:结合平台无关系视角和系统所使用的特定平台细节。其对应的是平台相关模型Platform Specific Viewpoint ModelPSMPSM是包含技术和具体工程细节的模型。 OMG模型驱动体系结构如图5所示:
39 / 160


5 OMG模型驱动体系架构
CWM元模型、规范以及生成的产品同MDA特不契合,从技术平台角度来讲,所有的平台相关模型CWMXMLCWMIDLCWM Java等)差不多上自动地从平台无关模型(CWM元模型和规范)中产生的;从产品平台角度来讲,平台相关模型(比如DB2ORACLESQLSERVER等)差不多上人工从平台无关模型(CWM元模型和规范)中构造出来的。
结束语
本文详细介绍了大数据治理统一流程参考模型第二步“元数据集成体系结构”的后续内容,要紧包括元模型、-元模型、公共仓库元模型(CWMCWM进展史、对象治理组织OMG的模型40 / 160

驱动体系结构(Model Driven ArchitectureMDA。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型的第三步:“实施元数据治理”,讲述在大数据时代如何实施元数据治理,如何使用元数据治理成熟度模型,以及IBM在元数据治理方面的产品:业务元数据治理工具IBM Info Sphere Business Glossary、业务词汇表小工具Info Sphere Business Glossary AnywhereInfo Sphere Metadata Workbench
参考文献 [1]
更多信息请参考:OMG Model Driven Architecture :http://www.omg.org/mda/ ; [2] OMG,Common Warehouse Metamodel(CWMSpecification v1.1,P44 ; [3] John Poole,Dan Chang,Douglas Tolbert and David Mellor,2002,Common Warehouse Metamodel,p48-53,p58-63 ; [4] OMG,Common Warehouse Metamodel(CWMSpecification v1.1,P45 ; 41 / 160

[5] David Frankel Consulting,”Using Model Driven Architecture to Manage Metadata”,P46 ;
[6] OMG,2003,MDA Guide Version 1.0.1,p11-12,P15-16 ; 第三部分:实施元数据治理
了解了元数据治理策略和元数据集成体系结构之后,企业能够依照需要选择合适的业务元数据和技术元数据治理工具,并制定相应的元数据治理制度进行全面的元数据治理。本部分要紧介绍大数据治理统一流程参考模型第三步“实施元数据治理”,数据治理成熟度模型、IBM元数据治理相关工具等内容。
第三步:实施元数据治理
在明确了元数据治理策略和元数据集成体系结构之后,企业能够依照需要选择合适的业务元数据和技术元数据治理工具,制定相应的元数据治理制度进行全面的元数据治理。比如能够使 IBM InfoSphere Business Glossary 进行业务元数据的治理,使用 IBM InfoSphere Metadata Workbench 作为元数据治理统一工具并进行图形化的元数据分析。
大数据扩大了数据的容量、速度和多样性,给元数据治理带来了新的挑战。在构建关系型数据仓库、动态数据仓库和关系型42 / 160

数据中心时进行元数据治理,有助于保证数据被正确地使用、用并满足各种规定。同样,对大数据来讲,元数据治理过程中出现的任何错误,都会导致数据重复、数据质量差和无法访问关键信息等问题[1]。随着大数据技术在企业中的应用越来越广泛,企业需要在原有的元数据治理策略中增加大数据相关的内容。常,大数据分析是受用例驱动的,企业能够通过梳理大数据用例的方式逐步完善大数据的元数据治理。
针对大数据的业务元数据,依旧能够通过构建基础本体、域本体、任务本体和应用本体等的方式来实现。通过构建基础本体,实现对级不且通用的概念以及概念之间关系的描述;通过构建领域本体,实现关于领域的定义,并确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等,提供对该领域知识的共同理解;通过构建任务本体,实现任务元素及其之间关系的规范讲明或详细讲明;通过构建应用本体,实现对特定应用的概念描述,其是依靠于特定领域和任务的。如此就通过构建各种本体,在整个企业范围提供一个完整的共享词汇表,保证每个元数据元素在信息供应链中每个组件的语义上保持一致,实现是语义等效。
为了实现信息供应链中各个组件元数据的交互和集成,大数
43 / 160

据平台的元数据集成体系结构依旧能够采纳基于模型驱动的中央辐射式元数据体系结构。对大数据平台中的结构化数据的元数据治理能够遵循公共仓库元模型(CWM)构建元数据体系结构,以便方便的实现各个组件间元数据的交互;对大数据平台中的半结构化和非结构化数据的元数据治理,因为业内还没有通用的公共元模型,企业能够尝试采纳基于自定义模型驱动的方式构建中央辐射式元数据体系结构。
简单来讲,企业能够尝试以下步骤进行大数据的元数据治理: 1、考虑到企业能够猎取数据的容量和多样性,应该创建一个体现关键大数据业务术语的业务定义词库(本体),该业务定义词库不仅仅包含结构化数据,还能够将半结构化和非结构化数据纳入其中。
2、及时跟进和理解各种大数据技术中的元数据,提供对其连续、及时地支持,比如 MPP 数据库、流计算引擎、Apache Hadoop/企业级 HadoopNoSQL 数据库以及各种数据治理工具如审计/安全工具、信息生命周期治理工具等。
3、对业务术语中的敏感大数据进行标记和分类,并执行相应的大数据隐私政策。
44 / 160

4、将业务元数据和技术元数据进行链接,能够通过操作元数据(如流计算或 ETL 工具所生成的数据)监测大数据的流淌;能够通过数据世系分析(血缘分析)在整个信息供应链中实现数据的正向追溯或逆向追溯,了解数据都经历了哪些变化,查看字段在信息供应链各组件间转换是否正确等;能够通过阻碍分析能够了解具体某个字段的变更会对信息供应链中其他组件中的字段造成哪些阻碍等。
5、扩展企业现有的元数据治理角色,以适应大数据治理的需要,比如能够扩充数据治理治理者、元数据治理者、数据主管、数据架构师以及数据科学家的职责,加入大数据治理的相关内容。
在实施元数据治理的过程中,能够参照元数据治理的成熟度模型确定企业当前元数据治理所在层次,并依照业务需要制定路线图实现元数据治理水平的提升。元数据治理成熟度模型具体如1所示:
45 / 160


1 元数据治理成熟度模型
依照元数据治理的成熟度,大体能够分成6个级不,具体如1所示:

L0:初始状态
元数据分散于日常的业务和职能治理中,由某个人或某一组人员在局部产生或猎取,并在局部使用,其他人假如想获得该元数据需要找到相应的人进行沟通猎取。

L1:从属于业务系统
在那个时期,随着各个业务系统自动化构建完成,相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或部分治理起来。业务元数据可能分散在各种46 / 160

业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中,技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中,元数据之间互通互联困难,假如需要猎取其他系统的元数据,除了调阅各种文档外,对分散在各种中间件和业务系统中的技术元数据需要通过桥bridge的方式实现互通互联。

L2:元数据统一存储
元数据依旧在局部产生和猎取,但会集中到中央存储库进行存储,业务元数据会手工录入到中央存储库中,技术元数据分散在文档中的部分也通过手工录入到中央存储库中,而散落在各个中间件和业务系统中的技术元数据则通过桥bridge的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或部分通过手工方式做了关联。中央存储库的构建,使得元数据在整个企业层面可被感知和搜索,极大地点便了企业猎取和查找元数据。缺点是,元数据仍然在各业务系统上维护,然后更新到中央存储库,各业务竖井之间仍然使用不同的命名法,经常会造成相同的名字代表不同意义的情况,而同一件情况则使用了多个不同的名47 / 160

字,有些没有纳入业务系统治理的元数据则容易缺失。元数据没有有效的权限治理,局部元数据更改后也不自动通知其他人。

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

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


L5:元数据治理自动化
L5元数据治理是高度自动化的,当逻辑层次元数据变更时,会被传播到物理层次,同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流,以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统(元模型)他们之间的关系能够通过知识本体进行推断,因此各个应用系统之间的数据格式的映射自动产生。
IBM InfoSphere Information Server 元数据治理组件介绍 IBM InfoSphere Information Server 能够关心组织从分散在其系统中的各种复杂信息中猎取更多价值。它让组织能够整合分散的数据,在需要的地点和时刻,按顺序和关联关系把可信的InfoSphere Information Server 关心业务人员和 IT 人员进行协作,理解来自任何来源的任何类型的信息的含义、结构和内容。它能够显著提高在整个企业内一致且安全地清理、转换和交付信息的生产力和效率,如此就能够以新的方式访问和使用信息,从而促进创新、提高运营效率并降低风险。InfoSphere Information Server 让客户能够跨分析、运营和事务环境应用一致的可重复的流程以49 / 160

解决企业级数据问题,不受数据量、复杂性或延迟的限制。InfoSphere Information Server 的每个核心产品能够作为集成平台的一部分使用,也能够作为单独的集成产品使用。
这些产品由一个全面的集成服务平台支持,提供全程数据集成、元数据治理、任何数据源与任何平台上的任何应用程序之间的连接以及通过并行处理技术无限制地扩展。能够按任何配置部署这些功能以支持事件驱动或按时刻表执行的处理。还能够通过 InfoSphere Information Services Director “随需”使用 InfoSphere Information Server 数据集成功能, Enterprise Application Integration(EAIBusiness Process Management(BPMEnterprise Information Integration(EII Application Servers 集成基础设施。
InfoSphere Information Server 提供一个全面的模块化解决方案,能够依照业务需求和客户预算扩展。客户既能够部署完整的 InfoSphere Information Server 以处理整个企业数据集成生命周期,也能够使用单独的集成产品并依照需要添加其他组件。这种灵活的方式让客户既能够通过完整的 InfoSphere Information Server 实现全面集成,也能够通过购买一个或更50 / 160

免费下载 Word文档免费下载: 大数据治理系列教材

  • 29.8

    ¥45 每天只需1.0元
    1个月 推荐
  • 9.9

    ¥15
    1天
  • 59.8

    ¥90
    3个月

选择支付方式

  • 微信付款
郑重提醒:支付后,系统自动为您完成注册

请使用微信扫码支付(元)

订单号:
支付后,系统自动为您完成注册
遇到问题请联系 在线客服

常用手机号:
用于找回密码
图片验证码:
看不清?点击更换
短信验证码:
新密码:
 
绑定后可用手机号登录
请不要关闭本页面,支付完成后请点击【支付完成】按钮
遇到问题请联系 在线客服