数据资产治理：元数据采集那点事

数据资产治理：元数据采集那点事

一、介绍

数据资产治理的前提要有数据。它要求数据类型全、量大，并尽可能多地

覆盖数据流转的各个环节。元数据采集就变得尤其重要，它是数据资产治理的

核心底座。

在早期的采集系统，我们主要面向数仓，通过"API直连方式"采集

Hive/Mysql表的元数据。随着业务的快速发展，数据运营、成本治理的需求越

来越强烈。元数据需要覆盖到数据全链路，包括离线计算平台、实时计算平台、

内部工具，任务元数据等。采集元数据的过程中，我们遇到以下困难：

•数据类别多

需要采集组件的基础元数据、趋势数据、资源数据、任务数据和血缘数

据。

・平台组件多

大数据平台组件：Hive/Hbase/Kafka/Druid/Flume/Flink/Prest。，内

部工具：BI报表系统/指标库/OneService等。

・采集周期长

接入新的数据类型周期长，需要经过需求评审、开发、测试、联调、数

据核对、上线。

•接入效率低，采集稳定性

接入每种数据类型需要和业务方对接，效率不高，采集过程出现异常中

断，不能及时感知到。

本文主要从元数据的含义、提取、采集、监控告警几个方面，介绍我们做的

一些事情。

二、元数据

2.1什么是元数据

什么是元数据？元数据是“用来描述数据的数据"。举个例子：我拿手机拍摄了

一张照片，查看照片的详情，如下所示信息：

照片信息

文件名:IMG_20201217_114115

时间:2020年12月17号11:30:01

分辨率：4608X2592

文件大小：2.69MB

相机制造商：OnePlus

相机型号：ONEPLUSA5000

闪光灯：未使用闪光灯

焦距：4.10mm

白平衡：自动

光圈：f/1.7

曝光时间：1/50

ISO:1250

这些就是数码照片的元数据，用来描述一张图片。在资产治理平台中，我们

采集Hive组件的元数据包含：表名称、字段列表、责任人、任务调度信息等。

收集全链路的数据（各类元数据），可以帮助数据平台回答：我们有哪些数据？

有多少人在使用？数据存储是多少？如何查找这些数据？数据的流转是怎么样

的？结合血缘关系进行问题溯源和影响分析。

2.2采集了哪些元数据

如下图所示，是一张数据的流转图，我们主要采集了各个平台组件的：

示息：数据坡路图馥曙羽严治理

・基础元数据

表名称、备注、字段列表、责任人、业务域、表所在集群、项目等信息。

.趋势数据

表的大小、行数、文件数、分区数、任务调度时长、产出时间等信息。

・资源数据

集群的吞吐量、QPS、调度任务消耗Cpu、内存大小等信息。

・血缘数据

表/字段级别的上下游依赖关系、任务的输入输出表依赖关系。

•任务数据

离线/实时计算任务的名称、责任人、deadline告警时间、脚本、任务

配置等信息。

截至目前为止，采集到的平台组件覆盖了整个数据的链路。覆盖数据类型10

种+,基础元数据的数量主要包括：

10w+o

・离线平台组件

Hive/Mysql0

•实时平台

Flume/Kafka/Hbase/Kylin/Es/Presto/Spark/Flink等。

•内部工具

BI报表系统、指标库系统、OneService,测试QA系统。

三、元数据提取

如何从众多平台组件提取元数据呢？大致有这几个方面：

・访问Metastore获取基础元数据

一般的平台组件会把元数据存储在Mysql等关系型数据库中，通过访

问Metastore获取基础的元数据。

•获取组件集群资源数据

平台组件本身会提供Metrics和Alarm的监控服务，定期请求服务，

把数据流入到Hbase/Opentsdb等存储。通过访问存储并对指标数据

进行汇总统计，获取集群或任务的资源数据。

•获取平台组件业务指标

数据中台内部有各种平台，比如KP（Kafka基础平台）、RP（Flink实

时计算平台）、RDS（管理Mysql的工具平台）、DP（数据研发平台）。

通过这些平台自身提供的服务获取基础元数据、业务监控指标、集群

QPS、吞吐量等数据。

