【数据治理工具】–元数据系统

1.元数据系统

1.1 概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 元数据

必须搞懂元数据相关的9个术语和名词

元数据最简单的定义是描述数据的数据。这里有两个关键点，一个是数据，一个是描述数据。企业中一般的可进行管理的数据如下表：

按照不同应用领域或功能，元数据一般大致可分为三类：业务元数据、技术元数据和操作元数据。

1.2.1 业务元数据

业务元数据描述数据的业务含义、业务规则等。明确业务元数据可以让人们更容易理解和使用业务元数据。元数据消除了数据二义性，让人们对数据有一致的认知，避免“自说自话”，进而为数据分析和应用提供支撑。

常见的业务元数据有：

业务定义、业务术语解释等；
业务指标名称、计算口径、衍生指标等；
业务引擎的规则、数据质量检测规则、数据挖掘算法等；
数据的安全或敏感级别等。

1.2.2 技术元数据

技术元数据是结构化处理后的数据，方便计算机或数据库对数据进行识别、存储、传输和交换。技术元数据可以服务于开发人员，让开发人员更加明确数据的存储、结构，从而为应用开发和系统集成奠定基础。技术元数据也可服务于业务人员，通过元数据厘清数据关系，让业务人员更快速地找到想要的数据，进而对数据的来源和去向进行分析，支持数据血缘追溯和影响分析。

常见的技术元数据有：

物理数据库表名称、列名称、字段长度、字段类型、约束信息、数据依赖关系等；
数据存储类型、位置、数据存储文件格式或数据压缩类型等；
字段级血缘关系、SQL脚本信息、ETL信息、接口程序等；
调度依赖关系、进度和数据更新频率等。

1.2.3 操作元数据

操作元数据描述数据的操作属性，包括管理部门、管理责任人等。明确管理属性有利于将数据管理责任落实到部门和个人，是数据安全管理的基础。

常见的操作元数据有：

数据所有者、使用者等；
数据的访问方式、访问时间、访问限制等；
数据访问权限、组和角色等；
数据处理作业的结果、系统执行日志等；
数据备份、归档人、归档时间等。

元数据的分类及实例见表2。

表2 元数据的分类（以“客户”信息为例）

我们再来举个通俗的例子，一本书的封面和目录向我们展示了这样的元数据信息：图书名称、作者姓名、出版商和版权细节、图书的提纲、标题、页码等。

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

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

1.3 元模型

和元数据管理相关的另一个重要概念是元模型，定义元数据的属性、关系的模型叫做元模型，每类元数据都属于一个元模型。

比如，表模型里定义了表的属性有“注释”、“是否系统表”、“是否临时表”、“所有者”等（图1）；定义了表由索引、外键、表分区、字段等组成（图2）；定义了表受表输出组件、存储过程、表等的影响（图3）。

图1

图2

图3

1.3.1 元模型作用

有了元模型，就能根据元模型来采集元数据信息。要实现企业元数据管理，需要定义一个符合存储企业数据现状的元数据模型，且这个模型有不同粒度和层次的元模型，有了层次和粒度的划分，未来元数据进行批量管理后就可以灵活的从不同维度进行元数据分析，如企业的数据地图、数据血统都是基于此实现的。

我们试着把企业中的技术元数据、业务元数据、操作元数据、管理元数据进行元模型的梳理，如下图所示：

将以上梳理出的信息通过UML建模处理就得到了元模型，在元模型中有包、类、属性、继承、关系。创建元模型的时候也可以参考CWM（公共仓库元模型），CWM定义了一套完整的元模型体系结构，用于数据仓库构建和应用的元数据建模。

1.4 数据血缘

一般可以通过3种方式

通过静态解析SQL，获得输入表和输出表
通过实时抓取正在执行的SQL，解析执行计划，获取输入表和输出表
通过任务日志解析的方式，获取执行后的SQL输入表和输出表
第一种方式，面临准确性的问题，因为任务没有执行，这个 SQL 对不对都是一个问题。
第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。
所以第二种方式，我认为是比较理想的实现方式，而 Atlas 就是这种实现。

