数据平台-元数据中心

元数据的作用

数据中台的构建，需要确保所有的口径一致，要先把原先口径不一致的，重复的指标进行梳理，整合成一个统一的指标字段（指标管理系统），而前提，要搞清楚指标的业务口径，数据来源，计算逻辑。这些东西就是属于元数据

元数据包括哪些数据

• 数据字典
• 数据血缘
• 数据特征

下面举个例子

任务 flow_dws_trd_sku_1d 读取表dwd 生成汇总表dws
数据字典描述的是数据的结构信息。包括表名，注释信息，产出的任务，哪些字段，字段含义，字段类型等等。
数据血缘指的是上游表是由哪些下游表生成，一般做故障恢复，业务口径的理解等。
数据特征则表示数据的属性信息，有存储的位置，存储的大小，访问的热度，标签，主题域，数据层级(ods/dw/dm)等等属性信息。
既然一张表有这么多的信息需要整理展示查询，所以很有必要有一个元数据中心来管理。来贯穿公司的产品线

业界元数据中心产品

• 开源的有 Netflix 的 Metacat、Apache Atlas；
• 商业化的产品有 Cloudera Navigator。

Metacat 支持多数据源，可拓展的架构设计，擅长管理数据字典。
Atlas 支持数据血缘比较完善，实时数据血缘采集

血缘采集一般通过三种方式：
1.静态的SQL解析，不论是否执行都会去解析
2.通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表
3.通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。将各个项目的执行成功的SQL，不论是pull 或者push 的方式通过元数据中心进行解析，获取到输入表 输出表。

第一种方式，面临准确性的问题，因为任务没有执行，这个 SQL 对不对都是一个问题。第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。所以第二种方式，是比较理想的实现方式， Atlas 就是这种实现。但是这种方式比较难以获取到表的特征数据，比如负责人信息，平台信息，这样在存储边的时候会有信息缺失。综上，选择了第三种方式，每日t+1统计执行成功的sql 汇总解析血缘。血缘延迟1天，但是边的信息会很全。而且不用开发hook或者Listener

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

公司的元数据产品

元数据系统整体分为三个大的方面:数据的采集,数据的存储,数据的应用。下面分别简单介绍其中的各个功能以及实现

• SQL采集：通过QE API、Kepler采集sql入DB。目前数据产品都经过QE API或Kepler调度收口
• SQL解析存储：解析SQL的输入表、输出表，以及应用来源，存入图数据库
• 数据应用：热度计算数据表的引用次数来排名，热度为0的表需要push数仓同学修改；追寻到任务、表、应用、人等4者之间的关系图谱，上下游依赖等信息

数据的采集

• 数据中心的数据查询目前分别在qe系统（查询），kepler系统（调调度），airflow系统（调度），以及tableu（报表）等系统中，其中qe系统分为qeAPI和qe的客户端。用户通过这些平台，提交自己的任务或者定时运行自己的任务。平台会将这些运行的SQL，存储到各自的DB。元数据会从指定的DB中收集各个SQL
• 用户执行的SQL中会有部分的创建、修改表的行为，会修改hive的metastore，元数据平台会通过binlog将hivemetastore采集到自己的数据库中。降低对集群底层的压力

数据的存储

• 将用户的SQL中的信息采集后经过SQL的解析，拿到血缘关系以及字段信息、修改信息、责任人等，存入图数据库。选择图数据库的原因是因为血缘关系复杂多变，依赖关系多，普通关系型数据库无法支撑这么大的依赖关系，查询时响应比较慢。
• 将binlog同步来的信息存储到mysql数据库
• 将部分mysql信息同步到ElasticSearch数据库中，用来支持数据的检索

数据的应用

• 数据的搜索：通过ElasticSearch进行搜索。支持数据库名、表中英文名、表描述、字段名、字段注释等关键信息，能够根据简单的关键字，快速定位到想要的表。ElasticSearch更加适合这种多字段，多文本的搜索功能。搜索速度控制在10ms以内
• 数据的维护：表的注释信息可以人工进行维护。表所属的业务线或者是分类信息都通过简单的设置维护到平台中。
• 数据的热度：通过采集部分采集到的表以及SQL，通过SQL解析功能解析后，在存储时会存储到数据库中，每日会计算一份近30日的数据存储到mysql，提供对外接口，用来展示表的使用情况，其中表的更改，查询都会算作一次使用，如果使用的SQL解析失败。则不会计算到热度中，因为出错后无法根据SQL解析到表。
• 血缘分析：根据图数据库中存储的关系，直接查询图数据库，生成血缘关系，目前仅展示两层关系。父类和子类。
• 表生成逻辑：在airflow阶段：对于数仓的表，会定期从git上拉取代码，生成到元数据的数据库中，用作表生成逻辑，后期迁移的kepler后，kepler自带输入输出表的功能，直接就能查询到生成逻辑。

具体场景

1. 血缘分析场景

首先解析SQL，以Hive为例。先定义词法规则和语法规则文件，然后使用Antlr实现SQL的词法和语法解析，生成AST语法树，遍历AST语法树完成后续操作。对于select * 的SQL可以通过客户端禁止，或者服务端解析后对于select * 的行为通过api去查询表的结构补充字段。
先经过Semantic Analyzer Factory类进行语法分析，再根据Schema生成执行计划QueryPlan。关于表、列的血缘，可以从LineageInfo、LineageLogger类中获得解决方案。

需要统计的hive操作类型

有了上面的操作类型可以清楚看到表是如何进行流转的
元数据血缘的展示效果，目前公司内只做了表的血缘。

返回的数据结构

其实对于数据血缘来讲，如果只做表级别的血缘，可以通过关系型数据来做，二期的血缘改回了mysql，因为我们的展示只是上下二级，不是全链路图形展示。也和降成本有关系。

用图数据库的话，将input信息和output信息，作为点，operation作为边，上面返回的数据其实就是从图数据库直接返回的数据 rid表示的就是当前点的id信息

对于血缘 还有一个问题，就是即使要清理历史的边，因为可能input output存在了很久，小时级别的任务，可能存在上千条边，所以需要制定清除策略，保存最近N天/N条数据边，不然mysql/图数据库会卡。

元数据应用对应的原型展示

1. 数据搜索
   

2. 引用热度

   • 字段的热度
     

   • 表的热度以及使用人
     

   这个对于不知道表的owner是谁的时候很方便，看看谁在用，问一下就好了

3. 血缘关系
   如上

4. 数据地图
   如表热度

5. 数据维护与特征
   

   对于数据特征，数据表owner可以修改表的特征信息

6. 生成逻辑
   每张业务表都有生成逻辑的展示，自动从调度系统同步
   我们的调度系统中，每个hsql的任务会有输出表，通过输出表关联到元数据，就可以将两个系统串联起来。
   

7. 其他的功能
   

公司的元数据还有那些不足

1. 由于历史原因，表和底层存储的位置不能关联起来，页面上没有展示底层存储的位置，hive表的location。外部表可能经常换
2. 没有一个建表的系统 这个至关重要，我认为要做元数据系统之前，就要把建表的系统建立起来，收起权限，规范信息，临时表只能往测试库建，正式表的创建通过系统走，这样才能将信息统计起来
3. 实时的元数据信息
4. 

Q&A

参考

1. 饿了吗元数据实践之路
2. 网易元数据中心的实践方案