网易严选全链路数据治理的实践与总结-51CTO.COM

一、面临的问题

自16年成立以来，网易严选已经发展了7个年头。数据一直是网易严选的核心资产，支撑着我们的业务发展，大数据平台也在严选成立不久之后就开始建设了。

我们的大数据基础组建主要包括HDFS存储系统、Kafka/Pulsar等消息中间件，还有用于实时计算的Flink、批处理的Hive、Spark计算引擎、AI训练的temsoflow，在这些基础设施之上我们也开发了很多数据产品，如数据集成工具datahub，任务开发平台等。

严选的数据来源主要包括线上业务数据库的数据、埋点日志数据，这些数据经过数据集成工具收集至大数据平台，经过数据开发工程师、算法工程师的ETL处理来构建数据仓库、提取特征进行算法模型训练，处理好的数据最终被数据产品/算法/BI等服务使用。数据从集成到最终被使用的链路非常长，而且中间依赖包括计算/存储/调度等很多服务和组件。

随着业务的发展，任务越来越多，参与开发的人员也越来越多，很多问题就逐渐暴露了出来，主要包括如下几点：

1、首当其冲的是数据成本，数据日积月累、存储量与日俱增、计算量也随之增大，但是又不能快速准确地对数据进行分类，数据是否有用全然不知，数据也不敢轻易删除；

2、其次是数据使用效率低，越来越多的表缺乏管理，在频繁变更的需求面前无法快速知道想要的数据是否已经存在，存在的又不知道具体在哪，较多的时间花费在沟通确认上；

3、数据稳定性差，调度任务越来越多，用户的资源参数随意设置，集群计算资源不足导致任务经常失败无法及时产出数据。在大促时期，更是无法保证数据产出的稳定性；

4、数据开发缺乏规范，数仓分层混乱，模型随意设计不通用，导致sql代码随意编写、任务重复开发等问题，降低数据开发效率。

为了解决这些问题，我们成立了治理专项小组，并开发了全链路数据治理平台，目标是来提升大数据平台整体的服务效率，对整个数据体系流程进行系统性的治理。

二、全链路数据治理平台

整个治理平台的设计主要包括三大治理服务 + 6个治理模型 + 3个治理应用。

治理服务：包括统一元数据服务、全链路血缘服务、全链路监控服务；

治理模型：基于治理服务提供的基本信息，来对数据进行有效评估，给出治理策略，并由治理应用来实际执行。

主要包括：表生命周期模型、任务健康模型、任务优先级模型、任务资源模型、数据产出模型、任务调度模型；

治理应用：表治理、任务治理、系统治理。

1、统一元数据服务

我们通过统一元数据服务来统一对元数据进行管理，以解决元数据分散的问题，这些元数据可以清晰地描述数据在大数据体系中的运转状态和内部组织结构，我们的元数据主要来源于数据源、数据表、任务和数据服务。

像数据表元信息中我们详细记录了其表名、表结构，还记录了其访问情况、存储位置等，任务元信息中记录了任务类型、资源配置、调度周期、历史运行情况。

这些元数据都有相应的agent自动采集，当元数据发生变更时，如表结构的变更会及时上报。

2、全链路血缘服务

元数据只是定义了一个个数据实体，如何让这些孤立的实体建立联系，就是血缘服务的主要职责。

对于不同的数据服务和组件，我们也有相应的Agent来采集血缘，比如我们有Hive hook、spark listener来实时采集计算引擎的动态血缘，也有sql静态血缘解析器来采集sql任务中的血缘，当任务编辑上线时立即可以感知血缘的变更并更新。

每个agent将采集的局部血缘通过RPC请求方式传输给Linage Core模块，Lineage Core负责将这些局部血缘构建成完整的血缘图谱和持久化存储，并对外提供相应的血缘查询服务。

由于后续的所有治理措施是构建在血缘之上的，错误的血缘关系将导致错误的治理决策，所以血缘数据的准确性就尤其重要，我们有血缘校验模块来对建立的血缘进行稽核校验，以确保我们构建血缘的准确率。当前我们的血缘已经有99%覆盖率，已接入的血缘准确率达到100%。

3、全链路监控服务

最后一个关键的服务是全链路监控服务，负责监控数据链路中的任务、服务的运行情况，并收集相应的metrics，比如任务的资源使用情况，实时任务的消息延迟、批任务的执行时长、HDFS的整体存储水位、Yarn集群的资源使用情况等。

4、数据治理模型

当有了完整的数据元信息、血缘关系信息、监控信息之后，我们就可以基于这些信息，来构建一些治理模型，以辅助我们做出治理决策，并采取相应的治理措施。

比如，我们使用任务健康模型从任务的配置、资源使用、运行时长、产出数据使用率等多个维度来评估任务的健康程度，每一个任务都有一份体检报告，异常项一目了然。

使用表生命周期模型来根据表的访问频次、优先级、存储格式来对数据表进行分类。

