元数据管理是随着数据仓库的建设逐渐完善起来的，这也决定了元数据管理主要集中在数据领域。例如数据结构、数据加工转换关系等。而随着我们对元数据理解的不断深入，其实元数据广泛存在于企业架构的方方面面，而不仅仅局限于数据领域里。

一、元数据是什么？

数据中台的构建，需要确保全局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典，我们称之为元数据。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。

要理解元数据首先要知道“元”是什么。元数据意思是“与数据有关的数据”。元数据可以为数据说明其元素或属性（名称、大小、数据类型等），或结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。元数据起源于图书馆管理系统，我们便从图书中去解释元数据的概念吧。

一本书，书的封面和内页都向我们展示了这样的元数据信息：标题、作者姓名、出版商和版权细节、背面的描述、目录、页码。这个栗子可以看出，我们日常生活中，都会有相应的元数据信息保留下来。

在数据治理中，元数据便是对于数据的描述，存储着关于数据的数据信息。我们可以通过这些元数据去管理和检索我们想要的“这本书”。

有了元模型，就能根据元模型来采集元数据信息。这样一来，就能通过层层关键信息将重要目标展现出来。

元数据主要分３种类型，分别是（数据字典＼数据血缘＼数据特征）。

• 数据字典：描述的是数据的结构信息。主要包括表名＼注释信息＼表的产出任务＼每个表都有哪些字段＼这些字典分别代表什么含义＼字段的类型。
• 数据血缘：一个表是直接通过哪些表加工而来。一般用于做影响分析和故障溯源。
• 数据特征：主要指数据的属性信息，比如存储空间大小＼访问热度＼主题域＼分层＼表关联的指标。

元数据可以用5个纬度来评判

• 其一，多业务线、多租户支持。
• 其二，多数据源支持（比如mysql、Hive、Kudu等，半结构化的KV管理【kafka、redis、hbase】），同时还要支持相同数据源的多个集群。
• 其三，数据血缘，元数据中心需要支持数据血缘的实时采集和高性能的查询，同时还要支持字段级别的血缘。
• 其四，与大数据平台集成。
• 元数据中心需要与ranger集成，实现基于tag的权限管理方式。
• 其五，数据标签。
• 必须支持对表和表中的字段打标签，通过丰富的不同类型的标签，可以完善数据中台数据的特征，比如指标可以作为一种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表。

其中比较难的是找到数据血缘，一般可以通过3种方式

• 通过静态解析SQL，获得输入表和输出表
• 通过实时抓取正在执行的SQL，解析执行计划，获取输入表和输出表
• 通过任务日志解析的方式，获取执行后的SQL输入表和输出表

对产品经理而言，元数据管理平台通过对业务指标、业务术语、业务规则、业务含义等业务信息进行管控，协助业务人员了解业务含义、行业术语和规则、业务指标取数据口径和影响范围等。

元数据管理是随着数据仓库的建设逐渐完善起来的，这也决定了元数据管理主要集中在数据领域。例如数据结构、数据加工转换关系等。

而随着我们对元数据理解的不断深入，其实元数据广泛存在于企业架构的方方面面，而不仅仅局限于数据领域里。

因此，元数据管理的范围也在不断扩大，从简单的库表，到整个数据平台，再到服务管理，不断地突破传统管理的范畴，形成了广义元数据管理。

在这个过程中，对元数据的技术架构也有了新的要求，稳定可扩展的架构才是实现广义元数据管理的基础。

二、元数据管理的架构

三、要实现元数据管理有三个方面：

1、采集：指从各种工具中，把各种类型的元数据采集进来，采集是元数据管理第一步。

2、存储：采集之后需要相应的存储策略来对元数据进行存储，这需要在不改变存储架构的情况下扩展元数据存储的类型;

3、管理和应用：在采集和存储完成后，对已经存储的元数据进行管理和应用。

随着元数据管理范畴的不断扩大，如何保证元数据从采集、存储到应用等关键环节的稳定和扩展，成为元数据管理架构设计的关键问题。

OMG的模型体系规范为元数据管理提供了基础，所以整个元数据管理设计的关键应该以模型体系规范为指导。

OMG提出的CWM(Common Warehouse Metamodel)规范对数据仓库相关的所有模型进行了描述，在初期我们也遵照此规范设计元数据管理的架构，但是规范里也有坑，我们很快就发现了问题。

我们发现CWM规范本质上是针对数据仓库领域的规范，按照OMG的模型体系来看，模型的抽象层次还是太低。

如果继续提高抽象层级，MOF规范位于模型体系最底层，所有模型体系规范的基础都应该是MOF(Meta Object Facility)规范，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、服务应用监控，优化服务应用等

将来在业务方面也能通过元数据实现业务流程分析、业务流程优化等能力。

大家常见的是元数据在数据仓库中的应用，数据仓库是一个典型的分层设计的数据架构，其分层设计反映了数据在数据仓库中的加工处理过程。

元数据作为数据仓库的核心组成部分，主要用于记录和管理数据在数据仓库中的整个流转过程，实现对数据仓库各层级数据进行统一管理。

（图来源《一本书讲透数据治理：战略、方法、工具与实践》）

来源：数据产品之美