大数据治理系列

大数据治理——为业务提供持续的、可度量的价值目录TOC\o"1-2"\h\z\u大数据治理——为业务提供持续的、可度量的价值1概述1大数据治理系列1第一局部：大数据治理统一流程模型概述和明确元数据管理策略2第二局部：元数据集成体系结构14第三局部：实施元数据管理24第四局部：大数据治理统一流程参考模型的第四步到第九步36第五局部：定义度量值和主数据监管52第六局部：大数据监管和信息单一视图监管66第七局部：分析监管、平安与隐私管理和信息生命周期监管79概述面对我们身边每时每刻迅速增长的庞大数据，因为其数量大、速度快、种类多和准确性的特征，如何更好地利用大数据创造出有意义的价值，一直是我们探索的重要话题。而在这之前，就需要用科学正确的方法策略对大数据进行治理。大数据治理是指制定与大数据有关的数据优化、隐私保护与数据变现的政策，是传统信息治理的延续和扩展，也是大数据分析的根底，还是连接大数据科学和应用的桥梁，因此大数据治理是大数据再创顶峰的“必修课〞。下面我们将与您分享新鲜出炉的大数据治理方案。大数据治理系列本系列共分为七个局部，围绕大数据治理统一流程参考模型，并结合实际业务问题和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]。在大数据时代，元数据还应该包括对各种新数据类型的描述，如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。元数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据主要包括业务规那么、定义、术语、术语表、运算法那么和系统使用业务语言等，主要使用者是业务用户。技术元数据主要用来定义信息供给链〔InformationSupplyChain，ISC〕各类组成局部元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖性等，以及存储过程、函数、序列等各种对象。操作元数据是指应用程序运行信息，比方其频率、记录数以及各个组件的分析和其它统计信息等。从整个企业层面来说，各种工具软件和应用程序越来越复杂，相互依存度逐年增加，相应的追踪整个信息供给链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中，元数据管理也逐渐从局部存储和管理转向共享。从总量上来看，整个企业的元数据越来越多，光现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业需要处理的数据类型越来越多。为了企业更高效地运转，企业需要明确元数据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据管理，并有步骤的提升其元数据管理成熟度。为了实现大数据治理，构建智慧的分析洞察，企业需要实现贯穿整个企业的元数据集成，建立完整且一致的元数据管理策略，该策略不仅仅针对某个数据仓库工程、业务分析工程、某个大数据工程或某个应用单独制定一个管理策略，而是针对整个企业构建完整的管理策略。元数据管理策略也不是技术标准或某个软件工具可以取代的，无论软件工具功能多强大都不能完全替代一个完整一致的元数据管理策略，反而在定义元数据集成体系结构以及选购元数据管理工具之前需要定义元数据管理策略。元数据管理策略需要明确企业元数据管理的愿景、目标、需求、约束和策略等，依据企业自身当前以及未来的需要确定要实现的元数据管理成熟度以及实现目标成熟度的路线图，完成根底本体、领域本体、任务本体和应用本体的构建，确定元数据管理的平安策略、版本控制、元数据订阅推送等。企业需要对业务术语、技术术语中的敏感数据进行标记和分类，制定相应的数据隐私保护政策，确保企业在隐私保护方面符合当地隐私方面的法律法规，如果企业有跨国数据交换、元数据交换的需求，也要遵循涉及国家的法律法规要求。企业需要保证每个元数据元素在信息供给链中每个组件中语义上保持一致，也就是语义等效〔semanticequivalence〕。语义等效可以强也可以弱，在一个元数据集成方案中，语义等效〔平均〕越强那么整个方案的效率越高。语义等效的强弱程度直接影响元数据的共享和重用。本体〔人工智能和计算机科学〕本体〔Ontology〕源自哲学本体论，而哲学本体论那么是源自哲学中“形而上学〞分支。本体有时也被翻译本钱体论，在人工智能和计算机科学领域本体最早源于上世纪70年代中期，随着人工智能的开展人们发现知识的获取是构建强大人工智能系统的关键，于是开始将新的本体创立为计算机模型从而实现特定类型的自动化推理。之后到了上世纪80年代，人工智能领域开始使用本体表示模型化时间的一种理论以及知识系统的一种组件，认为本体〔人工智能〕是一种应用哲学。最早的本体〔人工智能和计算机科学〕定义是Neches等人在1991给出的：“一个本体定义了组成主题领域的词汇的根本术语和关系，以及用于组合术语和关系以及定义词汇外延的规那么〞。而第一次被业界广泛接受的本体定义出自TomGruber，其在1993年提出：“本体是概念化的显式的表示〔规格说明〕〞。Borst在1997年对TomGruber的本体定义做了进一步的扩展，认为：“本体是共享的、概念化的一个形式的标准说明〞。在前人的根底上，Stude在1998年进一步扩展了本体的定义，这也是今天被广泛接受的一个定义：“本体是共享概念模型的明确形式化标准说明〞。本体提供一个共享词汇表，可以用来对一个领域建模，具体包括那些存在的对象或概念的类型、以及他们的属性和关系[2]。一个简单的本体例如发票概念及其相互关系所构成的语义网络如图2所示：图2简单本体〔发票〕例如随着时间的推移和技术的开展，本体从最开始的人工智能领域逐渐扩展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。与哲学本体论类似，本体〔人工智能和计算机科学〕依赖某种类别体系来表达实体、概念、事件及其属性和关系。本体的核心是知识共享和重用，通过减少特定领域内概念或术语上的分歧，使不同的用户之间可以顺畅的沟通和交流并保持语义等效性，同时让不同的工具软件和应用系统之间实现互操作。根据研究层次可以将本体的种类划分为“顶级本体〞〔top-levelontology〕、应用本体〔applicationontology〕、领域本体〔domainontology〕和任务本体〔taskontology〕，各个种类之间的层次关系如图3所示。图3本体层次关系顶级本体，也被称为上层本体〔upperontology〕或根底本体〔foundationontology〕，是指独立于具体的问题或领域，在所有领域都适用的共同对象或概念所构成的模型，主要用来描述高级别且通用的概念以及概念之间的关系。领域本体是指对某个特定的领域建模，显式的实现对领域的定义，确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解。领域本体所表达的是适合自己领域的术语的特定含义，缺乏兼容性，因而在其他领域往往不适用。在同一领域内，由于文化背景、语言差异、受教育程度或意识形态的差异，也可能会出现不同的本体。很多时候，随着依赖领域本体系统的扩展，需要将不同的领域本体合并为更通用的标准说明，对并非基于同一顶级本体所构建的本体进行合并是一项非常具有挑战的任务，很多时候需要靠手工来完成，相反，对那些基于同一顶级本体构建的领域本体可以实现自动化的合并。任务本体是针对任务元素及其之间关系的标准说明或详细说明，用来解释任务存在的条件以及可以被用在哪些领域或环境中。是一个通用术语的集合用来描述关于任务的定义和概念等。应用本体：描述依赖于特定领域和任务的概念及概念之间的关系，是用于特定应用或用途的本体，其范畴可以通过可测试的用例来指定。从详细程度上来分，本体又可以分为参考本体〔referenceontologies〕和共享本体〔shareontologies〕，参考本体的详细程度高，而共享本体的详细程度低。本体〔哲学〕哲学中的本体〔ontology〕也被称为存在论，源自哲学中“形而上学〞分支，主要探讨存在的本质，也就是存在的存在。英文ontology实际上就是来源于希腊文“ον〞〔存在〕和“λόγος〞〔学科〕的组合。本体是由早期希腊哲学在公元前6世纪到公元前4世纪提出的“始基〞延伸出来的。始基〔Principle，又称本原〕最早由泰勒斯〔米利都学派〕最早提出来，认为万物由水而生，其学生阿那克西曼德认为万物由一种简单的原质组成，该原质不是水[3]。而毕达哥拉斯〔学派〕认为“万物都是数〞，数不仅被看作万物的本原，而且被看作万物的原型、世界的本体。后来巴门尼德〔爱利亚学派〕提出了“存在〞的概念，认为存在才是唯一真正存在的真理，其创造了一种形而上学论证方式，之后的哲学一直到近时期为止，都从巴门尼德处接受了其“实体的不可消灭性〞。苏格拉底继承了巴门尼德的存在概念，主张“真正的善〞并完善了巴门尼德弟子芝诺的辩证法，其学生柏拉图提出了“理念论〞，认为只要假设干个个体拥有一个共同的名字，它们就有一个共同的理念或形式。亚里士多德〔柏拉图学生〕总结了先哲们的思想，完成了《形而上学》，并将本体总结为：对世界上客观存在事物的系统的描述，即存在论，也就是最形而上学的知识。形而上学不是指孤立、静止之类的意思，而是指超越具体形态的抽象意思，是关于物质世界最普遍的、最一般的、最不具体的规律的学问。第二步：元数据集成体系结构在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。各个企业的元数据管理策略和元数据管理成熟度差异较大，因此元数据集成体系结构也多种多样。大体上元数据集成体系结构可以分为点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于CWM〔CommonWarehouseMetaModel，公共仓库元模型〕模型驱动的点对点元数据集成体系结构、基于CWM模型驱动的中央存储库元数据集成体系结构、分布式〔联邦式〕元数据集成体系结构和层次/星型元数据集成体系结构等。针对信息供给链中不同的组件，为了实现跨组件的元数据交换和集成，最开始人们采用点对点的方式进行，也就是每一对组件之间通过一个独立的元数据桥〔metadatabridge〕进行元数据交换，桥一般是双向的能够理解两个方向的元数据映射[4]。点对点的元数据集成体系结构帮助用户实现了跨企业的元数据集成和元数据交换，对提升信息化水平提供了巨大帮助。这种体系结构在应用过程中，也暴露了很多问题，比方元数据桥的构建工作量和耗时都非常大，对中间件厂商、应用厂商、集成商和用户来说都是一个巨大的挑战，而且构建元数据桥还必须具有所有者的元数据模型和接口的详细信息。构建完成的桥很多时候无法在构建其他元数据桥时进行重用，因此开发和维护费用大幅度增加，用户投资回报率〔ROI〕不高。以动态数据仓库为例，其点对点的元数据集成体系结构具体如图4所示，信息供给链各组件之间的空心箭头表示全部的数据流，实心箭头表示不同的元数据桥和与之关联的元数据流。图4点对点的元数据集成体系结构通过使用中央元数据存储库〔centralmetadatarepository〕取代各个工具软件和应用程序之间的点对点连接方式，改成中央元数据存储库与各个工具软件和应用程序实现元数据交换的访问层〔也是一种桥〕，可以有效降低总本钱，减少建立点对点元数据桥的工作，提高投资回报率。信息供给链各组件可以从存储库访问元数据，不必与其他产品进行点对点交互。这种使用中央元数据存储库方式进行元数据集成的方式就是中央辐射式元数据体系结构〔hub-and-spokemetadataarchitecture〕，具体如图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〕。参考文献DavidFrankelConsulting,〞UsingModelDrivenArchitecture™toManageMetadata〞,P3;FredrikArvidssonandAnnikaFlycht-Eriksson,2023,OntologiesI,〞Anontologyprovideasharedvocabulary,whichcanbeusedtomodeladomain,thatis,thetypeofobjectsand/orconceptsthatexist,andtheirpropertiesandrelations〞;更多内容请参考:[专著]/(英)伯特兰.罗素/著孙绍武/主编<<西方哲学史>>;JohnPoole,DanChang,DouglasTolbertandDavidMellor,2002,CommonWarehouseMetamodel,p18-32,p180-202;本系列文章参考了SunilSoares编写的《TheIBMDataGovernanceUnifiedProcess》和《BigdataGovernance》书中内容｡第二局部：元数据集成体系结构在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。元数据集成体系结构涉及到多个概念，如元模型、元-元模型、公共仓库元模型〔CWM〕等，本局部将继续介绍大数据治理统一流程参考模型第二步“元数据集成体系结构〞的相关内容。在本系列的第一篇文章中，我们主要介绍了大数据治理的根本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略〞和第二步“元数据集成体系结构〞的六种例如等内容。大数据治理统一流程参考模型的第二步是“元数据集成体系结构〞，具体包括元模型、元-元模型、公共仓库元模型〔CWM〕、CWM开展史、OMG的模型驱动体系结构〔ModelDrivenArchitecture，MDA〕本文将对元数据集成体系结构包含的各种模型展开表达。大数据治理统一流程参考模型，第二步：元数据集成体系结构元模型〔Metamodel〕模型〔Model〕是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型〔Metamodel〕也就是模型的模型〔或者元-元数据〕，是用来描述元数据的模型。下面基于关系型表实体-关系〔ER〕模型举例说明什么是元模型。如图1所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必须有一个名字〔字符串〕，一个表可以有1到多个列，每个列必须有一个名字〔字符串〕和数据类型〔字符串〕：图1简单关系型表元模型如果要创立一个关系型表模型，基于该表元模型创立一个实例即可，比方创立一个常见的雇员表Employees表模型，具体如图2所示，Employees表包含6个列，分别是编号、姓、名字、部门编号、经理编号和职位编号。图2Employees表实例比方在DB2中创立employees表，可以很容易的从employees表模型中得到相应的DDL语句，执行DDL语句时DB2会生成描述employees表的内部元数据并存储在目录〔DB2内部的元数据存储库〕中。清单1在DB2中创立employees表例如Createtableemployees(Idintegernotnull，First_nameStringnotnull，Last_nameStringnotnull，Depart_IDIntegernotnull，Manager_IDIntegernotnull，Job_IDIntegernotnull)同样基于图1简单关系型表元模型创立另一个实例department表模型。department表包含2个列，分别是编号和部门名称，具体如图3所示。由于department表模型和employees表模型都是基于相同的公共元模型，其它工具和应用程序软件〔了解关系型表的公共元模型〕可以很容易理解department表和employees表，因为它们都是同一个元模型的实例。其它工具或应用程序通过调用导入映射〔importmapping〕将该department表模型或employees表模型翻译成自己内部的元数据实例。同样，也可以将该软件内部元数据翻译成一个与平台无关的形式化模型，也就是导出映射〔exportmapping〕，以便其他软件使用其专有的元数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结构[1]。图3department表实例元-元模型〔Meta-metamodel〕元-元模型就是元模型的模型，有时也被称为本体〔ontology〕，是模型驱动的元数据集成体系结构的根底，其定义了描述元模型的语言，规定元模型必须依照一定的形式化规那么来建立，以便所有的软件工具都能够对其进行理解。元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据〔模型〕那么是一个元模型的实例，遵守元模型的规定和约束。用户对象〔或用户数据〕那么是元数据〔或者称为模型〕的实例。元数据层次结构具体如表1所示，共分为4层，最高层L3是元-元模型，之下是L2元模型和L1模型/元数据，最底层是L0用户对象/用户数据：表1元数据层次结构元层次名称例如L3元-元模型元类、元属性、元操作L2元模型类、属性、操作、构件L1模型/元数据实体-关系〔ER〕图L0用户对象/用户数据交易数据、ODS数据、数据仓库数据、数据集市数据、数据中心数据等公共仓库元模型〔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〕。数据源层〔DataResources〕：主要描述CWM元数据交换中既可作为源又可以作为目标的数据源的结构，本层含有的元模型主要描述面向对象的数据库和应用、关系型数据库、面向记录的数据源〔如文件、记录数据库管理系统等〕、多维数据库和XML数据源等。对于面向对象数据源，CWM一般情况下重用根本的对象模型〔位于对象模型层〕，如果该数据源具有对象模型层无法处理的一些特征和功能时，可以通过定义一个扩展包来解决。数据分析层〔DataAnalysis〕：本层含有的元模型主要描述数据转换、在线分析处理OLAP、数据挖掘、信息可视化和业务术语等。仓库管理层〔WarehouseManagement〕：本层含有的元模型主要描述数据仓库处理和数据仓库操作。图4CWM1.1元模型CWM1.1是在2003年3月发布的，与之相关的OMG组织标准还有MOF、UML和XMI。CWM使用统一建模语言〔UML〕定义公共元数据的模型〔CWM元模型〕，使用可扩展标记语言〔XML〕生成CWM元数据交换标准〔也就是XML元数据交换，XMI〕，使用CORBA接口定义语言〔IDL〕为访问CWM元数据生成编程语言API的标准〔依赖MOF到IDL的映射〕。UML是一种标准化、可视化、描述明确、结构化和文档化的定义分布式对象系统的图形化语言。1996年，业内三种最杰出的面向对象建模语言：GradyBooch的Booch方法、IvarJacobson的面向对象软件工程〔OOSE〕和JimRumbaugh的对象建模技术〔OMT〕被统一起来发布，也就是UML0.9。2023年，发布。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用来作为面向对象元模型。元对象框架〔MetaObjectFramework，MOF，本文以版本为例〕是一个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的分布式对象集成框架。此框架支持各种类型的元数据，还可以根据需求添加新类型的元数据。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元模型、用户模型和用户对象/数据之间的关系。表2MOF四层元数据体系结构描述例如M3MOF,i.e.thesetofconstructsusedtodefinemetamodelsMOFClass,MOFAttribute,MOFAssociation,etc.M2Metamodels,consistingof

