优采集平台(【数据中台】数据资产治理（详情见：元数据2.1）)

　　优采集平台(【数据中台】数据资产治理（详情见：元数据2.1）)

　　部门：数据中心

　　一、简介

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

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

　　多个数据类别

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

　　许多平台组件

　　大数据平台组件：Hive/Hbase/Kafka/Druid/Flume/Flink/Presto，内部工具：BI报表系统/索引库/OneService等。

　　采集长周期

　　新数据类型接入周期长，需要需求评审、开发、测试、联调、数据验证、上线。

　　访问效率低，采集稳定性

　　每种数据类型的访问都需要与业务方对接，效率不高。采集进程异常中断，无法及时感知。

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

　　二、元数据

　　2.1 什么是元数据

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

　　这些是数码照片的元数据，用于描述图片。在资产管理平台中，我们采集Hive组件的元数据包括：表名、字段列表、负责人、任务调度信息等。

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

　　2.2 采集 什么元数据

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

　　基本元数据

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

　　趋势数据

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

　　资源数据

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

　　血液数据

　　表/字段级别的上游和下游依赖项，任务输入和输出表依赖项。

　　任务数据

　　离线/实时计算任务名称、负责人、截止报警时间、脚本、任务配置等信息。

　　截至目前，采集所达到的平台组件已经覆盖了整个数据链路。涵盖10种数据+，基础元数据量10w+。主要包括：

　　离线平台组件

　　蜂巢/Mysql。

　　ʵʱƽ̨

　　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脚本等信息。

　　计算任务

　　通过分析任务的输入/输出依赖配置，获取血缘关系。

　　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，比较值的过程）。

　　统一存储服务

　　定义统一的数据存储模型，包括表基础元数据、趋势数据、血缘关系数据、趋势数据，实现不同数据类型的存储服务。

　　数据适配器桥

　　获取Kafka的数据，根据不同的数据类型转换成“统一仓储模型”，触发“统一仓储服务”完成数据写入。

　　4.2.2 通用型号

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

　　通用元数据模型

　　主要包括接入方信息、表基本信息、服务域信息和扩展信息。

　　一般趋势模型

　　主要包括表格信息定义、趋势指标定义、扩展信息。

　　通用血液模型

　　血缘关系图主要由点和线组成。点是表节点，边是任务节点；节点信息包括：节点名称、节点类型、节点扩展信息；表节点包括表基本信息，可以唯一确定一个表，任务节点包括基本任务信息。

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

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

　　4.2.3 访问、验证、限流

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

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

　　在采集SDK服务器上，每隔一定时间（每两秒）消费一批Kafka数据。支持设置消费数据的时间间隔和拉取的片数。下游入站压力不会因上报数据流量高峰而变化。大，起到了限流作用。

　　4.3 触发器采集

　　我们支持多种 采集 元数据方法。如何触发数据的采集？总体思路是：

　　增量 采集 更改的数据

　　常规采集全量数据

　　实时采集SDK上报数据

　　基于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 数据更新

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

　　全额采集，找不同

　　当全额为采集时，获取平台组件的所有元数据，全额与资产数据库中的元数据表进行比对，找出差异表并设置下线。

　　递增采集，遵循约定

　　增加采集时，与接入方约定不上报离线表，清理3天未更新的元数据平台。

　　五、监控和警告

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

　　5.1 采集 链路监控告警

　　5.1.1 接口监控

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

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

　　如下图，是服务接口的每日告警报告：

　　5.1.2 采集 进程监控

　　对于每个元数据采集服务，如果采集进程发生异常，都会发送告警通知。

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

　　5.1.3 Kafka 消息积压警告

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

　　5.2 结果数据对比

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

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

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

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

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

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

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

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

　　六、总结与展望

　　6.1 摘要

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

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

　　

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

　　6.2 展望

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

　　自动化采集

　　目前，要访问新的数据类型，需要与访问方确认数据上报格式并编写数据适配器。未来我们会考虑自动化采集，减少人工干预。接入方接入工单系统，发起工单申请，填写基本元数据信息。管理员审核通过后，可根据工单信息自动生成数据适配器，完成数据报表。

　　采集任务管理

　　目前，各种组件的元数据都是相连的。采集 任务数为 25+。新增采集任务或离线任务需要Apollo配置系统。采集 任务管理、搜索、任务启停的需求越来越强烈。

　　提高元数据质量

　　访问的元数据类型和元数据服务越来越多，对元数据的质量提出了更高的要求。如何保证数据的准确性和可用性是后续需要考虑的关键问题。·

　　支持业务元数据访问

　　目前主要是访问数据平台组件的元数据，业务侧元数据占比较小。未来我们会考虑支持业务数据的快速访问，支持采集和非结构化数据的存储。