2.建设意义与作用

2.1 建设意义

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

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

2.2 主要作用

在数据治理中，元数据是对数据的描述，存储着数据的描述信息。我们可以通过元数据管理和检索我们想要的“书”。可见元数据是用来描述数据的数据，让数据更容易理解、查找、管理和使用。

元数据是建设数据仓库的基础，是构建企业数据资源全景视图的基础，清晰的血缘分析、影响分析、差异分析、关联分析、指标一致性分析等是数据资产管理的重要一环。

如果说数据是物料，那么元数据就是仓库里的物料卡片；如果说数据是文件夹，那么元数据就是夹子的标签；如果说数据是书，那么元数据就是图书馆中的图书卡。

元数据的主要作用是对数据对象进行描述、定位、检索、管理、评估和交互。

**描述：**对数据对象的内容、属性的描述，这是元数据的基本功能，是各组织、各部门之间达成共识的基础。
**定位：**有关数据资源位置方面的信息描述，如数据存储位置、URL等记录，可以帮助用户快速找到数据资源，有利于信息的发现和检索。
**检索：**在描述数据的过程中，将信息对象中的重要信息抽出标引并加以组织，建立它们之间的关系，为用户提供多层次、多途径的检索体系，帮助用户找到想要的信息。
**管理：**对数据对象的版本、管理和使用权限的描述，方面信息对象管理和使用。
**评估：**由于有元数据描述，用户在不浏览具体数据对象的情况下也能对数据对象有个直观的认识，方便用户的使用。
**交互：**元数据对数据结构、数据关系的描述方便了数据对象在不同部门、不同系统之间进行流通和流转，并确保流转过程中数据标准的一致性。

元数据以数字化方式描述企业的数据、流程和应用程序，为企业数字资产的内容提供了上下文，使得数据更容易理解、查找、管理和使用。准确的元数据是必不可少的，也是迅速、有效地对数据去粗取精的关键。没有元数据，数据就毫无意义，只不过是一堆数字或文字而已。因此，对于元数据的有效管理是企业数据治理的基础。

2.3 应用价值

良好的元数据架构，能够给元数据带来更多的应用价值。我们再看看元数据的应用价值。

围绕核心业务：通常在项目初期的时候，只围绕一些核心业务主体，使其在使用的时候灵活高效，后续在持续扩展其他能力。
数据成本分析：基于元数据中链路，分析各个节点数据的生产维护管理等成本，为数据服务中商业定价提供参考，可能直接影响服务是否可提供的决策。
配置可视化：在数据服务平台中，最忌讳的一点就是靠手动去维护各种作业，不管在什么场景下，都要考虑可配置化管理，保证动作可追溯。
流程自动化：不管是元数据结构映射，还是配置后数据的抽取，要保证指令生成后可以自动完成该一系列动作，并完成流程监控分析。
资产化分析：通常会把元数据视为数据资产体系，因此围绕元数据去统计数据的使用情况，产生的价值，以及热点数据识别和分布，业务主体关联度等，并输出相应分析结果。

通过元数据管理我们能够做到：

1、实现多样、繁杂的元数据信息集中管理，为企业数据(服务)管理提供统一的视图，实现企业级数据(服务)资产管理，方便数据(服务)交互共享，同时为后续规划提供依据;

2、通过管理维护数据(服务)之间关系，实现数据(服务)自动关联分析，为问题定位、影响分析、上线加速等提供支撑。

3、建立数据(服务)标准，统一交换、存储、应用口径，减少共享壁垒，降低应用出错几率，提升质量。

通过这些基本能力，元数据在数据管理、微服务管理、业务管理等方面都能发挥很大的作用。

通过元数据管理，在数据方面能做到：

1、数据标准化

2、数据开放

3、数据质量提升等

在微服务方面，能够提供以下支撑：

1、服务开发、应用等标准化;

2、服务应用监控，优化服务应用等

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

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

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

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

