优采集平台(元数据资产治理（详情见）——基于离线计算平台的介绍)

　　优采集平台(元数据资产治理（详情见）——基于离线计算平台的介绍)

　　一、简介

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

　　在早期的采集系统中，我们主要关注数据仓库，通过“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+。主要包括：

　　三、元数据提取

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

　　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 架构

　　

　　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 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.jdb*敏*感*词*.MySQLQueryInterruptedException: Query execution was interrupted

　　5.1.3 Kafka 消息积压警告

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

　　5.2 结果数据对比

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

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

　　表负责人：离职人员或特约负责人（表负责人为app、admin等）。

　　血缘关系：无相关任务，无上下游表。

　　趋势数据：表格趋势值非法（默认值-1）.

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

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

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

　　六、总结与展望6.1 结论

　　我们定义了一套通用的数据采集和存储模型，支持访问不同数据类型的元数据，支持多种访问方式，采集SDK提高了访问效率和数据时效性。如下图所示，已经访问了各个组件的元数据，统一管理数据，提供数据字典、数据地图、资产盘点、全局成本计费等元数据应用。

　　

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

　　6.2 展望

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

　　最后，有赞数据中心，长期招聘基础组件、平台研发、数据仓库、数据产品、算法等方面的人才，欢迎加入，一起享受~简历投递邮箱：。