元数据管理系统

数据治理工具–元数据系统
数据服务基础能力之元数据管理
元数据管理系统设计

1.元数据概述

1.1 介绍

如果想建设好元数据系统，需要理解元数据系统的相关概念，如数据、数据模型、元数据、元模型、ETL、数据血缘等等。

首先，要清楚数据的定义、数据模型的定义。数据一般是对客观事物描述的抽象，在数据库维度，数据是数据记录的简称，例如，个人的基本信息、产品信息等。数据模型是数据特征的抽象，它从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架。数据模型所描述的内容有三部分，分别是数据结构、数据操作和数据约束。

数据结构：数据模型中的数据结构主要描述数据的类型、内容、性质以及数据间的联系等。数据结构是数据模型的基础，数据操作和约束都建立在数据结构上。不同的数据结构具有不同的操作和约束。

数据操作：数据模型中数据操作主要描述在相应的数据结构上的操作类型和操作方式。

数据约束：数据模型中的数据约束主要描述数据结构内数据间的语法、词义联系、它们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效和相容。

其次，元数据和元模型。元数据是数据的数据，这句话好抽象、好难理解。结合数据模型的定义，我们把这句话丰富下，换成“元数据是数据记录的数据模型”。元模型是关于模型的模型，同理也是抽象、晦涩、难以理解，如果将这句话换成“元模型是元数据的数据模型”，是不是瞬间理解了。

需要注意的是，这两句转换内容只是为了方便初学者去理解和阅读接下来的大部分内容，随着时间的推移，个人对元数据认知的加深，请抛弃这两个转换内容，因为这两句话的描述是以狭隘的定义去描述元数据和元模型，会禁锢你对元数据和元模型的理解。

图 1 元数据、元模型与数据关系

然后， ETL、数据血缘。ETL是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL是数据仓库技术，也经常用于数据湖、数据仓库、数据中台等项目建设中，但其对象并不限于数据仓库。

数据血缘是数据溯源的过程中找到相关数据之间的联系，它是一个逻辑概念。基于数据血缘，还需要了解血缘分析、影响分析、数据全链路。

血统分析一般情况下采用图形方式展示了以某个元数据为终止节点，其前与其有关系的所有元数据，反应数据的来源与加工过程，使用血统分析可分析数据来源、标准贯标关系、数据质量问题追溯等。

影响分析一般情况下采用图形方式展示了以某个元数据为起始节点，其后与其有关系的所有元数据，反应数据的流向与加工过程，使用影响分析可分析元数据变更导致下游数据加工、数据关联的定位。

数据全链路分析，又称数据全链路地图，简称数据全链路，是血缘分析和影响分析的总和，是以当前元数据为节点，向上了解数据流向和加工过程的为血缘分析，向下了解数据流向和加工链路的为影响分析，一般情况下采用图形方式展示所有元数据节点的数据加工、关联节点。

图 2 ETL与数据全链路分析关系

图 3 数据全链路分析与血缘分析和影响分析的关系

最后，再根据实际情况去了解其他相关概念来丰富对元数据的理解。没有元数据，无法了解数据的真实意义。元数据看起来是一堆晦涩、无意义的文字和数字，但它能为企业的各类数据提供上下文环境，使企业能更好地了解、使用和管理数据，进而体现数据的价值。

1.2 建设意义

如果想梳理企业数据资产，了解企业数据加工逻辑，发现企业数据质量隐患，整理企业数据标准，建设数据中台，开展数据治理工作等，你会发现，方方面面或多或少的都和元数据有千丝万缕的联系。因为元数据是数据的数据，它是一切工作开展的切入点，如，想了解数据资产，元数据就能给你提供描述数据资产的定义；想查看、申请数据资产，可以基于元数据去控制查看范围、申请流程。

简单来说，元数据系统作为元数据管理态的系统，可以把各种各样复杂的信息统一管理起来，方便企业在数据层面，纵观全局的了解数据定义进而开展数据中台建设、数据治理工作建设、数据质量工作建设、数据资产相关工作建设。

1.3 视角分析

元数据是描述数据的数据，是数据的业务涵义、技术涵义和加工处理过程的定义，是数据管控的基本对象。企业要想知道拥有什么数据，数据在哪里，数据当前归属情况，数据的生命周期是什么，那些数据是需要做数据安全保护，数据质量如何开展，都离不开元数据的管理。因此，可以说，元数据系统为用户更好的认识数据、分析数据、挖掘数据提供了强有力的工具，是用户的数据由沉默到可用，由资源到资产的基石。

