数据治理-数据质量治理
前言
作为数据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来说,如果是非核心指标监控可降为弱规则,对于核心指标需要向上游数据找寻原因,同时需要建设核心指标运营群,当有特殊情况出现(例如大促等)提前通知方便处置解决。
3. 数据开发/校验流程重制定
需求评估:从接到需求开始进行评估,除了对接口径需求背景外,此时可以添加一道流程,即让业务阐述需求带来的价值和数据增长,从而判断需求要不要接,从源头降低无效需求出现。
模型设计:在接入需求后按照模型5要素(数据域、颗粒度、维度、度量、实时)完成数据模型设计,并进行需求模型评审(开个简单的会5分钟评审沟通)。
(1)设计是否满足5要素(颗粒度(买家 OR 卖家这种)清晰、主题域有划分、维度属性退化到模型、度量值是否合理(DWD存明细不做聚合操作)、全量增量是否有做区分)。
(2)内容是否添加插入数据日期及时间字段、内容是否将code转化、脱敏字段是否处理(看业务场景不一定要做)。
(3)表/字段命名是否按照规范来命名、字段属性是否按照规范、字段Comment是否清晰(要精确到内容 例如xxx_date Comment xxx日期类型(yyyy-mm-dd))。
(4)任务owner是否标清楚、模型对应业务过程是否描述清楚、颗粒度是否有描述、表使用说明是否添加(可不写)、表生命周期/存储格式是否按照标准、核心表是否有重点标注。
数据校验:重点一定是再次确认好业务口径
(1)通过平台工具或自测去看看数据分布情况最大值最小值空值也就是数据探查,这里可以通过SQL自查例如探查空选择where is null,通过数据比对平台或用开发环境数据表与线上环境对比检查是否数据膨胀等问题。
(2)采用抽样数据写从ODS 取出来逻辑与自己开发的抽样指标数据比对保障开发内容能对齐,从ODS 取数写SQL去关联清洗,通过算子加工与最后呈现指标去比对,但这里数据只能完成80%准确度,剩余20%需要与数据分析同学进行联调。
Code Review:除了代码合理性外,需要检查依赖、数据校验报告、任务在开发环境中运行情况是否超时等。
数据质量治理评估
这里更多是对于数仓内部价值,对外价值是数据问题更少发生,任务更稳定。
(1) 通过对基线/SLA治理,夜间值班培训及手册,保障核心任务按时产出,原每周3天不能准时产出降低至小于等于1天。
(2) 对DQC及任务治理系统化治理,实现自动化DQC识别,保障夜间值班同学起夜率降低至xx%。
(3) 通过对原有业务方提来的BUG找到共通性问题,重构数仓开发及校验流程,同时加强数仓团队数据质量理念,制定奖惩措施,数仓侧原有bug从每月40-50个,降低至每月小于7个。
数据质量治理思考
数据质量治理核心在于稳定数据交付,降低组内运维情况,更多在于业务数据资产扩张后遗留下来问题,除了如上保障手段,后续可借助AI对线上任务运行进行全面诊断、基线诊断,辅助数仓同学快速定位当前错综复杂问题。
#数据人的面试交流地##数据人offer决赛圈怎么选##数据开发工程师##数据分析##牛客创作赏金赛#