数据处理模型主要是针对离线数据的调度，对离线调度任务进行路径分析，识别生产链路中的关键节点、判断是否出现资源瓶颈。

根据这些治理模型，可以让我们俯瞰整个大数据平台的运作情况，在此基础之上我们就可以快速地构建治理服务。

5、数据成本治理

首先分享表治理、任务治理两个数据成本治理的案例：

1）表治理

通过表生命周期模型，我们可以将表数据划分为几类：频繁访问的热表、访问频次不是那么高的温数据、几乎不访问的冷表。

对于热数据，我们可以在其产出后，进行缓存预热，来提高查询效率；对于冷数据，我们可以进行冷备、过期数据进行删除操作来节省存储。

还有一个就是小文件合并。众所周知，小文件在HDFS这种针对离线大文件而设计的存储系统是非常不友好的，存储效率低，过多的小文件对namenode带来的压力巨大。因此，我们可以给予表的存储信息，自动识别出有小文件的表，并通过小文件合并工具自动合并。

由于Hive是不支持事物的，同时对同一张表进行读写是有问题的，因此我们根据血缘和任务调度信息来进行错峰执行，避免同时对表的同一个分区进行操作，并且做了数据比对、备份、失败快速恢复回滚处理，保证合并过程数据的准确性。

2）任务治理

任务治理可以根据任务健康模型来识别健康分低的任务，并自动做出治理优化，如对产出冷表的任务进行下线处理，来节省存储计算资源；对任务进行计算引擎的自动升级，来提升其运行效率。

我们的任务离线调度是基于Azkaban的，任务之间的依赖需要用户手动配置，任务治理服务会自动对任务进行配置项优化，去掉无效的任务依赖、补全缺失的依赖，在配置的时候给出依赖建议，减少人工操作。

有些任务执行耗时耗资源，对于这些低效任务，我们采取报警的手段是通知到人，进行人工调优。

表和任务的治理主要是关注在局部和个体，而更为全局的治理，则由我们的系统治理来完成，接下来介绍一下我们的系统性治理项之一——数仓基线稳定性治理。

6、数仓基线稳定性治理

在数据生产链路中，会对核心数据产出任务配置不同的基线，比如挂在凌晨3点基线上的任务，需要在3点之前完成，晚于3点就造成了破线，从而导致数据产出延迟。

在数据开发过程中，任务的调度时间是通过人工设置的，而人工很难有一个全局的视角.来判断任务具体哪一个时间点调度是最佳时间，实际上往往是估摸着大概设置一个调度时间。

所以我们分析发现，有很多任务的调度时间设置是不合理的，导致系统在某一些时间段有任务堆积、资源不足的情况，从而导致基线破线频发，值班起夜频繁。

为了保障数据及时产出，我们针对全链路数仓任务进行智能调度，首先我们根据血缘信息对任务进行自动分级打标，然后根据任务的优先级、任务的历史运行情况和平台的整体计算资源，来自动计算出每个任务最合理的调度时间、资源配置。

由于这些任务都是T+1任务，调整后的效果提升是否明显，需要等到第二天凌晨才能知晓，而且频繁调整线上任务也存在较大的风险，因此我们开发一个调度模拟器来模拟任务调度，这样我们可以快速地验证我们的治理策略的效果，给我们提供是否实施该治理策略的依据，当效果符合预期时，才实际去调整，从而可以减少频繁调整线上任务规避风险。

下图是我们对数仓3点基线的一个治理效果，按照智能调度给出的治理策略，调整了线上任务的调度时间，效果还是非常显著，基线完成时间提前40小时。

前面介绍的成本治理和稳定性治理都是在事后介入治理，也就是先污染后治理，如果一直以这些策略的话是治标不治本。

我们不知道是小文件、任务配置不合理的问题，还是开发人员在开发阶段造成的问题。当我们深入了解数仓开发的全流程后，我们发现数仓建设过程中是存在很多问题，如数仓架构不合理、计算口径不统一、指标缺乏管理构建混乱，模型设计不规范开发效率低等。

三、数据开发治理

为了治理这类开发不规范的问题，我们构建了一套指标管理系统Polaris，提供指标、模型的开发管理能力，让数据开发流程更为规范，并提供自动生成任务的能力，以达到事前治理的目的，从源头避免了污染。

以前数据开发对指标的管理非常混乱（记录在文档中、指标起名随意、计算口径可能写在物理表注释中），指标管理平台可以提供更加标准的指标定义流程，在平台根据业务域来划分，进行业务过程、原子指标、派生指标的设计和计算口径的定义。

在模型构建流程上也更加规范，完全规避了数仓跨层依赖、反向依赖、相同指标重复计算的问题，并且平台提供了模型代码自动构建的能力，用户只需要在平台上设计好指标和模型即可，任务代码由平台根据模型自动生成，并自动完成任务的发布与调度，像之前提及的任务调度时间设置、资源设置、表存储格式设置都无需用户介入，仅需专注于模型的设计工作即可。