图 1 元数据系统视角分析

1.4 建设内容

元数据系统建设范围非常宽泛，当前市面上每个厂商的元数据系统都不尽相同，各有各的特点。最早的元数据系统建设能追溯到十余年前，那时候的元数据理念跟现在也有些不同，如采集元数据的方式、范围等。

下图元数据系统建设的内容是参考市面主流元数据系统、《信通院元数据测评要求》以及本人对元数据的理解，结合自己的产品经验、实施经验、咨询经验将常见的功能整理如下。

系统建设的内容其实不重要，重要的是解决咨询过程中、实施过程中客户问题，这部分内容不在这里赘述，后续会在数据治理咨询、数据治理实施章节中陈述。

图 2 元数据系统建设范围图

下面介绍重点几个系统功能逻辑。

2 元数据管理系统设计与实现

元数据管理系统设计
别人家的元数据系统是怎么设计的
元数据平台治理

2.1 从零搭建元数据管理平台

如何从零搭建元数据管理平台 | geosmart.io

2.1.1 关键问题

怎么定义元数据？
元数据平台要解决哪些问题？
如何获取元数据？
- 数据来源规划
如何存储元数据？
- 数据血缘如何构建
如何提供元数据服务？
- 数据源变更处理方式

2.1.2 元数据是什么？

一般来说是数据的数据。具体来说，就是对动态数据的一种静态信息描述。狭义的元数据我们一般指的是数据集，表本身的信息（结构，量级，归属，修改历史）以及表与表之间的关系；实际在数据流处理中，元数据的类型可以按数据处理的生命周期来细分：

最原始的数据实体，称为模式元数据，如数据的表结构Schema信息，业务属性信息
数据实体之间的处理逻辑，叫做etl数据处理，接着有了数据实体的关系元数据，数据的血缘关系信息
对于这些数据处理的逻辑形式，需要调度器来物理化执行，所以有了调度元数据
数据处理完成之后，需要发布报表，就有了报表元数据，各类统计信息
整体系统中，会涉及不同的用户实体，就有了用户元数据，读写记录，权限归属

元数据系统的建立，是企业级的信息化建设过程。

2.1.3 元数据平台是什么？

数据治理是一个庞大的系统，其中主要包括数据管控，数据质量，数据安全，数据标准。其中数据管控的目标是让每一项数据变更都能得到明确记录及授权，使得数据系统变得可控，可追溯。而数据管控的核心就是搭建元数据平台，这样才能开始数据的规范化，才能做到管控；

2.1.4 元数据平台解决什么问题？

通过元数据建设，为使用数据提效，解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。

数据问题：多种存储形式的数据来源（mysql、hive、hbase、es）、数据变化评率高；
数据使用问题：查看表信息（结构、量级、所属、是否可用）、表依赖（血缘统计）；
数据管理问题：表权限管理、数据质量管控、数据接入管理；

2.1.5 元数据平台包含哪些功能？

核心功能是实现数据地图功能；数据地图以数据搜索为基础，提供表使用说明、数据类目、数据血缘、字段血缘等工具，帮助数据表的使用者和拥有者更好地管理数据、协作开发。

元数据采集
元模型构建
元数据服务
元数据应用

2.1.6 元数据来源

2.1.6.1 元数据的获取形式

```
pull：元数据管理平台根据用户的数据源定制工具抓取元数据
```
- 优点：用户不需要对接平台
- 缺点：平台维护成本高，用户数据结构变更后，可能需要重新对接

push：用户调用元数据管理平台接口提交元数据更新

元数据平台以消息队列异步处理

2.1.6.2 元数据的业务来源

知识线：智能问答、问答社区的埋点、反馈数据；
营销线：财税学院、学会app的埋点、用户、课程数据；
金融线：企业风控特征、贷后数据。

2.1.6.3 如何存储元数据？

元数据的主体主要是实体以及关系。

实体：user、dataset、report、job、metrics
数据实体用关系数据库存储，如MySQL
元数据之间的关系用图数据库存储，如Neo4j
用全文索引实现快速搜索，如ElasticSearch

2.1.6.4 如何提供元数据服务？

2.2 元数据管理系统设计

元数据管理系统设计

2.2.1 元数据管理系统设计

2.2.2 数据表管理模块

数据表信息维护需要如下信息：