instancesofMOFconstructs.UMLClass,UMLAssociation,UMLAttribute,UMLState,UMLActivity,etc.CWMTable,CWMColumn,etc.M1Models,consistingofinstances

ofM2metamodelconstructs.Class“Customer〞,Class“Account〞

Table“Employee〞,Table“Vendor〞,etc.M0Objectsanddata,i.e.instancesofM1modelconstructsCustomerJaneSmith,CustomerJoeJones,Account2989,Account2344,EmployeeA3949,Vendor78988,etc.XML元数据交换〔XMI〕是在工具软件、应用程序之间进行元数据交换的XML语言，整合了UML、MOF和XML三种技术，允许MOF元数据〔即遵从MOF或基于MOF的元模型的元数据〕以流或文件的形式按照XML的标准格式进行交换。XMI是OMG在元数据交换方面的标准之一，同时也是W3C认可的标准。本质上，XMI是W3C的XML和MOF之间，以及XML文档和MOF元数据之间的一对平行映射。2023年8月，XML发布了。CWM开展史其实早在上世纪80年代末90年代初，很多企业就尝试使用一种元模型实现元数据集成以整合分布于各个业务竖井中的元数据，但最终失败了，因为很多的利益相关者各自拥有不同的观点，且需要不同的模型结构。1997年，OMG将UML采纳为标准，为CWM标准制定打下了第一个根底。同样在1997年，MOF被OMG采纳为标准，为CWM的产生打下了第二个根底。1999年初，OMG采纳XMI作为标准，为CWM的出现打下了第三个根底。1998年5月，IBM、ORACLE和Unisys向OMG提交了公共仓库元数据交换〔CommonWarehouseMetadataInterchange，CWMI〕征求意见稿〔RFP〕，同年9月OMG发布了该征求意见稿，经过8个公司〔IBM、Unisys、Oracle、Hyperion、UBS、NCR、Genesis和DimensionEDI〕2年半的努力和协作，OMG于2001年4月正式采纳CWM为标准。在CWM开展的同时，其他一些元数据标准的制定也在进行中。最早在1993年，电子信息组织就发布了计算机辅助工程数据交换格式〔CASEDataInterchangeFormat，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发布了OIMv1.0版本，由此业内面临着两种元数据集成标准的竞争局面，之后考虑到业内对CWM的认可，MDC于2000年9月决定终止其OIM后续工作，将其元数据标准归入到OMG中，从此CWM影响力和范围持续扩大并得到了业内的统一认可。OMG的模型驱动体系结构〔ModelDrivenArchitecture，MDA〕OMG组织成立不久制定了对象管理体系结构〔ObjectManagementArchitecture，OMA〕参考模型，描述了OMG标准所遵循的概念化的根底结构。OMA是由对象请求代理〔ObjectRequestBroker，ORB〕、对象效劳、公共设施、域接口和应用接口等几个局部组成，其核心是对象请求代理〔ORB〕。对象请求代理〔ORB〕是公共对象请求代理体系结构〔CommonObjectRequestBrokerArchitecture，CORBA〕的核心组件，提供了识别和定位对象、处理连接管理、传送数据和请求通信所需的框架结构。OMA和CORBA被定位为软件框架，用来指导基于OMG标准的技术开发。从1995年开始，OMG开始非正式的采用针对特定行业〔“领域〞，Domain〕的技术标准，为了保持扩张重点，OMG在2001年正式采用第二个框架，模型驱动体系架构〔ModelDrivenArchitecture，MDA〕。与OMA和CORBA不一样，MDA不是部署分布式系统的框架，而是在软件开发中基于模型驱动的方法。为了实现MDA，OMG随后制定了一系列标准如UML、MOF、XMI和CWM等，解决了MDA的模型建立、扩展、交换等几个方面的问题。模型驱动体系结构源自众所周知的和长期建立的思想：“将系统操作标准从系统利用底层平台能力的细节中别离出来〞。MDA提供了一种方法〔基于相关工具〕来标准化一个平台独立的系统，为系统选择一个特定的实现平台，并把系统标准转换到特定的实现平台。MDA的首要三个目标是：可移植性、互操作性和可重用性。MDA三个视角〔viewpoint〕[6]分别是：计算无关视角〔ComputationIndependentViewpoint〕：侧重系统环境和系统需求；系统结构和流程细节被隐藏或尚未确定。其对应的是计算无关模型〔ComputationIndependentModel，CIM〕。平台无关视角〔PlatformIndependentViewpoint〕：侧重系统的操作，同时隐藏用于特定平台的必要细节。其对应的是平台无关模型〔PlatformIndependentModel，PIM〕，PIM是抽出技术和具体工程细节之后的模型。平台相关视角〔PlatformSpecificViewpoint〕：结合平台无关系视角和系统所使用的特定平台细节。其对应的是平台相关模型〔PlatformSpecificViewpointModel，PSM〕，PSM是包含技术和具体工程细节的模型。OMG模型驱动体系结构如图5所示：图5OMG模型驱动体系架构CWM元模型、标准以及生成的产品同MDA非常契合，从技术平台角度来说，所有的平台相关模型〔CWMXML、CWMIDL和CWMJava等〕都是自动地从平台无关模型〔CWM元模型和标准〕中产生的；从产品平台角度来说，平台相关模型〔比方DB2、ORACLE、SQLSERVER等〕都是人工从平台无关模型〔CWM元模型和标准〕中构造出来的。结束语本文详细介绍了大数据治理统一流程参考模型第二步“元数据集成体系结构〞的后续内容，主要包括元模型、元-元模型、公共仓库元模型〔CWM〕、CWM开展史、对象管理组织OMG的模型驱动体系结构〔ModelDrivenArchitecture，MDA〕。在本系列文章的下一局部将重点介绍大数据治理统一流程参考模型的第三步：“实施元数据管理〞，讲述在大数据时代如何实施元数据管理，如何使用元数据管理成熟度模型，以及IBM在元数据管理方面的产品：业务元数据管理工具IBMInfoSphereBusinessGlossary、业务词汇表小工具InfoSphereBusinessGlossaryAnywhere和技术元数据管理工具InfoSphereMetadataWorkbench。参考文献更多信息请参考:OMGModelDrivenArchitecture:

;OMG,CommonWarehouseMetamodel(CWM)Specificationv1.1,P44;JohnPoole,DanChang,DouglasTolbertandDavidMellor,2002,CommonWarehouseMetamodel,p48-53,p58-63;OMG,CommonWarehouseMetamodel(CWM)Specificationv1.1,P45;DavidFrankelConsulting,〞UsingModelDrivenArchitecture™toManageMetadata〞,P46;OMG,2003,MDAGuideVersion1.0.1,p11-12,P15-16;第三局部：实施元数据管理了解了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择适宜的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。本局部主要介绍大数据治理统一流程参考模型第三步“实施元数据管理〞，元数据管理成熟度模型、IBM元数据管理相关工具等内容。第三步：实施元数据管理在明确了元数据管理策略和元数据集成体系结构之后，企业可以根据需要选择适宜的业务元数据和技术元数据管理工具，并制定相应的元数据管理制度进行全面的元数据管理。比方可以使用IBMInfoSphereBusinessGlossary进行业务元数据的管理，使用IBMInfoSphereMetadataWorkbench作为元数据管理统一工具并进行图形化的元数据分析。大数据扩大了数据的容量、速度和多样性，给元数据管理带来了新的挑战。在构建关系型数据仓库、动态数据仓库和关系型数据中心时进行元数据管理，有助于保证数据被正确地使用、重用并满足各种规定。同样，对大数据来说，元数据管理过程中出现的任何错误，都会导致数据重复、数据质量差和无法访问关键信息等问题[1]。随着大数据技术在企业中的应用越来越广泛，企业需要在原有的元数据管理策略中增加大数据相关的内容。通常，大数据分析是受用例驱动的，企业可以通过梳理大数据用例的方式逐步完善大数据的元数据管理。针对大数据的业务元数据，依旧可以通过构建根底本体、领域本体、任务本体和应用本体等的方式来实现。通过构建根底本体，实现对级别且通用的概念以及概念之间关系的描述；通过构建领域本体，实现对于领域的定义，并确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解；通过构建任务本体，实现任务元素及其之间关系的标准说明或详细说明；通过构建应用本体，实现对特定应用的概念描述，其是依赖于特定领域和任务的。这样就通过构建各种本体，在整个企业范围提供一个完整的共享词汇表，保证每个元数据元素在信息供给链中每个组件的语义上保持一致，实现是语义等效。为了实现信息供给链中各个组件元数据的交互和集成，大数据平台的元数据集成体系结构依然可以采用基于模型驱动的中央辐射式元数据体系结构。对大数据平台中的结构化数据的元数据管理可以遵循公共仓库元模型〔CWM〕构建元数据体系结构，以便方便的实现各个组件间元数据的交互；对大数据平台中的半结构化和非结构化数据的元数据管理，因为业内还没有通用的公共元模型，企业可以尝试采用基于自定义模型驱动的方式构建中央辐射式元数据体系结构。简单来说，企业可以尝试以下步骤进行大数据的元数据管理：1、考虑到企业可以获取数据的容量和多样性，应该创立一个表达关键大数据业务术语的业务定义词库〔本体〕，该业务定义词库不仅仅包含结构化数据，还可以将半结构化和非结构化数据纳入其中。2、及时跟进和理解各种大数据技术中的元数据，提供对其连续、及时地支持，比方MPP数据库、流计算引擎、ApacheHadoop/企业级Hadoop、NoSQL数据库以及各种数据治理工具如审计/平安工具、信息生命周期管理工具等。3、对业务术语中的敏感大数据进行标记和分类，并执行相应的大数据隐私政策。4、将业务元数据和技术元数据进行链接，可以通过操作元数据〔如流计算或ETL工具所生成的数据〕监测大数据的流动；可以通过数据世系分析〔血缘分析〕在整个信息供给链中实现数据的正向追溯或逆向追溯，了解数据都经历了哪些变化，查看字段在信息供给链各组件间转换是否正确等；可以通过影响分析可以了解具体某个字段的变更会对信息供给链中其他组件中的字段造成哪些影响等。5、扩展企业现有的元数据管理角色，以适应大数据治理的需要，比方可以扩充数据治理管理者、元数据管理者、数据主管、数据架构师以及数据科学家的职责，参加大数据治理的相关内容。在实施元数据管理的过程中，可以参照元数据管理的成熟度模型确定企业当前元数据管理所在层次，并根据业务需要制定路线图实现元数据管理水平的提升。元数据管理成熟度模型具体如图1所示：图1元数据管理成熟度模型根据元数据管理的成熟度，大体可以分成6个级别，具体如图1所示：L0:初始状态元数据分散于日常的业务和职能管理中，由某个人或某一组人员在局部产生或获取，并在局部使用，其他人如果想获得该元数据需要找到相应的人进行沟通获取。L1:附属于业务系统在这个阶段，随着各个业务系统自动化构建完成，相应的元数据也随着需求整理、设计、开发、实施和维护等过程被各个业务系统孤立的全部或局部管理起来。业务元数据可能分散在各种业务规章、流程规定、需求、需求分析和概要设计等文档以及业务系统中，技术元数据可能分散在详细设计、模型设计和部署方案等各种文档和各种中间件以及业务系统中。由于各个业务系统处于一个个竖井之中，元数据之间互通互联困难，如果需要获取其他系统的元数据，除了调阅各种文档外，对分散在各种中间件和业务系统中的技术元数据需要通过桥〔bridge〕的方式实现互通互联。L2：元数据统一存储元数据依然在局部产生和获取，但会集中到中央存储库进行存储，业务元数据会手工录入到中央存储库中，技术元数据分散在文档中的局部也通过手工录入到中央存储库中，而散落在各个中间件和业务系统中的技术元数据那么通过桥〔bridge〕的方式被读取到中央存储库中。业务元数据和技术元数据之间全部或局部通过手工方式做了关联。中央存储库的构建，使得元数据在整个企业层面可被感知和搜索，极大地方便了企业获取和查找元数据。缺点是，元数据仍然在各业务系统上维护，然后更新到中央存储库，各业务竖井之间仍然使用不同的命名法，经常会造成相同的名字代表不同意义的事情，而同一件事情那么使用了多个不同的名字，有些没有纳入业务系统管理的元数据那么容易缺失。元数据没有有效的权限管理，局部元数据更改后也不自动通知其他人。L3:元数据集中管理在L2的根底上做了改良，增强了元数据的集中控制，局部业务单元或开发小组如不事先通知其他人，将无法对元数据进行修改。局部元数据的修改完成后将被播送给其他人。和其他中间件和应用系统的交互，仍然通过桥〔bridge〕的方式进行，中央存储库中的业务元数据和技术元数据之间还是通过手工方式进行映射。L4：元模型驱动管理在L3的根底上，通过构建元模型以及元元模型，优化各业务单元之间的各种冲突和各种副本，创立、管理和共享业务词汇表和分类系统〔基于主题领域的层次结构〕。业务词汇表〔业务元数据〕包含与企业相关的词汇、词汇业务含义以及词汇与信息资产〔技术元数据〕的关系，可以有效帮助企业用户了解其业务元数据和技术元数据对应的业务含义。分类是基于主题领域的层次结构，用以对业务术语归类。和其他中间件和应用系统的交换，通过基于CWM的适配器方式进行连接。L5:元数据管理自动化在L5元数据管理是高度自动化的，当逻辑层次元数据变更时，会被传播到物理层次，同样物理层次变更时逻辑层次将被更新。元数据中的任何变化将触发业务工作流，以便其他业务系统进行相应的修改。由于各个业务系统遵照相同的业务词汇表和分类系统〔元模型〕，他们之间的关系可以通过知识本体进行推断，因此各个应用系统之间的数据格式的映射自动产生。IBMInfoSphereInformationServer元数据管理组件介绍IBMInfoSphereInformationServer可以帮助组织从分散在其系统中的各种复杂信息中获取更多价值。它让组织能够整合分散的数据，在需要的地方和时间，按顺序和关联关系把可信的信息交付给特定的人员、应用程序和流程。InfoSphereInformationServer帮助业务人员和IT人员进行协作，理解来自任何来源的任何类型的信息的含义、结构和内容。它可以显著提高在整个企业内一致且平安地清理、转换和交付信息的生产力和效率，这样就可以以新的方式访问和使用信息，从而促进创新、提高运营效率并降低风险。InfoSphereInformationServer让客户可以跨分析、运营和事务环境应用一致的可重复的流程以解决企业级数据问题，不受数据量、复杂性或延迟的限制。InfoSphereInformationServer的每个核心产品可以作为集成平台的一局部使用，也可以作为单独的集成产品使用。这些产品由一个全面的集成效劳平台支持，提供全程数据集成、元数据管理、任何数据源与任何平台上的任何应用程序之间的连接以及通过并行处理技术无限制地扩展。可以按任何配置部署这些功能以支持事件驱动或按时间表执行的处理。还可以通过InfoSphereInformationServicesDirector交付根底设施“随需〞使用InfoSphereInformationServer数据集成功能，从而补充EnterpriseApplicationIntegration(EAI)、BusinessProcessManagement(BPM)、EnterpriseInformationIntegration(EII)和ApplicationServers集成根底设施。InfoSphereInformationServer提供一个全面的模块化解决方案，可以根据业务需求和客户预算扩展。客户既可以部署完整的InfoSphereInformationServer以处理整个企业数据集成生命周期，也可以使用单独的集成产品并根据需要添加其他组件。这种灵活的方式让客户既可以通过完整的InfoSphereInformationServer实现全面集成，也可以通过购置一个或更多组件的许可证实现局部集成，以后可以添加其他组件以创立单一的集成解决方案。InfoSphereInformationServer可以提高从事数据集成工程的开发团队的生产力，改良这些开发团队之间以及开发人员与提出需求的业务用户之间的协作，促进工程团队内部和之间的重用，这些都会产生价值。为SAP、Oracle、PeopleSoft、Siebel、SalesForce等公司的企业应用程序预先构建的接口扩展了InfoSphereInformationServer的功能范围。这些包帮助公司通过企业数据仓库或ERP厂商业务智能化解决方案集成来自这些企业应用程序的数据，构建分析解决方案。InfoSphereInformationServer提供一套统一的可单独购置的产品模块(即套件组件)，可以解决多种类型的业务问题。可以跨工程重用信息检验、访问和处理规那么，这会提高一致性、增强对数据的管控并提高IT工程的效率。IBMInformationServer让企业能够实现5种关键的集成功能：连接任何数据或内容，无论它驻留在什么地方：大型机或分布式系统，内部或外部；了解并分析信息，理解数据源的内容、质量和结构，从而在整个企业中集成和传播数据之前全面了解数据；清理数据，确保数据的质量和一致性，让公司可以访问任何个人或业务实体及其关系的权威且一致的视图；转换大量数据，从而有效且高效地从原数据源向目标提供丰富的有针对性的信息；交付数据，让人员、流程和应用程序可以像访问单一资源一样访问和集成不同类型的数据和内容，无论信息驻留在什么地方。这些功能的根底是一个共用的元数据和并行处理根底设施，它为整个平台提供支持和自动化。产品组合中的每个产品还可以连接许多数据和内容源，能够通过多种机制交付信息。另外，可以通过便于发布的共享效劳在面向效劳架构中使用这些功能。IBMInformationServer提供：最广泛的访问信息源的能力；最全面的集成功能，包括联合、ETL、内联转换、复制和事件发布；在使用这些功能的方式方面的灵活性，包括支持面向效劳架构、事件驱动的处理、按时间表执行的批处理以及SQL和Java等标准API平台的功能广度和灵活性让它能够解决许多类型的业务问题，满足许多类型的工程的需求。这可以增加重用的时机，加快工程的速度，提高信息的一致性，增强信息治理。IBMInfoSphereInformationServer由以下组件组成:元数据效劳InfoSphereBusinessGlossaryInfoSphereBusinessGlossaryAnywhereInfoSphereMetadataWorkbenchInfoSphereInformationAnalyzerIBMInformationServerFastTrackInfoSphereQualityStageInfoSphereDataStageInfoSphereInformationServicesDirectorInfoSphereChangeDataDeliveryforInformationServerInfoSphereFederationServer元数据效劳是IBMInformationServer所基于的平台的组成局部。可以通过使用元数据效劳访问数据以及完成分析、建模、清理和转换等数据集成任务。IBMInformationServer的主要元数据效劳组件是InfoSphereBusinessGlossary、InfoSphereMetadataServer以及InfoSphereMetaBrokers和桥。InfoSphereBusinessGlossary是一个基于web的交互式工具，可以帮助用户创立、管理和共享业务词汇表和分类系统。业务词汇和技术信息资产保持一致可以促进业务和IT群体的协作，有助于更有效地治理数据。另外，这个工具的数据专员功能可以提升责任感，支持数据治理策略。InfoSphereMetadataWorkbench允许以基于web的方式查看IBMInfoSphereInformationServer和其他第三方应用程序生成和使用的信息资产。这个浏览工具可以提高对最重要的信息的信任程度。另外，InfoSphereMetadataWorkbench向IT人员提供健壮的查询功能和全面且灵活的数据世系报告，让他们可以深入了解环境中使用的数据，还可以监视数据集成活动。在处理数据集成工程中的变动时，强大的影响分析工具可以帮助数据分析师和开发人员做出更好的决策。InfoSphereBusinessGlossary介绍BusinessGlossary是用来管理和展示企业业务元数据的基于Web的交互式工具，支持用户创立、管理和共享业务词汇表和分类系统〔基于主题领域的层次结构〕。业务词汇表〔业务元数据〕包含与企业相关的词汇、词汇业务含义以及词汇与信息资产〔技术元数据〕的关系，可以有效帮助企业用户了解其业务元数据和技术元数据的对应的业务含义。BusinessGlossary可以使所有用户协同管理业务元数据比方元数据定义、同义词、样例和分类等，并提供多种查询方式，比方报表、条件查询、影响分析等。元数据应该由了解信息资产对业务的意义和重要性的人员进行管理。InfoSphereBusinessGlossary设计用于协作授权，使用户能够共享关于数据的见解和体验。产品为用户提供关于数据资源的以下信息：数据的商业意义和说明；数据和流程的管家；保证的业务等级；获准使用的术语；用户可根据可控词汇表定义的语义来组织并查找InfoSphereBusinessGlossary，您可使用Web控制台来创立可控词汇表。IBMBusinessGlossary业务术语管理分类如图2所示，通过业务术语管理可以实现：定义权威性的含义；增加对整个企业机构的业务理解；建立职责和可追溯的制度；描绘业务层次；记录业务描述，例如缩写和同义词；查找相关的信息资产；鼓励使用、重用和更正业务术语；让IT与业务目标更有效地结合；提供业务内容与IT资产的对应联系；建立职责和数据管控的政策。图2IBMInfoSphereBusinessGlossary业务术语管理分类通过使用BusinessGlossary解决方案可以帮企业带来很多价值，比方：获取业务术语并进行分类，基于Web的业务元数据生成、管理和共享；把业务术语及其分类与IT资产关联，为信息技术资产提供业务环境；识别数据使用者让业务术语可被访问，让每个用户可立刻访问有内涵的信息；让IT工程向数据管理看齐，创立和管理业务术语及关系，同时链接到物理数据源。加强业务与IT人员的通力合作，确立责任和义务，使IT部门的工作与业务部门的目标保持一致。BusinessGlossary与InformationServer其他组件以及第三方产品交互如图3所示，BusinessGlossary负责对业务元数据进行管理，MetadataServer作为中央共享元数据库负责存储业务、技术和操作元数据，InformationServer组件的各种开发和运行元数据将会自动存储在MetadataServer中，通过import/exportmanager还可以将第三方各种元数据与MetadataServer进行元数据交互，MetadataServer还支持导入CSV、XML、Glossaryarchive和InfoSphereDataArchitect等内容。MetadataWorkbench允许用户浏览、分析和管理在MetadataServer中的元数据并为企业用户提供信息供给链全程的数据流报告、数据沿袭和依赖性分析等。InformationServer其他组件〔如FastTrack/InformationAnalyzer/InfoSphereDataArchitect等〕可以直接访问MetadataServer获取元数据，DataStage和QualityStage可以通过DataStageConnectors访问MetadataServer。如右下方所示，访问业务元数据的方法有多种，可以通过BusinessGlossary浏览器浏览和搜索词汇表，可以通过BusinessGlossaryAnywhere客户机浏览词汇表内容并支持屏幕取词功能，可以通过BusinessGlossaryRESTAPI〔RepresentationalStateTransfer应用程序编程接口〕编写自己的程序来访问和修改业务词汇表内容，还可以通过BusinessGlossaryClientforEclipse插件让基于Eclipse的应用程序直接访问词汇表内容。BusinessGlossary还支持与CognosBI和IBMIndustryModels等集成。图3元数据管理体系结构图InfoSphereBusinessGlossaryAnywhere介绍IBMInfoSphereBusinessGlossaryAnywhere可以从在MicrosoftWindows计算机上翻开的任何文本文件直接访问业务词汇表。另外，InfoSphereBusinessGlossaryAnywhere附带IBMInfoSphereBusinessGlossaryClientforEclipse和IBMInfoSphereBusinessGlossaryRESTAPI。通过使用IBMInfoSphereBusinessGlossaryAnywhere，用户可以在执行其他基于计算机的任务的同时搜索业务词汇表，不会丧失上下文或分散注意力。用户可以通过鼠标或键盘操作在MicrosoftWindows桌面上翻开的文档中捕捉单词或短语，然后在业务词汇表内容中搜索它。用户不必另外翻开并登录InfoSphereBusinessGlossary，就可以使用大多数业务词汇表信息。InfoSphereMetadataWorkbench介绍IBMInfoSphereMetadataWorkbench是基于Web界面的元数据管理工具，对MetadaServer中的业务元数据和技术元数据提供完整的管理并提供元数据的完整视图，提供多种元数据导入导出功能。InfoSphereMetadataWorkbench可以在整个数据集成工程中跟踪和维护信息的关系，从而提高IT对业务人员的透明性和IT的响应能力。使用InfoSphereInformationServer产品中不同的模块用户，可以通过InfoSphereMetadataWorkbench查看InfoSphereInformationServer元数据存储库中的元数据和数据资产。MetadataWorkbench可以提供丰富的元数据分析，为整个信息供给链的元数据提供全程的数据流报告，提供基于字段或作业的数据沿袭〔也就是数据世系分析或血缘分析〕、影响分析和系统相关性分析等。例如某电信公司在前端展示工具CognosReportStudio中展示的掉话率指标明显和实际不符，可以通过MetadataWorkbench使用血缘分析上溯到数据源〔数据仓库、ODS、ETL、网管系统、EOMS〕并图形化的显示出该路径上的所有对象，方便查找在哪个环节出现问题。数据流报告显示数据从最开始的业务系统〔粒度到列级别〕、复制、ETL、ODS或数据仓库到前端展示报告或Dashboad完整的转移路径，包括其中对数据执行的处理的类型等。数据流报告方便业务人员了解信息的起源以及具体的转移过程，有助于进行数据世系分析，满足法律遵从性和可审计性需求。比方可以方便的找出前端展示报告中的某个字段的来源，某个Datastage作业将数据移动到什么位置等。数据世系分析可以跟踪整个企业的数据流〔即便数据没有保存在MetadataServer中〕，可以通过创立扩展映射和扩展数据源来跟踪数据流，为数据流中的任何资产创立扩展的数据世系分析报告。结束语本文详细介绍了大数据治理统一流程参考模型的第三步：“实施元数据管理〞，并详细讲述了在大数据时代如何实施元数据管理，随后介绍了元数据管理成熟度模型，帮助企业可以参考该模型衡量自己当前元数据管理水平，最后简单介绍了IBM在元数据管理方面的产品：业务元数据管理工具IBMInfoSphereBusinessGlossary、业务词汇表小工具InfoSphereBusinessGlossaryAnywhere和技术元数据管理工具InfoSphereMetadataWorkbench。在本系列文章的下一局部将重点介绍大数据治理统一流程参考模型第四步“定义业务问题〞、第五步“获得主管支持〞、第六步“执行成熟度评估〞、第七步“构建路线图〞、第八步“建立组织蓝图〞和第九步“了解数据〞等内容，并继续介绍IBM信息效劳器中的InfoSphereInformationAnalyze、InfoSphereFederationServer、InfoSphereReplicationServer和InfoSphereChangeDataCapture等。InfoSphereInformationAnalyze是一款数据质量分析工具软件，用来在工程初期对数据源进行数据质量分析，以便真正地了解源数据的结构、质量和数据分布等，提早发现数据的缺失、错误、重复和不一致等问题，为后面的数据复制、ETL等过程提供支持，以便降低工程实施风险。参考文献SunilSoares,“BigDataGovernance〞,Part7；本章参考了IBM相关产品的信息中心、白皮书、方案建议书以及其他各种资料。第四局部：大数据治理统一流程参考模型的第四步到第九步如果想要成功地实施大数据治理方案，需要了解信息供给链中的各个环节的数据模型、主外键关系等。本局部主要介绍大数据治理统一流程参考模型第四步“定义业务问题〞、第五步“获得主管支持〞、第六步“执行成熟度评估〞、第七步“构建路线图〞、第八步“建立组织蓝图〞和第九步“了解数据〞等内容。第四步：定义业务问题如何准确的定义和描述业务问题是数据治理方案成功的关键，企业可以从对特定问题或领域进行数据治理的紧迫程度以及数据治理能够带来的价值来综合衡量，对排名靠前的问题或领域优先进行数据治理，这样能充分获得业务职能部门以及IT部门的支持，从而保证数据治理方案的成功。数据治理初始范围确定后，执行具体的数据治理工作，等成功后再考虑扩展至其他领域。总结以往很多企业进行数据治理失败的原因时可以发现很多经常出现的病症，比方：企业未从数据治理中获得任何价值；数据治理过于长期，和企业专注短期目标不符；IT部门应对数据质量负责；IT部门认为数据治理过于复杂，无法顺利落地；企业为数据管理员分配了其他职责。分析以上问题出现的根源，可以发现数据治理方案失败的根本原因在于与业务价值缺乏关联，IT部门单独进行数据治理，没有和相关业务部门进行联动。数据治理需要所有利益相关方参与，可以从业务角度〔而不是技术角度〕总结出各种数据治理的价值，从而吸引相关业务领域高层领导的支持，从而保证数据治理可以获得更高的业务收益。举例说明如何定义业务问题，很多上市公司财报都被监管机构要求提供其数据来源并证明其数据可信，而报告本身所使用的数据流经信息供给链多个组件〔如立方体、数