元数据在数据仓库中的应用如下：

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

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

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

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

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

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

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

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

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

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

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

2.4 视角分析

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

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

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

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

2.6 元数据应用

元数据的比较全的应用场景

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

3. 建设内容

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

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

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

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

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

3.1 元模型管理

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

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

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

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

元模型主要分技术元模型、业务元模型、管理元模型，后续的采集管理、元数据管理、统计与分析等都是基于这个分类开展相关工作。这三大类元模型的技术元模型在数据源系统章节已经讲述，这里不再赘述。业务元数据很多，后续数据标准系统的基础类标准、指标类标准，数据质量系统的检核规则都属于业务元数据，可以参考数据标准、数据质量系统相关章节。

管理元模型核心是管理元模型的属性，属性包括管理部门、分类、分级等，这些属性信息用来扩展技术元模型和业务元模型的属性，为了后续对元模型管理做到从字段属性层面的支撑工作。从数据治理源头来说，一般管理部门也会在源头系统进行统一要求，这样当元数据采集后，相关管理属性就存在了，不需要再次归类梳理。

3.2 采集管理

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

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

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

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

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

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

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

3.3 元数据管理

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

元数据管理是指与确保正确创建、存储和控制元数据，以便在整个企业中一致地定义数据有关的活动。

元数据管理是对涉及的业务元数据、技术元数据、操作元数据进行盘点、集成和管理。采用科学有效的机制对元数据进行管理，并面向开发人员、业务用户提供元数据服务，可以满足用户的业务需求，为企业业务系统和数据分析的开发、维护等过程提供支持。

可以从技术、业务和应用三个角度理解元数据管理。

**技术角度：**元数据管理着企业的数据源系统、数据平台、数据仓库、数据模型、数据库、表、字段以及字段间的数据关系等技术元数据。

**业务角度：**元数据管理着企业的业务术语表、业务规则、质量规则、安全策略以及表的加工策略、表的生命周期信息等业务元数据。

**应用角度：**元数据管理为数据提供了完整的加工处理全链路跟踪，方便数据的溯源和审计，这对于数据的合规使用越来越重要。通过数据血缘分析，追溯发生数据质量问题和其他错误的根本原因，并对更改后的元数据进行影响分析。

企业元数据管理的主要活动包括：

创建并记录主题领域的实体和属性的数据定义；
识别数据对象之间的业务规则和关系；
证明数据内容的准确性、完整性和及时性；
建立和记录内容的上下文（数据血缘、数据影响的全链路跟踪分析）；
为多样化的数据用户提供一系列上下文理解，包括用于合规性、内部控制和更好决策的可信数据；
为技术人员提供元数据信息，支持数据库或应用的开发。

3.3.1 元数据完善

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

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

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

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

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

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

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

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

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

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

3.3.2 元数据版本

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

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

3.3.3 环境巡查

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

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

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

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

3.3.4 元数据管理的目标

企业元数据管理的本质是有效利用企业数据资产，让数据发挥出尽可能大的价值。元数据管理可以帮助业务分析师、系统架构师、数据仓库工程师和软件开发工程师等相关干系人清楚地知道企业拥有什么数据，它们存储在哪里，如何抽取、清理、维护这些数据并指导用户使用。

以下元数据管理目标是企业的普遍诉求。

3.3.4.1 建立指标解释体系

满足用户对业务和数据理解的需求，建立标准的企业内部知识传承的信息承载平台，建立业务分析知识库，实现知识共享。能够回答以下问题：

企业有哪些数据？
什么是企业有效客户？有效客户和客户有何区别？
什么是产品的生命周期？
这个数据还叫什么名字？
数据仓库中的存储过程是谁写的？它用来干什么？现在还在用吗？

典型应用有数据资源目录和业务术语表。

3.3.4.2 提高数据溯源能力

让用户能够清晰地了解数据仓库中数据流的来龙去脉、业务处理规则、转换情况等，提高数据的溯源能力，支持数据仓库的成长需求，降低因员工换岗造成的影响。元数据有助于回答以下问题：