表的元数据信息（引擎、字段等）
表类型（维表或事实表）
表的使用情况（是否被模型使用）
表对应的ETL
描述信息
表的所有人
表的建表语句

2.2.3 模型管理模块

模型分为数据表模型和 SQL模型

2.2.3.1 数据表模型管理

需要维护如下信息：

事实表名称（必填）
备注信息

关联配置

主数据表（表名）
关联方式（join、left join、semi join）
关联表
关联字段（关联字段，关联关系(=,)）
关联限制（限制字段，限制关系，限制值）
模型ER图（绘制表关系图）

模型详情

数据表
字段名称
字段类型
字段描述
是否使用
维度信息

2.2.3.2 SQL模型

数据主题（业务用途）
查询引擎（查询工具）
SQL语句

模型详情

字段名称
字段类型
字段描述
维度信息
是否使用

2.2.4 维度管理模块

维度名称
业务定义
业务分类
维表
是否是日期维
对应code
对应name
绑定维表（如果有维表）

2.2.5 指标管理模块

包括基础信息管理、技术信息管理、关联指标管理、关联应用管理

核心部分是指标与模型的绑定关系，通过使用演进形成了当前系统两类绑定关系：绑定物理模型和构建虚拟模型。

绑定物理模型是指标与模型管理中的物理模型字段绑定，并配置对应的计算公式，或还包含一些额外的高级配置，如二次计算、模型过滤条件等；
创建虚拟模型是通过已有指标和其对应的物理模型，具体步骤首先配置已有指标的计算方式或指标维度的过滤，然后选择指标已绑定的物理模型，形成一个虚拟模型，虚拟模型的分析维度就是所选指标基础模型的公共维度。

基础信息管理(业务维护)

指标名称
业务分类
统计频率
精度
单位
指标类型
指标定义
计算逻辑
分析方法
影响因素
分析维度

技术信息管理（技术维护）

指标名称（必填）
数据类型

模型信息

模型名称
筛选指标
公共引擎
查询引擎

基础指标信息

基础指标
业务线/主题
指标代码
数据模型
支持维度

计算公式
分析维度
场景描述

基础模型信息

数据模型名称
查询引擎
绑定字段
计算公式
操作人
操作时间
支持维度

2.2.6 应用管理

应用管理由数据应用、外部应用、数据地图三大模块组成，它们构成了对外服务的主体，记录了外部应用与平台内管理的指标、维度、模型和表的关联关系，也提供数据查询展示、应用层ETL生产的能力。而且数据开发人员从底层向上观察，可以追踪数据最终的所有流向；业务分析人员从顶层向下观察，可以看到构成服务的所有数据来源。

2.2.6.1 数据应用模块

数据应用模块是记录生成每个服务所需的指标、维度和数据模型的关系。每次服务中可以包含多个指标，这些指标可以来源于多个数据模型，不过不同的数据模型中需要包含公共维度，因为是通过这些公共维度将不同模型关联起来。

数据应用中构建的服务可以发布成查询服务、应用层ETL生产服务、对外API数据接口服务、通用报表配置服务，来满足业务的不同需求

需要信息：

应用名称
查询引擎

统计指标列表

统计指标
指标代码
数据模型
支持维度

分析维度列表

where条件

逻辑运算
过滤字段
是否为动态参数
比较运算
值
操作

备注

需要功能：

生成SQL
执行查询

2.2.6.2 外部应用模块

外部应用模块管理外部应用和应用内的模块，以及这些模块订阅的对应数据应用，目标是实现API接口调用的权限管理和数据最终流向的记录。

具体的实现上模块

首先创建对应的外部应用，记录：

对应的外部应用
记录外部应用的名称
URL
-APPKEY等信息

然后由对应应用的负责人创建模块，记录：

模块名称
URL
moduleKey等信息。

这些信息完善后，由对应的数据应用赋权给对应的模块，建立起数据应用与外部应用的联系。最后在外部应用调用平台对外API接口时，进行权限管理。

2.2.6.3 数据地图

数据地图功能是追查数据的流向，可以从数据表、模型、指标、数据应用、外部应用任意节点查看上游数据来源和下游数据去向

2.3 元数据管理与架构设计

一文彻底了解元数据管理与架构设计

2.3.1 元数据治理在整个数据治理体系的位置

数据治理很火，在 DAMA 数据管理知识体系指南中，数据治理位于 “数据管理车轮图” 的正中央，如下图：

而元数据管理，正是十大数据管理领域其中很重要的一环。