・获取血缘数据用户在DP平台、RP平台上开发计算任务，我们可以及

时的获取发布的任务列表、任务的配置信息、SQL脚本等信息。

a.计算任务通过解析任务的输入/输出依赖配置，获取血缘关系。

b.SQL类型任务通过"SqlParser"（使用ANTLR4系统实现的sql改写

工具）工具解析SQL脚本获取表/字段级别的血缘关系。

3.1离线平台

主要是采集Hive/RDS表的元数据。

Hive组件的元数据存储在Metastore,通过JDBC的方式访问Mysql获取

库表的元数据。根据Hive表信息组装成HDFS地址，通过FileSystemAPI获

取文件的状态、文件数、文件大小、数据更新时间等趋势数据。RDS平台提供了

对Mysql服务的管理，通过平台提供的服务接口获取表的元数据、趋势数据、

访问情况等信息。

3.2实时平台

主要是Flume/Hbase/Kafka等组件的元数据。举个例子:我们通过访问KP

平台落盘的工单数据，获取topic的基础元数据信息，定时消费topic获取抽样

数据，解析出字段列表。平台本身提供集群状态和业务监控指标，通过平台服务

获取集群资源的使用情况。

3.3内部工具

主要是BI报表系统（一张BI报表查询的Hive表、Mysql表关系\指标库

（指标关联的Hive表和字段关系XOneService服务（接口访问哪些库表的关

系数据）的血缘数据。这些内部系统在产品不断迭代中积累了很多元数据。在不

考虑元数据时效性的情况下，我们一般同步这些系统的数据到Hive库，经过离

线处理得到元数据。

3.4任务元数据

元数据任务主要是DP离线任务、Flink计算服务、Flume任务。这些计算

任务都有落盘，通过Binlog同步或离线同步的方式获取任务列表，得到任务的

元数据。

四、数据采集

经过元数据提取，我们可以获取数据全链路中各个平台组件的元数据。数据

采集指的是把这些元数据入库到数据资产管理系统的数据库中。

4.1采集方式

采集数据主要有3种方式，下方表格列出了3种方式的优缺点：

采集方式描述优点缺点适用场景举例

API直连请求组件提供无侵入强依赖API服有现成的API采集

的API服务获快速接入务服务RDS/Druid元

取到元数据并满足采集需求数据

入库解析不同API

返回的数据格

式

离线采集同步组件的元无侵入数据时效性元数据提取复采集内部工具

数据到Hive库T+1杂，数据的时BI报表系统，

表，进行数据效性低指标库系统的

离线处理得到元数据

元数据并完成

入库

采集SDK业务方通过采快速接入有侵入性有独立的平台采集实时平台

集SDK主动上解耦系统组件的元数据

报元数据到时效性高时效性高

Kafka

一般情况我们推荐业务方使用采集SDK。主动上报元数据，在接入时只需要

关注上报的数据格式、SDK的初始化，就能快速完成上报工作。

4.2采集SDK设计

采集SDK支持上报基础元数据、趋势数据、血缘数据，主要包括客户端SDK

和采集服务端两部分。客户端SDK主要实现了通用上报模型的定义和上报功能,

采集服务端主要实现了不同的适配器，完成数据的统一入库。

4.2.1架构

FlinkDruidKafka

采集

监控

告警

数据

校验

数据

鉴权

pull

采集SDK客户端