这张表是从哪个业务系统中抽取过来的？
ETL过程是否对数据进行过加工处理？进行了哪些处理？
指标数据是从哪些表汇总计算出来的？

典型应用有血缘分析、影响分析、全链路分析。

3.3.4.3 数据质量稽核体系

通过非冗余、非重复的元数据信息提高数据完整性、准确性。元数据管理解决的问题是如何将业务系统中的数据分门别类地进行管理，建立报警、监控机制，出现故障时能及时发现问题，为数据仓库的数据质量监控提供基础素材。能够回答以下问题：

今天的在线用户数为什么是0？
为什么A报表中的本月收入值与B报表中的不同？

典型应用有指标标准和数据质量规则。

3.4 元数据展示

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

3.4.1 元数据展示

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

3.4.2 元数据地图

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

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

按数据域对企业数据资源进行全面盘点和分类，并根据元数据字典自动生成企业数据资产的全景地图。该地图可以告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。

数据资产地图支持以拓扑图的形式可视化展示各类元数据和数据处理过程，通过不同层次的图形展现粒度控制，满足业务上不同应用场景的图形查询和辅助分析需要：

在这里插入图片描述

3.4.3 元数据搜索

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

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

3.4.4 血缘关系

从上层业务侧追溯到底层结构，形成血缘关系的概念，概念本身并不重要的，背后的核心是链路的管理，链路上的节点（中间实体）是通过多种计算手段生成；

如果某个节点数据一旦出现质量问题，则需要根据这里的链路关系进行逐级向底层排查，完成问题修复后，还需要根据关系向上逐级修复清洗；如此通过血缘关系进行数据质量的分析和把控。

3.5 监控管理

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

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

3.5.1 事后监控

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

3.5.2 事前监控

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

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

3.6 统计与分析

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

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

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

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

3.7 接口管理

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

4 元数据系统设计

数据管理之元数据管理

4.1 架构设计

元数据管理的应用通常一款元数据管理工具应具备元模型设计、元数据采集、元数据分析、数据地图展现等核心功能。元数据包括:元模型、元数据采集、元数据注册、元数据应用、元数据服务等;

架构图2：

元数据系统整体分为接入层、存储层、功能层和应用层。

接入层：适配不同元数据生产方，转换成标准定义，输出全种类实体、关系变更消息。
存储层：基于元模型的实体、关系的存储与查询，支持统计与分析能力。
功能层：提供元模型管理、元数据分析应用、元数据管理、元数据检核等功能。
应用层：基于定板元数据提供单点、复杂查询服务，基于分析引擎提供面向不同角色的元数据分析服务。

作为企业数据治理的基础，元数据管理平台从功能上主要包括：元数据采集服务，元数据访问服务、元数据管理服务和元数据分析服务。

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

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

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

这两种架构各有利弊。

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

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

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

元数据架构：

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

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

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

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

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

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

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

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

（2）通用的数据源模块来对接多种数据源

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

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

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

（3）还需要提供个性化的 SDK 接入

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

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

（4）后端存储的统一模型

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

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

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

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

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

4.2 元数据采集服务

能够适应异构环境，支持从传统关系型数据库和大数据平台中采集从数据产生系统到数据加工处理系统到数据应用报表系统的全量元数据，包括过程中的数据实体（系统、库、表、字段的描述）以及数据实体加工处理过程中的逻辑；数据管理平台内置多种采集适配器，支持多种存储格式的元数据自动获取，如：数据库、报表工具、ETL工具、文件系统等，同时无法完成自动获取的元数据，提供了可自定义的元数据采集模版完成元数据的批量导入。

4.3 元数据管理服务

实现元数据的模型定义并存储，在功能层包装成各类元数据功能，最终对外提供应用及展现；提供元数据分类和建模、血缘关系和影响分析，方便数据的跟踪和回溯。

数据管理平台提供各类元数据管理，包括：业务元数据、技术元数据和管理元数据，支持元数据的基本信息、属性、依赖关系、组合关系的增删改查操作。

