元数据管理数据中台的构建

　　元数据管理是随着数据仓库的建设逐渐完善起来的，这也决定了元数据管理主要集中在数据领域。例如数据结构、数据加工转换关系等。而随着我们对元数据理解的不断深入，其实元数据广泛存在于企业架构的方方面面，而不仅仅局限于数据领域里。
　　一、元数据是什么？数据中台的构建，需要确保全局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典，我们称之为元数据。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。
　　要理解元数据首先要知道元是什么。元数据意思是与数据有关的数据。元数据可以为数据说明其元素或属性（名称、大小、数据类型等），或结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。元数据起源于图书馆管理系统，我们便从图书中去解释元数据的概念吧。
　　一本书，书的封面和内页都向我们展示了这样的元数据信息：标题、作者姓名、出版商和版权细节、背面的描述、目录、页码。这个栗子可以看出，我们日常生活中，都会有相应的元数据信息保留下来。
　　在数据治理中，元数据便是对于数据的描述，存储着关于数据的数据信息。我们可以通过这些元数据去管理和检索我们想要的这本书。
　　有了元模型，就能根据元模型来采集元数据信息。这样一来，就能通过层层关键信息将重要目标展现出来。
　　元数据主要分种类型，分别是（数据字典数据血缘数据特征）。数据字典：描述的是数据的结构信息。主要包括表名注释信息表的产出任务每个表都有哪些字段这些字典分别代表什么含义字段的类型。数据血缘：一个表是直接通过哪些表加工而来。一般用于做影响分析和故障溯源。数据特征：主要指数据的属性信息，比如存储空间大小访问热度主题域分层表关联的指标。
　　元数据可以用5个纬度来评判其一，多业务线、多租户支持。其二，多数据源支持（比如mysql、Hive、Kudu等，半结构化的KV管理【kafka、redis、hbase】），同时还要支持相同数据源的多个集群。其三，数据血缘，元数据中心需要支持数据血缘的实时采集和高性能的查询，同时还要支持字段级别的血缘。其四，与大数据平台集成。元数据中心需要与ranger集成，实现基于tag的权限管理方式。其五，数据标签。必须支持对表和表中的字段打标签，通过丰富的不同类型的标签，可以完善数据中台数据的特征，比如指标可以作为一种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表。
　　其中比较难的是找到数据血缘，一般可以通过3种方式通过静态解析SQL，获得输入表和输出表通过实时抓取正在执行的SQL，解析执行计划，获取输入表和输出表通过任务日志解析的方式，获取执行后的SQL输入表和输出表
　　对产品经理而言，元数据管理平台通过对业务指标、业务术语、业务规则、业务含义等业务信息进行管控，协助业务人员了解业务含义、行业术语和规则、业务指标取数据口径和影响范围等。
　　元数据管理是随着数据仓库的建设逐渐完善起来的，这也决定了元数据管理主要集中在数据领域。例如数据结构、数据加工转换关系等。
　　而随着我们对元数据理解的不断深入，其实元数据广泛存在于企业架构的方方面面，而不仅仅局限于数据领域里。
　　因此，元数据管理的范围也在不断扩大，从简单的库表，到整个数据平台，再到服务管理，不断地突破传统管理的范畴，形成了广义元数据管理。
　　在这个过程中，对元数据的技术架构也有了新的要求，稳定可扩展的架构才是实现广义元数据管理的基础。
　　二、元数据管理的架构
　　三、要实现元数据管理有三个方面：
　　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层中就可以对元模型进行定义和扩展（例如CWM模型），将来还可以扩展到微服务模型、业务模型等。
　　六、元数据的管理：
　　第一步，以MOF规范设计元模型存储结构，从而支持元模型的扩展。
　　第二步，基于MOF设计元模型，例如将CWM（公共仓库元模型）规范中定义的元模型，存储在元模型中。
　　第三步，按照扩展后的元模型，采集元数据，存储到元数据系统中。
　　在元数据管理三层管理架构的支持下，通常只需要做元模型定义和元数据采集，就对不同元数据进行管理。
　　例如，要将表与字段元数据采集到元数据管理系统，只需要如下两步：
　　首先，对元模型定义并描述元数据特征，包括类属性描述、关系的描述等；
　　然后，将元数据采集进来，存储到系统中；
　　七、元数据的应用价值
　　良好的元数据架构，能够给元数据带来更多的应用价值。我们再看看元数据的应用价值。
　　通过元数据管理我们能够做到：
　　1、实现多样、繁杂的元数据信息集中管理，为企业数据（服务）管理提供统一的视图，实现企业级数据（服务）资产管理，方便数据（服务）交互共享，同时为后续规划提供依据；
　　2、通过管理维护数据（服务）之间关系，实现数据（服务）自动关联分析，为问题定位、影响分析、上线加速等提供支撑。
　　3、建立数据（服务）标准，统一交换、存储、应用口径，减少共享壁垒，降低应用出错几率，提升质量。
　　通过这些基本能力，元数据在数据管理、微服务管理、业务管理等方面都能发挥很大的作用。
　　通过元数据管理，在数据方面能做到：
　　1、数据标准化
　　2、数据开放
　　3、数据质量提升等
　　在微服务方面，能够提供以下支撑：
　　1、服务开发、应用等标准化；
　　2、服务应用监控，优化服务应用等
　　将来在业务方面也能通过元数据实现业务流程分析、业务流程优化等能力。
　　大家常见的是元数据在数据仓库中的应用，数据仓库是一个典型的分层设计的数据架构，其分层设计反映了数据在数据仓库中的加工处理过程。
　　元数据作为数据仓库的核心组成部分，主要用于记录和管理数据在数据仓库中的整个流转过程，实现对数据仓库各层级数据进行统一管理。