大数据治理技术核心，可扩展的元数据架构设计.docxVIP

PAGE 1 PAGE 1 大数据治理技术核心，可扩展的元数据架构设计  本文争论了什么是元数据，元数据管理的架构和应用价值，期望对大数据从业者有些许启发。  本文争论了什么是元数据，元数据管理的架构和应用价值，期望对大数据从业者有些许启发。  各位晚上好，很快乐能与大家共享对元数据架构与应用的一些思索。  首先简洁介绍下我自己，我2010年加入普元，目前负责普元大数据产品部，我和我的团队主要在做大数据治理相关的产品和解决方案。在来到普元之前在人民银行软件开发中心担当核心架构师，参与了人民银行的一些大型项目的建设。  整个共享分为三个部分：  第一部分，说说我和我的团队眼中的元数据。  第二部分简洁介绍如何实现元数据管理的架构。  第三部分，我将通过举例的方式，说明元数据的应用价值。  元数据是什么  元数据是信息的维度，可以说，把握了元数据就把握了信息的维度。  只有充分利用好元数据(也就是信息的维度)，通过合理的元数据建模(维度整合)，对元数据进行科学管理(维度完善)，才能更好地认知信息。  那么，就可以将元数据管理看成是这些信息概念和信息本身之间的一种连接。其中信息概念表示某个业务全部维度的集合，连接则是描述元数据与元数据之间关系的方式。  元数据管理是随着数据仓库的建设渐渐完善起来的，这也打算了元数据管理主要集中在数据领域。例如数据结构、数据加工转换关系等。  而随着我们对元数据理解的不断深入，其实元数据广泛存在于企业架构的方方面面，而不仅仅局限于数据领域里。  因此，元数据管理的范围也在不断扩大，从简洁的库表，到整个数据平台，再到服务管理，不断地突破传统管理的范畴，形成了广义元数据管理。  在这个过程中，对元数据的技术架构也有了新的要求，稳定可扩展的架构才是实现广义元数据管理的基础。  元数据管理的架构  要实现元数据管理有三个方面，  1、采集：指从各种工具中，把各种类型的元数据采集进来，采集是元数据管理第一步。  2、存储：采集之后需要相应的存储策略来对元数据进行存储，这需要在不转变存储架构的状况下扩展元数据存储的类型；  3、管理和应用：在采集和存储完成后，对已经存储的元数据进行管理和应用。  随着元数据管理范畴的不断扩大，如何保证元数据从采集、存储到应用等关键环节的稳定和扩展，成为元数据管理架构设计的关键问题。  OMG的模型体系规范为元数据管理供应了基础，所以整个元数据管理设计的关键应当以模型体系规范为指导。  OMG提出的CWM(CommonWarehouseMetamodel)规范对数据仓库相关的全部模型进行了描述，在初期我们也遵照此规范设计元数据管理的架构，但是规范里也有坑，我们很快就发觉了问题。  我们发觉CWM规范本质上是针对数据仓库领域的规范，根据OMG的模型体系来看，模型的抽象层次还是太低。  假如连续提高抽象层级，MOF规范位于模型体系最底层，全部模型体系规范的基础都应当是MOF(MetaObjectFacility)规范，UML，CWM都是由MOF扩展而来。  基于MOF的还有模型交换的规范XMI，为不同元数据交换供应了很好的模型基础。  那么若整个元数据围绕MOF设计和扩展，不用修改元数据管理核心部分，就可以适应元数据种类的不断扩展。  下面我们来看看如何设计元数据的存储。  元模型对元数据属性及关系进行了定义，一般来讲，元模型存储有两种方式。  1、第一种方式是将元模型转换成系统数据库表和属性，实现一对一管理存储。例如可以将主键元模型存储在主键记录表中、将存储过程元模型存储在存储过程记录表中等。  2、另一种方式是基于MOF元元模型把全部属性和关系打散，以此来实现元模型的通用存储结构。  如图所示，以CWM模型中关系型包为例进行说明，方式一是直接将元模型转化为库表，方式二根据元元模型的方式存储元模型；  尽管第二种实现方式上复杂度会更高一些，但是在扩展性有肯定优势，是元数据管理实现的优先选择方式。  再来看看模型体系的层次结构。  和元数据有关的体系分三层，M1(元数据)、M2(元模型)、M3(元元模型)，其中MOF元元模型中描述了包、元素、属性、命名空间和约束等对象及其关系，位于层次结构的最上层，也是最抽象的一层。  以MOF作为底层元元模型来支持元数据管理，在M2层中就可以对元模型进