最新元数据和定版元数据隔离，在最新元数据中的改动不影响定版元数据的正常使用，同时每次发布都有版本留痕，支持各版本的对比分析。

4.4 元数据分析服务

元数据的应用一般包括数据地图，数据的血缘、影响分析，全链分析等；元数据管理平台提供了丰富的元数据分析功能，包括血缘分析、影响分析、全链分析、关联度分析、属性值差异分析等，分析出元数据的来龙去脉，快速识别元数据的价值，掌握元数据变更可能造成的影响，以便更有效的评估变化带来的风险，从而帮助用户高效准确的对数据资产进行清理、维护与使用。

血缘分析：告诉你数据来自哪里，都经过了哪些加工。

影响分析：告诉你数据都去了哪里，经过了哪些加工。

冷热度分析：告诉你哪些数据是企业常用数据，哪些数据属于僵死数据。

关联度分析：告诉你数据和其他数据的关系以及它们的关系是怎样建立的。

数据资产地图：告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。

附录A：建设范例

A.1 网易元数据管理方案

你真的了解数仓元数据吗，数据地图你又知道多少？

网易的元数据中心的界面（数据地图）是基于元数据中心构建的一站式企业数据资产目录，可以看作是元数据中心的界面。数据开发、分析师、数据运营、算法工程师可以在数据地图上完成数据的检索，解决了“不知道有哪些数据？”“到哪里找数据？”“如何准确的理解数据”的难题。

数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，在结果排序的时候，增加了数仓维护的表优先展示的规则。同时数据地图还提供了按照主题域、业务过程导览，可以帮助使用者快速了解当前有哪些表可以使用。

当使用者定位到某一个表打开时，会进入详情页，详情页中会展示表的基础信息，字段信息、分区信息、产出信息以及数据血缘。数据血缘可以帮助使用者了解这个表的来源和去向，这个表可能影响的下游应用和报表，这个表的数据来源。

数据地图同时还提供了数据预览的功能，考虑到安全性因素，只允许预览 10 条数据，用于判断数据是否符合使用者的预期。数据地图提供的收藏功能，方便使用者快速找到自己经常使用的表。当数据开发、分析师、数据运营找到自己需要的表时，在数据地图上可以直接发起申请对该表的权限申请。数据地图对于提高数据发现的效率，实现非技术人员自助取数有重要作用。经过我的实践，数据地图是数据中台中使用频率最高的一个工具产品，在网易，每天都有 500 以上人在使用数据地图查找数据。

A.2 美团团队元数据管理方案

美团数据地图作为元数据应用的一个产品，聚焦于数据使用者的“找数”场景，实现检索数据和理解数据的“找数”诉求。我们通过对离线数据集和在线数据集的元数据刻画，满足了用户找数和理解数的诉求，通过血缘图谱，完成物理表到产品的血缘建设，消除用户人肉评估的痛苦。

1.离线场景下的元数据中心

关键字检索和向导查询共同解决了“找数据”的问题：大部分的检索数据场景下，数据使用者都可以通过关键字检索来得到匹配结果。剩下的一小部分场景，例如，对于新人入职后如何了解整个数仓和指标的体系（数仓分几层，每层解决什么问题，都孵化出什么模型；整个指标、维度体系都是怎么分类，有哪些指标和维度），这部分场景可以使用向导查询功能。向导查询相当于分类查询，将表和指标按照业务过程进行分类，用户可以按照分类逐步找到想要的表或指标。

打通了业务元数据和技术元数据之间的关系，提高了“找数据”的能力：通过“Wherehows”查找到指标后，不仅不可查看指标的业务定义，还能查看指标的技术实现逻辑，指标在哪些维度或维度组合中已经实现，并且能够在哪张表里找到这些维度，或维度组合的指标数据。反之，也可以知道在某个维度下已经实现了哪些指标，对应的指标在哪些表里。这些功能能让用户更加方便地找到想要的数据。