数据资产治理的前提是要有数据，并且要求数据类型全、量大，并尽可能的覆盖数据流转的各个环节。元数据的采集和管理就变得尤为重要，它是数据资产治理的核心底座。

2.3.2 什么是元数据

所谓元数据，就是 “关于数据的数据”。举一个例子，比如 175 这个数字，它在特定场景下，有如下的元数据：

在这个表格中，175 是实体数据，而业务元数据、技术元数据、操作元数据、管理元数据，从各种不同的角度描述了 175 这个数字，他们都属于元数据。

可以再举个例子，元数据就像 “户口本”，户口本中除了有姓名、出生日期、住址、民族等信息外，还有家庭的血缘关系，父子关系，兄弟关系等。这些信息就构成了对这个人的详细描述，这些信息就是描述这个人的元数据。

对于数据平台来说，收集各类元数据可以帮助数据平台回答下面的问题：

我们有哪些数据？
有多少人在使用？
数据存储是多少？
如何查找这些数据？
数据的流转是怎么样的？
通过血缘关系进行溯源和问题分析。

2.3.3 元数据的分类

元数据的分类，一般来说可分为：

技术元数据
业务元数据
操作元数据
管理元数据

但其实元数据的分类并没有那么的严格，因为有些指标在不同的视角下可能属于不同的分类。

举个例子，比如数据安全等级，对于安全部门来说就是业务元数据了，但是在开发部门来看，就是一种管理元数据。

2.3.3.1 技术元数据

1、数据库对象属性；

2、物理数据库表名，备注，主键，索引

3、物理表的大小，行数，文件数，分区数，存储类型，表类型，索引名称，索引字段，索引类型，约束

4、字段属性，包括字段名，字段注释，字段类型，是否主键，是否自增，是否外键等等；

5、ETL 作业详细信息，名称，责任人，脚本，任务配置（执行时间，执行频率，是否互斥，上游依赖等），任务调度时长，产出信息等；

6、物理表和字段的访问权限、权限组、权限角色等信息；

7、物理模型和实物资产的关系；

8、文件格式定义；

9、恢复和备份规则；

10、数据集群的吞吐量，QPS，调度任务消耗 CPU，内存大小等信息；

11、数据血缘，表/字段级别的上下游依赖关系；任务输入/输出表依赖关系；

2.3.3.2 业务元数据

1、数据库表的业务域，所在的项目，所在的集群；

2、业务规则、转换规则、计算公式、推导公式等（更多是文档）；

3、数据模型；

4、数据质量规则和核检结果；

5、数据标准；

6、数据的安全，隐私级别；

7、数据使用说明等

2.3.3.3 操作元数据

1、批处理的执行日志；

2、调度异常记录及处理；

3、报表和查询的访问模式，访问频率和执行时间；

4、数据产生；

5、表的访问（查询，关联，聚合等）；

6、字段的访问；

7、物理表的创建时间，创建人，更新时间，更新人

2.3.3.4 管理元数据

1、人员

2、流程

3、职责、岗位

4、组织、部门；

2.3.4 元数据的架构

元数据的架构，一般分为集中式架构和分散式架构。

集中式的架构，指的是采集多种数据源的元数据到元数据自己的存储中来，再集中加工给其他场景提供服务；而分散式的架构，没有自己的元数据存储，而是在使用的时候，去即时的查询其他数据源的元数据。

这两种架构各有利弊。

集中式的架构，可以快速的检索元数据，抽取的时候，也可以自由的转换，自定义补充，提升了元数据的质量；同时也有缺点，需要保证自身存储和其他源数据的一致性，增加了流程复杂度和工作量。

分散式架构的优点是，元数据总能够保持最新，查询更加的简单；缺点也很明显，无法自定义或修改元数据项，查询也受源系统可用性的影响。

一般我们推荐使用集中式架构，定时采集源系统的元数据，通过 hook 方式捕捉各种引擎运行时数据血缘关系，并且定义通用的数据模型提供给第三方接入使用。

最后我们设计了如下的元数据架构：

2.3.4.1 使用 Hook 方式采集作业运行时数据血缘

作业的数据血缘，有三种方式来采集：

静态解析 SQL；
实时抓取正在执行的 SQL，解析执行计划，解析输入表和输出表；
解析任务日志，获取输入表和输出表。

第一种方式，静态解析 SQL，可以使用 Antlr4 仿照 Hive 的 SQL 解析来实现，但是不能保证 SQL 的准确性，因为任务都没有执行。

