声明：本文归属一寸HUI所有。@一寸HUI
在上一篇文章数据中台(架构篇)中了解到了数据中台的架构，其中我们一个很重要的部分就是要构建数据资产，而数据资产中的元数据管理又是很重要的部分，接下来我们从几个方面了解元数据：搞懂什么是元数据？元数据和数据的区别是什么？元数据有什么作用？元数据可以用来做什么？
什么是元数据
元数据（metadata），就是描述数据的数据。看到这个估计比较抽象，比较难理解。
举个例子：对于一个数据表，表的含义是什么，由谁管理，每个字段的意思是什么，都属于这个数据表的元数据。一般来说，数据中台不仅需要管理传统的元数据，也需要管理数据应用的元数据。
元数据用来描述数据的数据，通过描述数据的产生、存储、使用情况、业务含义等信息，以及数据管理人员相关信息。让人们能够清楚拥有什么数据、代表什么、源自何处、如何在系统中移动，以及哪些人可以使用源数据，如何使用。
元数据是一种数据。元数据反映了数据的交易、实践、对象和关系。数据反映了真实世界的交易、实践、对象和关系。两者的关系就像数据和真实世界的关系。这一定义从数据和元数据区别与联系表述定义。元数据描述了数据本身（数据库、数据元素、数据模型等）、数据表示的概念（如业务流程、应用程序系统、软件代码、技术架构等）以及数据和概念之间的关系。数据承载的是业务实体数据，而元数据是用于管理实体数据的。
元数据的分类
按照主要用途来划分，元数据可以分成以下几类。
- 业务元数据：与业务相关的数据信息，如数据项的语义、语法限制、与其他数据的关系。这类元数据可以帮助业务人员和应用使用数据，确认数据使用的正确性。
- 技术元数据：主要提供数据或应用的一些运维信息，例如存储空间大小，数仓分层，访问热度，主题分类，关联指标数据量、数据记录数、数据集的物理位置、数据访问记录、数据装载日志、数据计算时间、质量稽核记录等。这类元数据是系统高效运维和审计所必需的信息。
- 管理元数据：用于机构管理的元数据，例如组织架构、人员权限等。这类元数据一般用来控制数据的访问权限及数据用途审计和统计。
- 应用元数据：一般不属于传统元数据管理的范畴，包括数据中台中运行的数据应用的信息，例如应用的开发部门、使用的数据源、产生的数据源、代码的版本、运行的配置等。这类元数据可以用来回答数据如何产生、如何使用、使用多少资源等问题，可以提高数据能力共享和复用的效率。
在数据中台中，业务数据的元数据往往能够让人更加实用。业务元数据包括如下内容：
- 数据定义：一般就是数据库表的DDL，或者说是数据表的Schema。采集数据定义的目的是统一管理数据字段名称、类型、说明，便于全局查询及数据发现。
- 数据字典：一般是业务系统中所涉及概念的定义列表，描述的是数据的结构信息：表结构信息，主要包括像表名，字段名称、类型和注释，表的数 据产出任务，表和字段的权限等。数据字典的建设过程一般涉及业务系统的调研和从业务流程到实际数据映射关系的梳理，是元数据管理和数据中台建设中很关键的一步。
- 数据血缘：数据之间的血缘依赖关系，对于一个指定的数据表、字段、记录、域值，包括上游血缘（它们是如何计算出来的）和下游血缘（它们被用来计算哪些其他的数据表、字段、记录、域值）。数据血缘在数据关系理解、数据验证、运维排错中都有很广泛的应用，一般是元数据管理的必备功能之一，简单理解为一个表是直接通过哪些表加工而来。数据血缘一般会帮我们做影响分析和故障溯源。注意，支持不同级别的血缘带来的额外管理负担是逐渐增加的。目前大部分系统支持到表级血缘。
- 质量控制：数据必须满足的一些质量规则，例如，每个字段必须满足的条件、字段之间的关系、维度表中维度的限制。这些元数据一般属于数据治理流程的一部分，在制定了质量规则之后，数据治理应用可以对指定对象检查这些规则，并在需要的时候报错。
- 统计数据：对于一些重要字段的统计数据，如最大值、最小值、中值、平均值、最常出现值等。有些统计数据的计算很耗资源，一般按需处理。例如，有的字段需要列出最常出现的前10个值，我们可以为每个表提供一些基本的统计数据，然后提供可配置的统计数据计算功能。
- 数仓模型数据：对于数仓模型中的事实表、维度表，标注它们所属的业务域（例如属于销售还是生产）和数仓模型层级（例如属于贴源层还是汇聚层）。标记这些元数据可以让用户更方便地浏览数据资产。
- 聚合语义数据：一般是一些描述性数据，用来描述不同的数据表汇聚时必须满足的条件，例如，用户表和销售表合并的时候应该过滤掉内部测试用户和机器人账号。这种语义元数据难以人工维护，可以采用与源代码结合的方式来展示聚合的方式。
元数据的基础功能和应用
我们可以通过元数据的管理，记录和管理与数据相关的业务数据，便于人们理解数据，保证数据使用的一致性。从不同数据源采集并集成元数据，保证人们理解不同数据的相似性和差异保证元数据的质量、一致性和安全给元数据使用者提供标准的元数据访问方法。
（1）数据地图：数据地图是基于所有元数据搭建起来的数据资产列表，可以将数据地图看作将所有元数据进行可视化呈现的系统。它不仅能够解决有什么数据的问题，还能够进行检索，解决数据在哪里的问题。通过可视化查询、浏览、搜索，能够根据类别、类型等信息展示各个数据实体的信息及其分布情况，展示数据实体间的组合、依赖关系以及数据实体加工处理上下游的逻辑关系，也可以根据数据源库、类型等搜索元数据信息。
（2）数据血缘和影响性分析
数据血缘和影响性分析主要解决“数据之间有什么关系”的问题。因其重要价值，有的厂商会从元数据管理中将其单独提取出来，作为一个独立的重要功能。但是考虑到数据血缘和影响性分析其实是来自于元数据信息，所以还是放在元数据管理中来描述。数据血缘分析是元数据管理的重要应用之一,血缘分析指的是获取到数据的血缘关系，以历史事实的方式记录数据的来源、处理过程、梳理系统、表、视图、存储过程、ETL、程序代码、字段等之间的关系，并采用图数据库进行可视化展现。总之就是通过可视化展示数据是怎么来的，经过了哪些过程、阶段及计算逻辑。
- 影响分析：在一个数据源或数据应用出现问题后，定位该问题的影响范围，并根据管理元数据通知相关部门或人员。
- 指标溯源分析：通过血缘关系，对于一些关键指标，可以查看该指标的计算流程，并回溯到相关的数据源。这个方法在数据治理和数据质量管理中经常用到。
（3）元数据质量：主要做元数据治理用的，包含库、表元数据治理功能，分多个维度统计元数据完成情况，并可以做相应通知等。在做好元数据质量的前提下，可以基于元数据做数据质量管理，在定义好数据质量元数据之后，由系统自动按照数据质量规则检查数据，形成数据质量报告，并在数据质量出现问题时报警。
（4）元数据管理：元数据的管理包含元数据的增删改查、变更管理、对比分析、统计分析等。
- 元数据的增删改查。通过对不同的角色赋予相应的权限，实现元数据在组织范围内的信息共享。值得注意的是，对元数据的修改、删除、新增等操作，必须经过元数据管理员的审核流程。
- 元数据变更管理。对元数据的变更历史进行查询，对变更前后的版本进行比对等。
- 元数据对比分析。对相似的元数据进行比对。比如，对近似的两张表进行对比，发现它们之间的细微差异。
- 元数据统计分析。用于统计各类元数据的数量，如各类数据的种类、数量、数据量等，方便用户掌握元数据的汇总信息。
（5）元数据中心：这是元数据核心功能之一，整个元数据的输出就是数据地图，用户可以通过元数据中心查看表的元数据信息（技术元数据、业务元数据）、任务信息、血缘关系（表级、字段级）血缘分析、使用信息等等（再多就看自己公司诉求了）
（6）元数据服务：统一元数据服务，主要提供查询表、指标、维度基本信息的基础元数据服务以及查询表级血缘、字段级血缘的血缘服务。
（7）安全管理：通过元数据设置表及字段的安全等级，加密，脱敏，授权等，然后结合相应的规则对数据表及字段访问进行控制，确保数据安全。
（8）数据冷热度分析：冷热度分析主要是对数据表的被使用情况进行统计，如表与ETL程序、表与分析应用、表与其他表的关系情况等，从访问频次和业务需求角度出发，进行数据冷热度分析，用图表展现表的重要性指数。
元数据管理架构
元数据管理架构功能：支持多业务线，支持多租户，支持多种数据源，有数据血缘功能，数据标签功能，与数据中台集成等。
元数据中心统一对外提供了 API 访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过API 接口获取元数据。另外 Ranger 可以基于元数据中心提供的 API 接口，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制。
1.元数据采集和存储
在数据处理的每一步中，我们必须获取相应的元数据，并将这些元数据集中存储在关系型数据库中，便于后续查询和管理。元数据是理解和使用数据的根据，它的完整性和正确性是整个大数据分析系统的基本条件。元数据采集必须能够适应异构环境，支持从传统关系型数据库和大数据平台中采集数据产生系统、数据加工处理系统和数据应用报表系统的全量元数据，包括过程中的数据实体（系统、库、表、字段的描述）以及数据实体加工处理过程中的逻辑。同时，元数据管理系统必须支持人工输入，允许人工的增、删、改、查及发布。
2.数据血缘
通过Spark/Hive/Flink本身提供的Listener/Hook机制，解析调度依赖中的FROM、CREATE、INSERT等语句，获取输入节点与输出节点，生成血缘关系，就可以解析除SQL之外的其他语法。
在明确了实现方式后，就要考虑计划执行时机了。执行时机主要有3个。
- （1）在运行前通过解析静态的SQL，获取依赖的输入节点与输出节点。
- （2）在运行中实时截取动态的SQL，获取依赖的输入节点与输出节点。
- （3）在运行后通过解析任务日志，获取依赖的输入节点与输出节点。
在这3个时机中，时机（1）因为没有执行代码，所以无法保证可以正常运行，时机（3）则比较后置，没有时效性，所以最合适的是时机（2），在运行中解析SQL，能够实时获取输入与输出表，并且当依赖关系改变时也能实时变更。但是时机（2）也有一个缺点，那就是当数据表开发完成但还没有被执行时，就无法获取血缘关系，这时就需要通过解析静态SQL的方式，建立跟其他表的依赖关系。
Apache Atlas就是采用（2）方式实现，其架构图如下：
对于 Hive 计算引擎，Atlas 通过 Hook 方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka，由一个 Ingest 模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式，基于图查询引擎，获取血缘关系。对于 Spark，Atlas 提供了 Listener 的实现方式。
对于数据血缘的实现，可以简要概述为：首先，通过Spark Listener/HiveHook/Flink Hook，解析调度依赖中的FROM、CREATE、INSERT等语句获取输入节点与输出节点，生成血缘关系并推送给消息中间件（Kafka）；其次，消费端负责将血缘关系沉淀到图形数据库（Neo4j）中；最后，通过图计算引擎在前端以图形的方式将其展示出来。
3.数据字典
在实际的场景中，公司普遍存在大量多源异构的数据，其数据源包括Hive、MySQL、Oracle、Greenplum等。支持不同数据源，建立一个可扩展的、统一的元数据层非常重要的，否则公司的元数据是缺失的。所以构建数据字典是很重要的，开源的Metacat 擅长管理数据字典，可以参考Metacat的架构构建公司的数据字典。
Metacat最大的优势：多数据源的可扩展架构:
从上面Metacat的架构图中，可以看到：Metacat的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉取的方式。一方面，它不存在保存两份元数据一致性的问题；另一方面，这种架构设计很轻量化，每个数据源只要实现一个连接实现类即可，扩展成本很低。
4.数据地图
数据地图是基于所有元数据搭建起来的数据资产列表，可以将数据地图看作将所有元数据进行可视化呈现的系统。数据地图是基于元数据中心构建的一站式企业数据资产目录，可以看作是元数据中心的界面。数据开发、分析师、数据运营、算法工程师可以在数据地图上完成数据的检索，解决了“不知道有哪些数据？”“到哪里找数据？”“如何准确的理解数据”的难题。
数据地图最核心的功能有两个：元数据信息的展示、血缘关系。
数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，因此在结果排序时，我们增加了数仓维护的表优先展示的规则。数据地图还提供了按照主题域、业务过程导览功能，可以帮助使用者快速了解当前有哪些表可以使用。
参考：
元数据管理系统
数据中台学习笔记-元数据管理，指标管理，数据模型
聊聊数据中台：元数据建设有哪些坑（一）
《云原生数据中台：架构、方法论与实践》
《数据中台：让数据用起来》