文章采集api(数据资产治理（详情见）——元数据提取)

　　文章采集api(数据资产治理（详情见）——元数据提取)

　　来源：

　　一、简介

　　数据资产治理（详见：数据资产、赞智治理）需要数据。它要求数据类型齐全，数量大，并尽可能覆盖数据流通的方方面面。元数据采集

变得尤为重要，它是数据资产治理的核心基础。

　　在早期的采集系统中，我们主要使用数据仓库通过“API直连方式”采集Hive/Mysql表的元数据。随着业务的快速发展，对数据运营和成本管理的需求越来越强烈。元数据需要覆盖整个数据链路，包括离线计算平台、实时计算平台、内部工具、任务元数据等。在采集

元数据的过程中，我们遇到了以下困难：

　　本文主要从元数据的意义、提取、采集、监控告警等方面介绍了我们所做的一些事情。

　　二、元数据2.1 什么是元数据

　　什么是元数据？元数据是“用于描述数据的数据”。例如：我用手机拍了一张照片，查看了照片的详细信息，如下图：

　　照片信息

文件名：IMG_20201217_114115

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

分辨率：4608X2592

文件大小：2.69MB

相机制造商：OnePlus

相机型号：ONEPLUS A5000

闪光灯：未使用闪光灯

焦距：4.10mm

白平衡：自动

光圈：f/1.7

曝光时间：1/50

ISO：1250

　　这些是数码照片的元数据，用于描述图片。在资产管理平台，我们采集

Hive组件的元数据，包括：表名、字段列表、负责人、任务调度信息等。

　　采集

整个链接的数据（各种元数据）可以帮助数据平台回答：我们有什么数据？有多少人在使用它？什么是数据存储？如何找到这些数据？什么是数据流？结合血缘关系分析问题根源，分析影响。

　　2.2 采集

了哪些元数据

　　如下图所示，是一个数据流图。我们主要采集

了各种平台组件：

　　

　　到目前为止，采集

到的平台组件覆盖了整个数据链路。涵盖10种数据+，基础元数据量10w+。主要包括：

　　三、元数据提取

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

　　计算任务通过分析任务的输入/输出依赖配置来获取血缘关系。 SQL类任务使用“Sql Parser”（ANTLR4系统实现的sql重写工具）工具解析SQL脚本，获取表/字段级血缘关系。 3.1个线下平台

　　主要采集

Hive/RDS表的元数据。

　　Hive组件的元数据存储在Metastore中，通过JDBC访问Mysql获取数据库表的元数据。根据Hive表信息组装HDFS地址，通过FileSystem API获取文件状态、文件编号、文件大小、数据更新时间等趋势数据。

　　RDS平台提供Mysql服务的管理，通过平台提供的服务接口获取表元数据、趋势数据、访问状态等信息。

　　3.2 实时平台

　　主要是Flume/Hbase/Kafka等组件的元数据。

　　例如：我们访问KP平台的工单数据，获取topic的基本元数据信息，定时消费topic获取样本数据，解析字段列表。平台本身提供集群状态和业务监控指标，通过平台服务获取集群资源的使用情况。

　　3.3 个内部工具

　　主要是BI报表系统的血缘关系（一个BI报表查询的Hive表和Mysql表的关系）、指标库（Hive表和指标关联字段的关系）、OneService服务（哪个数据库表的关系数据）由接口访问）数据。

　　这些内部系统在产品的不断迭代中积累了大量的元数据。在不考虑元数据的时效性的情况下，我们一般将这些系统的数据同步到Hive数据库中，离线处理后获取元数据。

　　3.4 任务元数据

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

　　这些计算任务都放在磁盘上，通过Binlog同步或者离线同步获取任务列表，获取任务的元数据。

　　四、数据采集

　　元数据提取后，我们可以得到整个数据链中各个平台组件的元数据。数据采集​​是指将这些元数据存储到数据资产管理系统的数据库中。

　　4.1种采集方式

　　采集

数据的方式主要有三种。下表列出了三种方式的优缺点：

　　

　　一般情况下，我们建议业务方使用收购SDK。主动上报元数据，访问时只需要关注上报数据格式和SDK初始化，即可快速完成上报。