第二种方式，实时抓取执行的 SQL，这是执行后产生的，可以保证是准确的；

第三种方式，要分析大量的日志，而且时效性很难保证。

所以，第一种方式和第二种方式都是可以的，优先选择第二种方式来做。

当前众多大数据组件都提供了 Hook 钩子的方式，相当于以插件的方式实时的捕捉执行计划。解析之后，推送到 Kafka，再去解析到分布式的图数据库中。

2.3.4.2 通用的数据源模块来对接多种数据源

一般公司肯定是存在多种不同类型的数据源的，比如 Mysql，Oracle，Hive 等，可以制作一个通用的模块，提供统一的接口，来对接这些不同的数据源。

数据源模块则提供三方接口供采集模块定时采集数据源的元数据信息。

核心的技术点，就是要隔离不同数据源的驱动，这些驱动也需要以插件化来集成到数据源模块中。

2.3.4.3 还需要提供个性化的 SDK 接入

如果公司的核心业务部门比较多，公司的数据平台产品比较多，那么势必会产生一些其他的元数据。比如监控平台监控的资源使用情况、任务调度的任务运行情况等。

这种 SDK 接入，需要考虑接入时的安全校验，限流（可定时消费一批Kafka数据来实现）等问题。

2.3.4.4 后端存储的统一模型

元数据类型纷繁杂乱，需要统一整理抽象，再分类存储，并且设计之初，就要尽可能的详尽所有情况，设计出统一的表模型，预留扩展字段。

有一套模型是专门解决元数据模型通用性问题的，叫做 CWM （Common Warehouse Metamodel）标准，翻译过来是公共仓库元模型，这里提供了三层元模型来存储一切不同类型的元数据，当然设计起来比较复杂，一般超大型企业会采用这种模型。

如果可以详尽公司未来的元数据种类，可以分门别类建不同类型的元数据模型表来解决。

参考有赞这样的大公司，元数据可分为：

基础元数据表；
趋势数据表；
任务元数据表；
血缘数据表

2.3.5 元数据应用

最后，我们再罗列一下元数据的比较全的应用场景

可以看到，建立好企业的元数据，便可以为数据治理打下坚实的基础，也可衍生出丰富的应用，如数据地图，血缘分析，数据冷热分析，数据资产管理等。

3 元数据管理系统

3.1 元模型管理

元模型定义了各种元数据的结构以及元数据之间的关系，是元数据管理的基础。因此建设元模型需要考虑元模型需要遵守的规范，元模型建设的范围，元模型对元数据的影响，元模型是否能让用户自定义建设。

建设元模型难点是需要梳理元模型的属性信息以及属性信息在哪里存放，技术元模型需要对相关的数据库、接口等作深入了解，通过深入了解之后，梳理元模型的属性信息及如何查询到这些元模型属性；是业务元模型跟技术元模型调研对象是不一样的，需要跟业务人员沟通属性口径、属性关系，基于沟通内容整理元模型的属性，如果涉及业务元模型出处的业务系统，还需要跟对方业务系统调研，确定采集方式。

由此可见，元模型的范围是非常重要的，如果是刚刚建设元数据系统，推荐先从关系数据库着手，后续随着产品交付、项目的实施在逐步完善其他技术元模型、业务元模型的建设。

一般情况下，建设元模型都会参考CWM（公共仓库元模型）规范，按照CWM规范开展元模型的设计工作。不建议让客户去对元模型进行增删改。因为，技术元模型一般对应的数据库层面，相关数据库底层的元数据是固定的，不会因为调整元数据的元模型而改变数据库的元数据信息，通常需要根据具体的数据库去设计不同的元模型；业务元模型是根据具体业务场景去分析整理相关元模型；管理元模型是根据业务要求抽象的管理属性，需要依托于技术元模型和业务元模型，不能孤立使用。

元模型主要分技术元模型、业务元模型、管理元模型，后续的采集管理、元数据管理、统计与分析等都是基于这个分类开展相关工作。这三大类元模型的技术元模型在数据源系统章节已经讲述，这里不再赘述。业务元数据很多，后续数据标准系统的基础类标准、指标类标准，数据质量系统的检核规则都属于业务元数据，可以参考数据标准、数据质量系统相关章节。管理元模型核心是管理元模型的属性，属性包括管理部门、分类、分级等，这些属性信息用来扩展技术元模型和业务元模型的属性，为了后续对元模型管理做到从字段属性层面的支撑工作。从数据治理源头来说，一般管理部门也会在源头系统进行统一要求，这样当元数据采集后，相关管理属性就存在了，不需要再次归类梳理。

