今天和大家聊一聊元数据。为什么这里要讲元数据呢？我来举个例子，你就知道元数据的重要性了。

小明刚入职公司，对公司业务和研发不是太了解，现在要新研发一个指标，通过梳理发现需求需要用到订单表，那小明怎么才能找到订单表呢？另外订单量的加工逻辑是订单表的订单状态为已下单状态的数量，那又应该怎么确定订单状态是哪个字段呢？在研发过程中小明发现，订单表加工出来的订单金额错误，那怎么才能知道加工表的任务是哪个？负责人是谁呢？负责研发人员被告知问题后，如何能够快速排查上游依赖任务，加工逻辑排查问题呢？

上面的问题，通过元数据都可以很好的解答，比如表及字段信息会有专门的技术元数据存储，加工逻辑有对应的业务元数据存储，针对任务报错或加工逻辑错误，可以依赖数据血缘帮我们做影响分析和故障溯源，从而尽快排查问题。

什么是元数据呢？元数据又包括那些呢？

元数据（Meta Data）狭义的来说可以理解为描述数据的数据，广义的来看是除了业务逻辑直接读写处理外的业务数据，所有用来维持整个数仓系统运转所需的信息及数据都可以叫作元数据。

元数据定义理解

如何理解上面这句话呢？我告诉你小头儿子的信息，如果你没见过动画片你肯定是不能理解的，但是如果按照下面的文字进行描述呢？

小头儿子是一个高150cm的男孩子，重100斤，出生在2008年，现在13岁，爸爸的名字是小头爸爸，现在在上中学。

上文在描述小头儿子，那么是怎样描述的？从身高，体重，性别，家庭关系，年龄等。这些描述的信息可以理解为元数据。

同理，现在我告诉你一个数字175，看到这个你除了可以确定他具备一定的度量意义外，还是有很多疑问，无法立即，比如度量的什么，谁度量的等等问题，但是如果按照下面这些信息度量呢？

数据类型 数据内容
数据值 175
单位 cm
指标 平均身高
统计时间 2020年
区域范围 全国
人群范围 成年男性
范围 80-260
数据库类型 Mysql
数据库链接 jdbc:mysql://127.0.0.1:3306/info
表名 human_stat
字段 height_avg
创建人 李四
创建时间 2020-10-01
修改时间 2020-10-01
数据权限 公开
安全等级 安全
质量等级 极高

这样是不是就很清楚了？175 的意思是：2020 年统计的全国成年男性平均身高，该值的合理范围是 80-260cm，数据目前存在 MySQL中，访问连接是 jdbc:mysql://127.0.0.1:3306/info，由国家统计局的李四在 2020 年 10 月 1 日创建，数据目前是公开的，很安全，质量经过多重确认无误的。

上表在描述 175 这个数据，用了哪些描述项呢？单位、指标、统计时间、统计范围、合理范围、数据库、表、字段、创建人、创建时间、数据权限、质量等级等等。这些都是在描述 175 这个数据。我们把描述 175 这个数据的其他数据称之为“元数据”。

元数据类型又包括那些呢？

个人这块的话，我将元数据分为技术元数据（Technical Metadata)和业务元数据（Business Metadata）。

技术元数据是什么？

技术元数据是为开发和管理数据仓库的IT人员使用，包括etl工程师，大数据研发工程师等，它描述了与数据仓库开发、管理和维护相关的数据。针对类型上可以再次进行细分，可以细分为字典技术元数据、任务技术元数据、数据质量和运维技术元数据。

字典元数据：

如表、字段、分区等信息。记录了表及字段的中英文名、备注、字段类型、及表状态、分区信息、责任人信息、对应主题，文件大小、表类型、生命周期、保密级别、权限信息等。

任务元数据

如大数据平台上所有作业运行等信息：类似于 Hive Job 日志，包括作业类型、实例名称、输入输出、 SQL 、运行参数、执行时间，执行引擎等。

数据开发平台中数据同步、计算任务、任务调度等信息: 包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息 任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。

数据质量和运维相关元数据

如任务监控、运维报警、数据质量、故障等信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。

数仓业务元数据是什么？