提供了较为完善的数据信息，帮助用户更好理解数据：对于表的信息，“Wherehows”除了提供表和字段的中英文名称、描述信息等基础信息外，为了帮助用户更好地理解表的建设思路，我们还提供了表的星型模型（可以关联的一致性维度及对应的维度表）、表的血缘关系等信息。

2.业务数据场景下的元数据中心

业务数据场景主要想解决的一个问题是，如何知道一个业务表（MySQL表）有没有同步到数仓。如果没有同步，能够找谁进行同步。因为已经打通“业务表 -> 数仓表 -> 产品”三者之间的血缘关系，我们能够轻松解决业务数据场景的问题。

3.生产评估场景下的元数据中心

在日常数据生产工作中，我们经常需要对表进行影响评估、故障排查、链路分析等工作，这些工作如果靠纯人工去做，费时费力。但现在我们已经打通了“业务表/字段 -> 数仓表/字段 -> 产品”三者之间的血缘关系，就能够在10分钟内完成评估工作。对于不同的场景，血缘链路提供了两个便捷的功能：过滤和剪枝。例如，某个表逻辑需要修改，需要看影响哪些下游表或产品？应该要通知哪些RD和PM？这种情况下，血缘工具直观地显示影响了哪些负责人和产品，以及这个表的下游链路。

有些表的链路很长，整个血缘关系图很大，这样会导致用户定位信息或问题。所以血缘工具提供了剪枝的功能，对于没用的、不想看到的分支可以剪掉，从而让整个链路变得更加直观。

4. 元数据功能

ETL自动化管理：使用元数据信息自动生成物理模型，ETL程序脚本，任务依赖关系和调度程序。
数据质量管理：使用数据质量规则元数据进行数据质量测量。数据质量根据设定的规则帮助您过滤出有问题的数据，并智能分析数据质量缺陷。
数据安全管理：安全性会更进一步，可以限制特定的组成员只可以访问表中特定的数据。
数据标准管理：使用元数据信息生成标准的维度模型。
数据接口管理：使用元数据信息进行接口统一管理。多种数据源接入，并提供多种插件对接最流行的源系统。应该可以简单方便获取数据。
项目文档管理：使用元数据可以自动、方便的生成的健壮全面的项目文档，其以帮助您应对各种对于数据合规性要求。读取元数据模型，并生成pdf格式的描述文件。生成文档您查看每个对象的名称、设置、描述和代码。
数据语义管理：业务用户在自助服务分析中面临的挑战他们不了解数据仓库从而无法正确解释数据，使用元数据可以语义层建模，使用易于业务用户理解的描述来转换数据。

A.3 元数据管理系统设计

元数据管理系统设计

在这里插入图片描述

1. 数据表管理模块

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

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

2. 模型管理模块

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

2.1 数据表模型管理

需要维护如下信息：

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

关联配置

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

模型详情

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

2.2 SQL模型

在这里插入图片描述

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

模型详情

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

3. 维度管理模块

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

4. 指标管理模块

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

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

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

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

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

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

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

模型信息

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

基础指标信息

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

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

基础模型信息

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

5. 应用管理

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

5.1 数据应用模块

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

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

需要信息：

应用名称
查询引擎

统计指标列表

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

分析维度列表

where条件

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

备注

需要功能：

生成SQL
执行查询

5.2 外部应用模块

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

具体的实现上模块

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

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

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

模块名称
URL
moduleKey等信息。

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

5.3 数据地图

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

A.4 元数据治理产品案例实践

元数据治理：产品方案介绍及案例实践

1. 案例场景描述

目标：通过一个简化的案例，介绍元数据基本的治理流程，该案例将介绍业务库存量表的元数据治理流程。

场景：某业务系统的MySQL库中存储了一张「客户信息表」，该表在实际业务中使用比较频繁，但是由于元数据缺失导致经常面临各种数据答疑、数据使用不规范等问题。故计划将该表采集到平台上进行治理，治理内容主要是完善表的业务信息、技术信息、管理信息等，以便将治理后的数据表呈现给用户，方便用户快速理解和使用表。