3.2 采集管理

元数据采集管理，简称采集管理，是将目标库、文件、接口中的元数据通过技术的方式自动化或者半自动化获取具体内容。采集管理核心内容是采集引擎、任务调度、采集日志、消息通知。

采集引擎，是元数据采集引擎的简称，作用是对数据源进行元数据采集。由于元模型的多样性和元模型是对采集范围的定义，且元模型需要与采集引擎一一对应，因此采集引擎是包含多种元数据采集引擎的集合。采集引擎是解决自动化或者半自动化获取元数据的诉求。自动化一般是基于分析好的元模型，结合数据源系统提供的目标地址，获取元数据信息；半自动化仪表是基于分析好的元模型，导出需要采集的元模型表头样式，用户通过线下收集的方式整理元数据，最后，将整理好的元数据文件导入到系统中。

任务调度，简单来说就是定时任务，是指基于给定时间点，给定时间间隔或者给定执行次数自动执行任务。通过任务调度可以按照调度排期顺序启动元数据采集工作，解决自动化采集元数据问题。也需要考虑与第三方调度平台对接，将任务调度纳管到客户整体的任务调度系统中。

采集日志是在采集引擎工作的时候，将采集信息收集起来，例如开始结束时间、相关元数据数量等。用户通过采集日志能看到本次任务调度的成功与失败，通过分析采集日志了解到当前采集引擎的性能等。

消息通知是对采集任务结束之后，对采集任务的整理汇总后，通过系统消息通知渠道、短信、邮箱、钉钉、微信等将采集任务结果推送给用户，达到用户实时了解采集任务情况。

消息通知主要有如下几种形式：任务失败成功信息、采集元数据变化情况汇总消息、元数据异动情况分析消息等。

采集管理是元数据管理的入口，元数据采集引擎是采集管理的核心，只有把元数据采集管理梳理清楚，才能更好的为后续的元数据版本、数据地图等提供基础数据。

3.3 元数据管理

元数据管理是对采集到的元数据统一的后台管理端，主要包括三个子功能，分别是完善元数据、元数据版本、环境巡检。

元数据完善

如果只是对元数据简单管理，不涉及数据资产相关管理内容，或者说不对原始元数据添加任何管理元数据，也没有相关元数据发布流程，那么，元数据完善功能可以不做建设。元数据完善主要是对采集过来的元数据进一步的加工，通过元数据完善的操作丰富元数据管理属性和添加相关流程以满足咨询团队编制的《元数据管理办法》中提到的元数据管理流程。

一般情况下，元数据通过采集任务根据调度任务通过增量的方式自动采集，为了确保数据源头与采集内容的一致性，不会对采集的元数据做任何内容的修改，根据客户需求添加相关管理属性，如管理部门、元数据目录、安全等级等。通过元数据发布流程完成元数据从管理态到发布态，让元数据进入下一个展示环节元数据展示中。如果元数据是通过线下Excel梳理，通过文件导入的方式获取元数据，那么除了自动采集的操作之外，还可以根据具体情况对导入的元数据进行优化调整。

在元数据完善过程中，完善的重点是元数据目录、管理部门、安全等级、甚至访问元数据的申请流程，换一个维度思考，这些完善信息就是确定数据所有者、数据管理者、数据生产者、数据使用者、数据使用流程、数据使用是脱敏要求，简单归纳四个字，数据确权，就是确定数据的权利属性，包括确定数据权利主体、确定权利的内容。这些其实就是在确定数据资产的权属问题。数据确权是数据资产化的基础，是数据交易和数据流通的前提，是保护数据安全的重要手段。

数据资产一般是对用数层面，体现数据价值的角度，为什么在完善元数据时，说是在确定数据资产的权属呢？因为，元数据是展示数据资产，或者管理数据资产的承接者。举个例子，假设把数据比喻为液体，元数据比喻为容器，偏离片、蒸馏器、分离器等工具和糖、盐等各种试剂比喻为展示液体的工具，如数据查询、商业智能等。那么，液体需要用各式各样的容器存放，当用户用使用液体时，根据不同需求，对液体进行处理，如蒸馏获取纯洁的液体、添加试剂掩盖液体真实颜色或者味道等。