　　4.2采集SDK设计

　　采集SDK支持基础元数据、趋势数据、血缘关系数据的上报，主要包括客户端SDK和采集服务器两部分。客户端SDK主要实现通用报表模型的定义和报表功能，采集服务器主要实现不同的适配器完成数据的统一存储。

　　4.2.1 架构

　　

　　获取SDK客户端

　　定义了基本元数据（MetaSchema）、趋势数据（TrendSchema）、血缘关系数据（LineageSchema）的通用模型，并支持扩展新的报告模型（XXXSchema）。 ReportService实现了向Kafka推送数据的功能。

　　采集

服务器

　　数据鉴权服务器消费Kafka，获取数据后，对每条记录的签名进行鉴权（获取记录中的appId、appName、token信息，重新生成token，比较值的过程）。统一仓储服务定义了统一的数据仓储模型，包括表基础元数据、趋势数据、血缘关系数据、趋势数据，实现不同数据类型的仓储服务。数据适配器Bridge获取Kafka的数据，根据不同的数据类型转换成“统一存储模型”，触发“统一存储服务”完成数据写入。 4.2.2 通用模型

　　采集

了很多平台组件。我们参考Hive“表模型”的定义，抽象出一套通用的数据上报模型，保证数据上报和数据存储的可扩展性。

　　通用血缘模型主要包括血缘模型定义和任务血缘模型定义，支持用户分别上报血缘关系和任务血缘关系。模型定义如下：

　　/**

* 表血缘模型定义

*/

@Data

public class TableLineageSchema {

/**

* 当前节点

*/

private T current;

/**

* 父节点

*/

private List parents;

/**

* 子节点

*/

private List childs;

/**

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

*/

private String extParam;

}

　　/**

* 表任务血缘定义

*

*/

@Data

public class JobLineageSchema {

/**

* 任务节点对象

*/

private Job task;

/**

* 输入对象列表

*/

private List inputs;

/**

* 输出对象列表

*/

private List outputs;

/**

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

*/

private String extParam;

}

　　每个模型定义都有一个扩展字段（常规的 json 格式）。不在定义中的指标可以放在扩展字段中。数据上报后，也会存储在元数据表的扩展字段中。访问新的类型，索引定义大不相同，元数据上报是通过扩展新的数据模型定义来完成的。

　　4.2.3 访问、验证、限流

　　如何保证用户上报的数据安全？我们设计了一组签名：访问方Id（appId）、访问名称（appName）、访问标识（token）。管理员填写基本接入方信息，生成随机的appId和token信息。业务方在初始化SDK集合时，指定了签名信息，每上报的数据都会携带签名。在采集服务器上，每条数据都经过签名和认证，保证了数据的安全性。

　　采集SDK会对每一条上报的数据执行通用规则来检查数据的有效性，比如表名不为空，负责人的有效性，表的大小，趋势数据不能为负数等。如果检测到非法数据，将被过滤掉并触发报警通知。

　　在采集SDK服务器上，每隔一定时间（每两秒）消费一批Kafka数据。支持设置消费数据的时间间隔和拉取件数，不会因为上报数据的流量高峰而增加下游存储压力。 ,起到限流作用。

　　4.3 触发获取

　　我们支持多种元数据采集

方法。如何触发数据采集

？总体思路是：

　　基于Apollo配置系统（见：Apollo's Praise in Practice）和Linux系统的Crontab功能，实现任务调度。数据采集​​任务在Apollo上配置。更改配置后，Apollo会发布，配置信息会实时同步到在线节点的Crontab文件中。

　　4.3.1 增量任务，准实时

　　支持获取组件最近变化的元数据，配置增量任务，提高元数据采集的实时性。比如增量采集

Hive表元数据，每1分钟查询一次metastore，获取最近变化的元数据列表，并更新元数据。

　　4.3.2个满任务，走底线

　　增量采集

可能会出现数据丢失的情况。每 1 天或更多天完成一次完整采集

，作为确保元数据完整性的底线计划。

　　4.3.3 采集SDK并实时上报

　　采集SDK支持实时和全量上报模式。一般要求接入方数据实时变化，不定期上报一次满量。