业务元数据是为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性、指标口径等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。

常见的业务元数据有维度及属性(包括维度编码，字段类型，创建人，创建时间，状态等)、业务过程、指标(包含指标名称,指标编码，业务口径，指标类型，责任人，创建时间，状态，sql等)，安全等级，计算逻辑等的规范化定义，用于更好地管理和使用数据。数据应用元数据，如数据报表、数据产品等的配置和运行元数据。

数仓元数据类型举例讲解

针对元数据的类型上更容易理解，对上述例子中的元数据类型，进行归类划分：

业务元数据

数据类型 数据内容
数据值 175
单位 cm
指标 平均身高
统计时间 2020年
区域范围 全国
人群范围 成年男性
范围 80-260

技术元数据

数据类型 数据内容
数据库类型 Mysql
数据库链接 jdbc:mysql://127.0.0.1:3306/info
表名 human_stat
字段 height_avg
创建人 李四
创建时间 2020-10-01
修改时间 2020-10-01
数据权限 公开
安全等级 安全
质量等级 极高

如何管理元数据?

通过上面的介绍和案例，你了解了元数据了吗？ 那元数据的种类那么多，怎么管理这些元数据呢？一般是构建一个元数据中心。

业界元数据中心产品有哪些呢？

目前业绩对元数据中心产品，我总结为开源产品、商业化产品、自研这三种。

业界的比较有影响力的产品：
开源的有 Netflix 的 Metacat、Apache Atlas；
商业化的产品有 Cloudera Navigator、阿里云的maxcomputer、网易有数相关产品
自研：网易内部元数据、美团内部元数据产品、惟客数据（作者公司）等

开源产品

针对开源解决方案这里介绍下Metacat 和 Atlas 这两款产品，一个擅长于管理数据字典，一个擅长于管理数据血缘，下面简要介绍下这两款产品，希望你更能深入的理解元数据中心应该如何设计。

Metacat 多数据源集成型架构设计（借鉴郭忆大佬《数据中台实战课》）

关于Metacat，你可以在 GitHub 上找到相关介绍，所以关于这个项目的背景和功能特性，我就不再多讲，我只想强调一个点，就是它多数据源的可扩展架构设计，因为这个点对于数据字典的管理，真的太重要！

Metacat架构

在一般的公司中，数据源类型非常多是很常见的现象，包括 Hive、MySQL、Oracle、Greenplum 等等。支持不同数据源，建立一个可扩展的、统一的元数据层是非常重要的，否则你的元数据是缺失的。

从上面 Metacat 的架构图中，你可以看到，Metacat 的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉的方式，一方面它不存在保存两份元数据一致性的问题，另一方面，这种架构设计很轻量化，每个数据源只要实现一个连接实现类即可，扩展成本很低，我把这种设计叫做集成型设计。我认为这种设计方式对于希望构建元数据中心的企业，是非常有借鉴意义的。

Apache Atlas 实时数据血缘采集（借鉴郭忆大佬《数据中台实战课》）

同样，关于Apache Atlas的背景和功能，我也不多说，只是想强调 Atlas 实时数据血缘采集的架构设计，因为它为解决血缘采集的准确性和时效性难题提供了很多的解决思路。

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

Atlas架构

对于 Hive 计算引擎，Atlas 通过 Hook 方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给 Kafka，由一个 Ingest 模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式，基于图查询引擎，获取血缘关系。对于 Spark，Atlas 提供了 Listener 的实现方式，此外 Sqoop、Flink 也有对应的实现方式。

自研的产品方案

目前作者调研了几个公司的平台的方案，针对元数据的管理上，都是构建统一的元数据管理中心，直观的产品话方案就是数据地图，下面分别介绍网易和美团的数据地图产品。

网易元数据管理方案

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

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

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

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

美团团队元数据管理方案

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

离线场景下的元数据中心

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

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

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

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

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

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

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

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

元数据功能

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

总结

由上可见，基于元数据可以做很多事，除了最基本的指导开发外，对于数据质量管理、数仓建模、指标管理、安全管理等都有重大作用，特别是数据中台产品化后，元数据就更是重要了。