元数据目录还可以理解为资产目录，资产目录是什么，相关定义请查阅理论知识章节，如果建设，等后续实施章节在详细陈述。这里简单概述数据资产目录到底是什么，解开他神秘的面纱。

先说数据资产一般都包含什么，如果从元数据是数据资产管理的抓手，那么，数据资产包括存储元数据、业务元数据。而这些元数据其实在采集的时候就有相关目录，这些目录组装起来就是资产目录。存储元数据采集后，一般都会以技术口径、管理口径、业务口径挂载到相关目录上，例如，科技部、计划财务部、网络金融部等。业务元数据中的基础类数据标准的主题、层级，质量检核规则中的规则目录，例如唯一性、完整性、一致性等这些都是目录，把他们整理汇总起来，就是数据资产目录。

图 3 依托于存量目录建设数据资产目录（仅供参考）

当然，如果您经济实力夯实，相关业务人员充足，也可以重新基于采集来的各类元数据，按需要重新划分资产目录，如按客户、业务、经营管理等。需要说明的是，数据作为可以快速复制的特性，同一个数据资产最少会在一个资产目录下，也就是说，同一个数据资产可以出现在多个资产目录下。

图 4 重新梳理数据资产目录（仅供参考）

如果仅从管理元数据就是管理数据资产，那么元数据完善功能还可以使用资产盘点、资产确权、资产认责等名称。

元数据版本

元数据版本管理解决相同数据源、相同环境（开发、测试、生产）下，不同时期采集的元数据支持任意对比，并基于版本对比功能，展示元数据各个维度之间的变化情况，如新增、修改、删除。

一般情况下，元数据采集使用增量的方式获取元数据，元数据版本中会包含所有采集的增量内容。只有这样，才能完成元数据版本工作，也就是说，元数据完善功能是最新的元数据，元数据展示中是添加过管理属性或者允许发布的元数据。

环境巡查

环境巡查解决不同环境下元数据是否一致的问题，一般环境巡查主要针对数据库相关的技术元数据，是元数据版本管理的特殊场景下的功能延伸，因为其他类型元数据可以通过元数据版本解决。

做过开发的小伙伴都知道，理论上系统部署在开发环境、测试环境、生产环境都是物理隔绝的。开发小伙伴在开发环境基于产品经理整理的需求开发相关功能，开发完毕后将代码、数据库脚本提供给测试小伙伴，由测试小伙伴基于发布的文件部署到测试环境，测试小伙伴在测试环境测试通过，相关人员准备上线文档（软件程序、配置文件、数据库脚本等）由配置管理员基于文档发布到生产环境中。

在实际过程中，需求的变动、人员的变动、配置管理不标准化，会出现测试环境的库表字段和生产环境的库表字段差异特别大，如何知道两个环境之间库表字段的差异，是非常费力的一件事情。环境巡查就是解决不同环境下元数据不一致的问题。

首先，从某个元数据环境上的采集最新的元数据信息，通过导出的方式获取全量元数据信息（建议导出的元数据信息是加密，只有元数据系统才能解析）。将导出元数据信息在另一个元数据系统环境上的环境巡查中导入，通过与最新采集的元数据进行比对，发现两个环境上元数据的不同，并形成差异分析报告，提供给原业务系统，便于原业务系统整改。

3.4 元数据展示

通过元数据采集任务和元数据完善，元数据的相关属性信息已经相当丰满，这时候的元数据展示主要包括三个方面，按元数据分类的数据方式层级展示元数据（或者叫数据资产展示），基于采集的ETL相关脚本解析后的元数据地图（或者叫数据地图、资产地图等），基于搜索引擎的元数据搜索（或者叫数据资产搜索）。

元数据展示

元数据展示主要基于元数据完善添加数据分类、安全分级、管理属性等信息之后，用户通过数据分类可以层级点开展示元数据，查看元数据详情。

元数据地图

有一种特殊的元数据，从广义上讲属于技术元数据，从在细粒度划分上，归属为计算元数据，基于计算解析引擎处理后，展示数据加工逻辑、数据引用关系，这就是元数据地图。

元数据地图或者叫血缘地图，通常展示库表字段的数据加工链路。让用户知道基于某个字段或者某个表，数据加工的上游是哪个表、哪个字段，数据下游是哪个表、哪个字段。在广义些，指标标准依赖的模型是那些，数据标准贯标的表和字段有哪些，质量规则是对那些表和字段进行检核的，调度任务的先后依赖等等。也就是说，除了常见的库表字段的数据加工血缘链路图，也有业务元数据依赖的库表字段关系，把他们这些关系融为一体，就能形成三维立体的元数据关系地图。