定义了基础元数据(MetaSchema\趋势数据(TrendSchema\血缘数

据(的通用模型，支持扩展新的上报模型(

LineageSchema)XXXSchema)o

Reportservice实现了数据推送到Kafka的功能。

采集服务端

a.数据鉴权服务端消费kafka,获取到数据后，对每条记录的签名进行认

证（取到记录中的appld、appName、token信息，重新生成token

并比对值的过程X

b.统一入库服务定义统一数据入库模型，包括表基础元数据、趋势数据、

血缘数据、趋势数据并实现不同数据类型入库的服务。

c.数据适配器Bridge获取kafka的数据，根据不同的数据类型转换成

"统一入库模型"，并触发"统一入库服务"完成数据的写入。

4.2.2通用模型

采集的平台组件多，我们参照Hive"表模型"的定义，抽象出了一套通用

的数据上报模型，保障了数据上报和数据存储的扩展性。

・通用元数据模型主要包括接入方信息、表基础信息、业务域信息、扩展

信息。

.通用趋势模型主要包括表信息定义、趋势指标定义、扩展信息。

・通用血缘模型一张血缘图主要是由点、线组成的。点指的是表节点，边

指的是任务节点；节点信息包括：节点名称、节点类型、节点扩展信

息；表节点包括表基础信息，可以唯一确定一张表，任务节点包括任

务的基础信息。

通用血缘模型主要包含表血缘模型定义、表任务血缘模型定义，支持用户单

独上报表血缘、任务血缘。模型定义如下：

*表血缘模型定义

V

(5)Data

publicclassTableLineageSchema<TextendsTableNode>{

*当前节点

*/

privateTcurrent;

/**

*父节点

*/

privateList<T>parents;

/**

*子节点

*/

privateList<T>childs;

/**

*表级别血缘扩展信息,json对象，kv结构

*/

privateStringextParam;

)

*表任务血缘定义

*

*/

@Data

publicclassJobLineageSchema<JobextendsJobNode,TableextendsTableNode>

(

/**

*彳甥节点艰

*/

privateJobtask;

/**

*输入又搀列表

*/

privateList<Table>inputs;

/**

*输出对象列表

*/

privateList<Table>outputs;

/**

*任务级别血缘扩展信息，json对象，kv结构

*/

privateStringextParam;

)

每种模型定义留有扩展字段（约定json格式），不在定义中的指标可以放在

扩展字段，上报数据后，也会被存储在元数据表的扩展字段中。接入新的类型,

指标定义差异性较大，通过扩展新的数据模型定义，完成元数据的上报。

4.2.3接入，校验，限流

如何保障用户上报的数据是安全的？我们设计了一组签名：接入方Id

（appld1接入名称（appName1接入标识（token工管理员填写基础的接

入方信息即可生成随机的appld、token信息。业务方在初始化采集SDK时，

指定签名信息，上报的每条数据会携带签名。在采集服务端，会对每条数据进行

签名认证，这样保障了数据的安全性。采集SDK会对上报的每条数据执行通用

规则，检查数据的合法性，比如表名称不为空、责任人有效性、表大小、趋势数

据不能为负数等。检杳出非法数据会过滤掉并触发告警通知。在采集SDK服务

端，定时（每隔两秒）消费Kafka一批数据，支持设置消费数据的时间间隔和拉

取条数，不会因为上报数据的流量波峰导致下游入库压力变大，起到了限流的作

用。

4.3触发采集

我们支持了元数据的多种采集方式，如何触发数据的采集呢？整体的思路是：

・增量采集变更的数据

•定期采集全量的数据

・实时采集SDK上报的数据

基于阿波罗配置系统（详见：Apollo在有赞的实践）和Linux系统的Crontab

功能，实现了任务的定时调度。数据采集任务配置在阿波罗上，变更配置后发布

阿波罗，实时同步配置信息到线上节点的Crontab文件中。

4.3.1增量任务，准实时

支持获取组件最近变更的元数据酒己置增量任务才是升元数据采集的实时性。

比如增量采集Hive表元数据，每隔1分钟查询metastore获取最近变更的元

数据列表，更新元数据。

4.3.2全量任务，兜底

增量采集可能存在丢数据的场景，每隔1天或多天全量采集一次，作为兜底

方案保障元数据的完整性。

4.3.3采集SDK,实时上报

采集SDK支持实时和全量上报模式，一般要求接入方数据变更后实时上报,

同时不定期全量上报一次。

4.4数据存储，更新

数据采集后,要考虑如何存储、元数据发生变更如何同步更新。我们对采集

过来的元数据进行分类归一，抽象出"表模型"，分类存储。

4.4.1数据存储

我们评估了每种组件的元数据数量（总量10w+1预估数据可能的使用场

景，最终选择Mysql存储。为了满足用户的个性化查询需求，构建Es宽表。以

表粒度为主包括：表名称、备注、责任人、字段列表、趋势信息、业务域信息、

任务信息等。数据采集过程中同步更新Es表保障了元数据查询的实时性，定期

（构建离线模型表，每天同步更新Es表）全量更新一次，保障了元数据的完整

性。元数据中的表不是孤立存在的，一般有关联的任务（离线任务，实时任务）

产出表，数据地图中也会展示表和任务的流转关系。那么在众多的平台组件中，

如何唯一的区分出一张表呢？我们是通过表所在的集群名称、项目名称、表类型

（来自哪个平台组件1表名称这几个字段组合来唯一区分。数据分类储存，最

终形成：基础元数据表、趋势数据表、任务元数据表、血缘数据表。

4.4.2数据更新

元数据表下线了，如何同步更新呢？

•全量采集，找差异全量采集时，获取平台组件的所有元数据，和资产数

据库中的元数据表做全量比对，找出差异的表并设置下线。

•增量采集，走约定增量采集时，与接入方约定：已下线的表不上报，3

天未更新的元数据平台会进行清理。

五、监控预警

完成了数据的采集，是不是就大功告成了？答案是否定的。采集过程中数据

类型多、删掉方式多样、删掉链路长，任何一个环节出现问题就会导致结果的不

准确。我们通过以下方式保障采集服务的稳定性。

5.1采集链路监控告警

5.1.1接口监控

我们把系统所有的服务接口划分为三个等级：核心、重要、一般，并支持注

解的方式打标接口和责任人，发生异常触发不同程度的告警通知。核心服务异常

直接触发电话告警，重要或一般服务异常触发邮件告警。系统会存储接口请求和

执行的状态删掉，每天定时向接口服务的责任人发送服务日报。通过将元数据的

采集服务标记为核心和重要服务，对"API直连方式"的接口做到了异常感知。

如下所示，是服务接口的告警通知：

[Warning][prod][data-dict]-数据资产平台告警

你负责的[元信息采集]模块(backup为XXX)出现[重要]等级问题，方法

^iIcom.youzan.bigdata.crystal.controller.HiveMetaController.getHiveDb],异常信息:null

host:XXXXXX

处理地址：https://XXXX

如下所示，是服务接口的告警日报：

[Warning][prod][data-dict]-数据资产平台告警

[shunfengche]今日问题汇总

请及时收敛今日问题，总问题数1个，出现2次

【核心】问题0个：

【重要】问题0个：

【一般】问题1个：

[数据采集]com.youzan.bigdata.crystal.controller.HiveMetaController.getHiveDb今日出现2次，

已存在5天，历史出现8次

host:XXXXXX

处理典：https://XXXX

5.1.2采集过程监控

针对每个元数据采集服务，采集过程发生异常则发送告警通知。如下所示，是采

集过程发生异常触发的告警：

[Waming][prod][data-dict]-数据资产平台告警

你负责的[元信息采集]模块(backup为XXX)出现[一般]等级问题，方法

=S：[com.youzan.bigdata.crystal.asyncworker.work.AsyncAIIRdsDDLWorker.run],异常信息:/n

###Errorupdatingdatabase.Cause:

com.mysql.jdbc.exceptions.jdbc4.MySQLQueryInterruptedException:Queryexecutionwas

interrupted

5.1.3kafka消息积压告警

消费kafka数据，通过kp平台配置消息积压告警，针对采集SDK服务做

到了异常感知。

5.2结果数据比对

主要是事后监控预警，定时探查采集的元数据数量异常波动。对不同类型的

元数据，通过比较当日采集的数量和近7天历史平均的数量，设定异常波动告警

阈值，超过阈值触发告警通知。针对采集的元数据结果表，配置一些数据质量探

查规则，定时执行异常规则发现问题数据触发告警通知。这样保障了对结果数据

的异常感知。比如已定义的数据质量规则：

・表责任人：离职人员或特殊责任人（表的责任人是叩p,admin等）数

量。

・血缘：无关联的任务，无上下游的表数量。

・趋势数据：表趋势值非法（默认值-1）的数量。

.业务域：表所属的业务域值为-1（非法值）的数量。

5.3项目迭代机制，采集问题收敛

经过事前、事中、事后的监控告警机制，能够及时发现并感知采集异常。对

异常问题，我们一般以项目迭代的方式，发起"a，组织关联人复盘。追溯根因，

讨