　　4.4 数据存储、更新

　　数据采集后，需要考虑如何存储，以及元数据发生变化时如何同步和更新。我们对采集

到的元数据进行分类统一，抽象出“表模型”，分类存储。

　　4.4.1 数据存储

　　我们评估了每个组件的元数据量（共10w+），估计了数据可能的使用场景，最终选择了Mysql来存储。为了满足用户个性化的查询需求，构建了Es宽表。表粒度主要包括：表名、备注、负责人、字段列表、趋势信息、业务领域信息、任务信息等，在数据采集过程中同步更新Es表，保证元数据查询的实时性。定期更新（构建离线模型表，每天同步更新Es表），保证元数据的完整性。

　　元数据中的表不是孤立存在的。一般有关联任务（离线任务、实时任务）输出表，表和任务之间的流向关系也会在数据图中显示。那么如何在众多平台组件中唯一区分一个表呢？我们通过表所在的集群名称、项目名称、表类型（它来自哪个平台组件）和表名称的组合来唯一区分。

　　数据分类存储，最终形成：基础元数据表、趋势数据表、任务元数据表、血缘关系数据表。

　　4.4.2 数据更新

　　元数据表离线，如何更新？

　　五、监控和警告

　　完成数据采集后，就全部完成了吗？答案是否定的。在采集过程中，数据种类繁多，删除方式多样，删除链接长度。任何环节的任何问题都会导致结果不准确。我们通过以下方式来保证采集服务的稳定性。

　　5.1 采集

链路监控告警5.1.1 接口监控

　　我们将系统的所有服务接口分为核心、重要、通用三个层次，并支持标注接口和责任人的注解。异常会触发不同级别的警报通知。核心业务异常直接触发电话报警，重要或一般业务异常触发电子邮件报警。系统会存储接口请求和执行状态并删除，每天向接口服务负责人发送服务日报。通过将元数据采集服务标记为核心重要服务，“API直连方式”接口异常感知。

　　如下图是服务接口的告警通知：

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

你负责的[元信息采集]模块(backup为XXX)出现[重要]等级问题, 方法名:[com.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 采集过程监控

　　对于每个元数据采集服务，如果采集过程中出现异常，都会发出警报通知。

　　如下图，是采集过程中出现异常触发的告警：

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

你负责的[元信息采集]模块(backup为XXX)出现[一般]等级问题, 方法名:[com.youzan.bigdata.crystal.asyncworker.work.AsyncAllRdsDDLWorker.run], 异常信息:/n

### Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLQueryInterruptedException: Query execution was interrupted

　　5.1.3 Kafka 消息积压警告

　　消费Kafka数据，通过kp平台配置消息backlog告警，实现SDK服务采集异常感知。

　　5.2 结果数据对比

　　主要用于事后监测预警，定期探索采集的元数据量异常波动。针对不同类型的元数据，通过将当天采集的金额与过去7天的历史平均金额进行比较，设置异常波动的告警阈值，超过阈值时触发告警通知。

　　根据采集到的元数据结果表，配置一些数据质量检测规则，定期执行异常规则，发现问题数据触发告警通知。这保证了对结果数据的异常感知。例如定义的数据质量规则：

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

　　通过事前、事中、事后的监测预警机制，及时发现和感知采集异常。对于异常问题，我们一般以项目迭代的方式发起jira，组织相关人员进行审核。追根溯源，讨论改进方案，制定行动，关注并持续收敛问题。

　　六、总结与展望6.1 结论

　　我们定义了一套通用的数据采集和存储模型，支持访问不同数据类型的元数据，支持多种访问方式。采集SDK提高了数据的访问效率和时效性。

　　如下图所示，已经访问了各个组件的元数据，统一管理数据，提供数据字典、数据地图、资产盘点、全局成本计费等元数据应用。

　　

　　如果将数据资产治理比作高层建筑的建设，那么不同构件的元数据是原材料，数据采集是基础。只有夯实了基础，数据治理的建设才能越来越稳固。

　　6.2 展望

　　在数据采集

的过程中，我们也遇到了很多问题。在后续工作中，我们需要不断的优化和功能迭代，包括但不限于：