大数据治理技术核心：元数据管理架构设计

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

元数据是什么？

数据中台的构建，需要确保全局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典，我们称之为元数据。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。 要理解元数据首先要知道“元”是什么。元数据意思是“与数据有关的数据”。元数据可以为数据说明其元素或属性（名称、大小、数据类型等），或结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。元数据起源于图书馆管理系统，我们便从图书中去解释元数据的概念吧。

一本书，书的封面和内页都向我们展示了这样的元数据信息：标题、作者姓名、出版商和版权细节、背面的描述、目录、页码。这个栗子可以看出，我们日常生活中，都会有相应的元数据信息保留下来。在数据治理中，元数据便是对于数据的描述，存储着关于数据的数据信息。我们可以通过这些元数据去管理和检索我们想要的“这本书”。有了元模型，就能根据元模型来采集元数据信息。这样一来，就能通过层层关键信息将重要目标展现出来。

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

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

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

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

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

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

元数据在数据仓库中的应用如下： 描述数据源的库表结构、数据关系以及每个数据项的定义； 描述数据源中每个数据项的值域范围和更新频率； 描述数据源与数据仓库之间的数据映射关系； 描述数据仓库中有哪些数据以及它们来自哪里； 描述数据在数据仓库各层中的加工处理过程； 元数据管理工具为数据管理者和使用者提供了理解和查询数据的一致语言； 利用元数据管理工具的元数据变更和版本管理功能，管理数据仓库的数据模型，支持将元数据恢复到某一版本； 利用元数据管理工具的血缘分析、影响分析等功能，对数据仓库中的数据问题快速定位、快速查找； 利用元数据管理工具的开放式元数据交换标准，实现数据仓库中数据的交换和共享。

下面我们用几个例子，举例说明元数据的作用。

数据治理之中，元数据是整个治理体系落地的技术核心。

比如：在数据标准中将数据标准作为一类业务元数据存储，将其和技术元数据一定程度的关联，去看标准的落地效果。

在数据质量中，通过元数据追溯质量问题。在共享发布中，利用元数据自动形成数据服务等等。

元数据还能够自动化的准确的管理应用的上线、变更， 通常企业系统建设会分为开发、测试与生产三个不同的环境，而在软件开发过程中，无论是需求变更还是BUG修改都避免不了元数据的改动，这时候往往会出现开发库、测试库测试通过，而在上线过程中又出现问题的情况，这会让运维部门非常头疼。

此时若通过元数据对系统的上线变更进行管理，自动采集三个环境的库表结构与存储过程等信息，保证各个环境中的元数据都是最新的、最准确的，再将上线环境与测试环境的元数据进行对比，不一致的地方一目了然。如果把系统的开发库、测试库、生产库的元数据都管理起来，上线时突然出现问题的概率就会大大降低。

通过扩展模型，元数据也能够管理微服务，微服务的生命周期有多个阶段，在前期需要与多个微服务协同考虑，上架后也会有多个使用者，在这种复杂的状况下需要管理微服务的全生命周期。

在规划阶段提供标准元数据规范微服务，在设计阶段提供连接其他微服务的元数据信息，在开发阶段使用元数据协助开发测试。

上线后分析微服务的使用情况，并协助维护微服务的变更。最后微服务下架时将微服务的元数据存档，并确保对目前体系不产生影响。

同时微服务的不同版本间的元数据的变化也可以做追溯和分析。

最后，未来元数据将是连接业务，数据与服务的企业核心基础设施，可扩展的元数据架构也能够产生更多更有价值的应用场景。