数据治理-数据质量治理

前言

作为数据er，数据质量一直是最大的困扰，问题来源2个方面，1是下游反馈较多Bug工单导致，Bug工单会延迟大家项目进度，同时不作为数据价值产出，但还是得给业务方解答反馈，2是基线问题，不知道各位数据er是什么情况，就语兴原来在阿里及网易的值班经历来说，当时组内一人值班一周，7天值班时间有5天夜间都被电话叫醒，更难受在于夜间不止1个电话，最终基线还会破线，较为头疼，因此对于数据质量治理在数仓团队内部较为重要。

本期语兴从数据质量治理角度出发，与大家一起探讨数据质量治理最佳实践

数据质量治理背景

大家应该知道数据质量保障措施包括DQC、基线/SLA、数据问题上报平台、数据质量长期监测跟踪体系等。

这里数据质量治理前提是已经做过数据质量规划，如没实施数据质量方案需要先去部署，存在的问题包括：

1．基线/SLA经常破线起夜率较高：由于线上任务告警过多（任务报错、资源告警、任务超时等）导致值班同学高频率起夜看问题，同时部分任务挂在基线/SLA上导致夜间电话不断，同时对于跨域值班的同学、新人来说处理起来较难，需要去找他人解决，对于跨BU数据使用还需要找到其他业务方去处理，因此数据er甚至能看到半夜值班起来开会的情况，对于这种情况都需要去“摇人”，虽然解决了数据稳定产出的问题，但也导致早晨开发同学都较疲倦，效率大幅降低。

2.DQC（数据质量监控）常触发：在做好全链路DQC保障后，夜间值班也会被无效/敏感DQC触发所影响休息，较多问题为数据质量波动触发，或者无效DQC不下线仍每天触发，导致夜间告警频发。

3.BUG工单较多：由于数仓在快速扩张期时忙于交付需求，从而对数据质量侧并未形成对应流程，同时由于开发者能力较弱或对业务不理解也会出现被投诉的情况。

数据质量治理识别

1.基线/SLA破线识别：基线可以通过基线运维去查看每日/近一周基线破线情况，每条基线周破线次数，夜间电话告警次数，起夜次数等判断基线情况，SLA破线可从与业务方对接，对数仓产出投诉去查看。

2. DQC及任务失败频出：DQC可以通过数据质量中心去查看每日/近一周情况，每DQC周破线次数，夜间电话告警次数，起夜次数等判断情况，SLA破线可从与业务方对接，对数据仓库产出投诉去查看。

3. 数据质量问题频出：可以从数据质量问题出发，找到任务经常出现数据质量问题对应的数仓同学或域负责人，定位触发问题细节。

数据质量治理流程

1. 基线告警问题拆解

对于基线治理很多同学都比较茫然，可能因为数据血缘链路长、也有可能不知道如何定位，语兴在这里给大家提供一些思路：

（1）产出延迟任务：确定破线/预警基线，通过数据表采集的元数据信息表通过数据血缘链路串起来，通过任务元数据找到告警基线任务中实际结束时间减开始运行最长的，即依赖部分晚产出（1-3小时运行时长）数据导致基线破线（包括倾斜任务、算法任务等），需要对这块任务调整或依赖t-2降低时效保障产出。

（2）链路过长导致产出延迟：找到所有表的输出输入点即启始ODS表（接入层）与末尾ADS表（应用层），ADS回溯到DWD（明细层）或ODS向下游依赖找问题，可能存在指标反复加工计算或者数据表反复依赖（ADS依赖ADS再依赖ADS导致）找到依赖问题原因，这里多数都是ADS指标反复依赖导致，需要对指标进行公共沉淀到DWS（轻度指标汇总），形成公共指标复用，或建设ADS核心指标/标签宽表，减少重复依赖问题。

（3）高优先级基线调度时间重叠：通过任务元数据梳理同时间运行的节点任务，根据当前资源消耗波动，把重叠基线调度时间提前，进行削峰填平，充分使用其他闲置时间资源。

（4）任务失败导致告警：通常是代码提交时缺乏审核流程导致任务匆忙上线（多半问题是没配依赖，元数据字段数与代码字段数不一致，生产环境未上线发布任务等情况），需要确定代码审核流程及模型评审机制，降低简单问题发生，同时也存在OOM情况，需要根据数据量等情况进行重分配。

（5）跨部门数据表依赖未产出告警：这种情况多出现在大厂跨部门合作出现问题，例如之前阿里与蚂蚁未断流情况下相互依赖导致基线破线，在这里高时效数据（强依赖t-1）需要拉齐夜间值班群，方便夜间及时值班沟通，对于非强依赖任务则临时取消依赖修改代码取最新分区（max_pt）。

（6）夜间值班培训/手册：前期未做这块准备的小组可以通过近1到2个月值班情况通过共享Excel去维护值班进度，找出常出现的问题，形成解决步骤，例如看到基线告警可以快速定位到预警原因，方便夜间值班同学能在夜间犯困情况下及时翻阅手册通过夜间值班培训处理好基线问题，降低出错效率。

2. DQC整治

DQC夜间经常触发，导致多次被吵醒，不一定是数据质量问题，可能是DQC太过敏感或无效DQC影响整体数据质量（尤其是强规则）。

基础DQC治理：可以从原来的表行数波动/主键唯一/主键不为空/表不为空作出裁剪优化，尤其是增量表表行数波动，变化较大，其次对于表行数波动经常会遇到多1%-5%的情况，数据范围评估起来也较为合理，但就因为设定不合理导致失败，DataWorks具备算法识别功能能够根据最近执行情况判断，使用线性回归15日DQC执行结果也可以智能识别。

业务DQC治理：对于长期未告警DQC可以采取下线，时常告警DQC，例如之前课程讲过的用户基础信息、业务流程数据丢失，同时也对这块数据配置了业务DQC，导致时常告警，此时需要暂停DQC，通过血缘进行数据丢失溯源，如果是源头数据问题需要一起修复。

对于指标异动数据DQC来说，如果是非核心指标监控可降为弱规则，对于核心指标需要向上游数据找寻原因，同时需要建设核心指标运营群，当有特殊情况出现（例如大促等）提前通知方便处置解决。