元数据搜索

元数据搜索又称数据地图，是通过全文搜索的方式，让用户找到目标元数据，但用户点击元数据时，除了展示当前元数据的基本信息，还需要展示元数据的关联信息、血缘信息等。假设搜到的是某个数据标准，展示数据标准的基础属性、业务属性、技术属性、管理属性等通用信息，还展示当前数据标准贯标的库表字段，及关联的库表字段数据血缘加工链路，展示这些库表字段引用的数据检核规则、指标标准、标签规则、报表等信息。

如果元数据搜索的结果，能让用户申请资产访问，通过资产访问申请通过之后，可以看到具体当前元数据关联的部分或者全部，脱敏或者未脱敏的数据记录信息，或者说业务数据信息，那么，这时候的元数据搜索或者数据地图，应该成为资产地图，且当前功能不能放到元数据系统中，应该放到数据门户或者数据资产系统中。

3.5 监控管理

元数据监控管理是元数据系统重要的功能，但不一定是必须的功能。

元数据系统其实是对存量的元数据管理工具，从另一个维度说，是对元数据事后管理的工具。当元数据变更时，系统通过采集的方式感知元数据的变化，但系统发现元数据变化时，其实已经对某些数据产生了影响。如某个字段的变化，导致后续数据ETL开发调度的运行报错。在元数据监控管理中，重点是元数据的事前监控和元数据的事后监控。

事后监控

元数据事后监控主要在采集任务的时候，但元数据发生变化时，及时通知相关元数据负责人，通过元数据的血缘分析可以分析出元数据变化的影响，基于采集的数据源管理属性，系统可以给数据影响的相关人员发生短信、邮件、微信等信息。

事前监控

元数据的事前监控是最重要的，这里的元数据事前监控主要针对的数据库层面的，如数据库表、字段、函数、存储过程等变化。如果客户有系统上线管理系统，那么与元数据接口，可以更好的管控元数据事前监控。如果没有相关上线管理系统，只能在上线之前，将相关上线脚本提前预制到系统中，并制定预警时间范围，当系统监控到数据源变化情况时，将变化情况及时采集，并与提前预制的上线脚本进行比对，发现两种异常时，及时告知上线人员及相关管理人员，在最短的时间内容，提醒上线人员异常信息，根据具体情况来更新上传脚本或者数据回滚。

与上线管理系统对接的事前监控重点是打通上线时运行的数据库脚本，通过接口的方式获取脚本信息，同时启动监控系统上线，但系统数据库一旦发生变化时，及时进行预警。

3.6 统计与分析

元数据统计分析通过搜集、汇总、计算统计元数据，利用统计信息对元数据本身的分布、变更趋势，系统、人员等特性进行不同维度的定量定性分析，既可横向对比，也可总结历史、预测未来。总体反映元数据的现状与发展规律，协助企业更进一步的提升元数据管理认知，提高元数据管理水平，辅助企业管理者作出正确决策。

元数据统计解决元数据汇总之后的日变化量、分布情况等。常见的统计维度有时点数、元数据类型、元数据更新状态（新增、删除、修改）、元数据来源，度量值主要是个数、占比等。

元数据分析解决元数据的影响分析、视图关系分析、关联度分析等。影响分析解决某一个元数据变动产生的影响链路，视图关系分析解决视图加工链路，关联度分析是基于血缘关系，将关联度特别高的元数据排名。

元数据稽查是解决元数据质量问题，主要从元数据注释、元数据同名不同义、元数据命名规则等对某个数据源的元数据质量检查。通过元数据稽查功能发现元数据的质量问题。

3.7 接口管理

元数据非常重要，很多系统都与元数据对接，元数据常见的对外接口有：元数据列表、元数据详情、元数据血缘链路、元数据解析引擎等。

4. 与咨询关联

常见的《元数据管理办法》需要元数据系统帮助落地。梳理数据资产相关的库表字段、数据标准、指标标准、报表等都离不开元数据信息。

5. 与实施关联

基于库表字段注释率及同名不同义等情况，需要对原业务系统数据库进行整改。如果建设数据湖、数仓等，元数据是必不可少的输入条件之一，没有元数据，可以说数据字典基本就是空的，根本无法进行模型分析、数据建模等工作。