数据基建-数据质量
数据质量
概念:数据质量,意如其名,就是数据的准确性,他是数据仓库的基石,控制好数据质量,是做数据仓库基本要求,也使得下游业务方对数据用的放心
痛点:
数据问题该如何上报修复,缺少流程化。
数据链路缺少卡点保障。
数据不能及时产出影响到下游用数。
用户无感知,除了发现的数据问题,隐藏的数据问题仍存在。
疑问:
很多人会有一种想法,做了这么久的数仓为什么还存在质量问题?
数据质量保障措施
数据质量保障措施-全流程卡点总览
上线/变更规范
模型上线/变更流程
模型上线:设计模型-->组内模型评审-->代码编写-->提交运行(dev环境)-->代码审核数据校验(数据校验时需要给审核人提供数据比对结果)-->配置DQC-->数据初始化(线上环境)
模型变更(例如加字段):确定需求(了解需求背景)-->代码编写-->提交运行(dev环境)-->代码审核&数据校验(数据校验时需要给审核人提供数据比对结果)-->配置DQC(可省略,或添加业务dqc)-->数据初始化(线上环境)
指标变更:如果发现字段变更后对下游自己的表/报表产生影响,那自己负责修改代码并让其他同学进行代码审核、数据质量审核且任务运行成功后方可发布线上。如果下游血缘存在不是自己的表/报表,需要在相关业务群里说一下/找到下游表owner/报表owner发送通知,让下游owner进行修改,如联系不上需要向owner的leader说明问题,并且让下游表/报表的owner当天回复一下受不受影响,不回复则对方承担问题责任,如果对方不接受修改方案,需要双方约定一下修改内容、修改日期,重定方案
代码检验工具
平台化
手动验证(sql查询记录)
开源项目
数据质量监控(dqc)
DQC概念:dqc全称Data Quality Center,中文又称数据质量监控,用于监控表/字段数据的质量,防止问题数据流入下游任务,是数据仓库强有力的保障卡点,dqc触发于每个任务执行后
DQC平台展示
DQC种类
强规则可以中断任务的进行,将任务置于失败,并对任务负责人及值班人发送任务失败的消息(消息包括电话、邮件、短信、钉钉、飞书等)
弱规则不能中断任务的进行,只对任务负责人及值班人发送任务失败的消息(消息包括电话、邮件、短信、钉钉、飞书等)
DQC划分
基础dqc(每个表必加) :
主键唯一:联合主键、单主键
主键不为空
表行数波动
表不为空
业务dqc :
文本类:
字段不为空或空串
json中key不为空
字段是香脱敏
数值:
数值在区间范围
字段不能为0
枚举值
枚举值类型是香正常
枚举值波动
枚举值占比
日期
字段不为空
日期小于当天
数据基线及sla
数据基线概念(数仓内部):数据基线是指数仓内部对数据产出严格把控标准,当数据产出较晚(可能任务报错、强dqc拦截等因素导致),会通知对应的值班人及任务负责人解决任务保障底层数据按时产出,在布置基线时会配置基线告警时间
sla概念(下游业务方):sla是指数仓与业务方约定好的数据产出时间,像是与业务方"签字画押",能够按时为下游提供数据,当数据产出较晚(可能任务报错、强dqc拦截等因素导致),会通知对应的值班人及任务负责人解决任务保障底层数据按时产出,在布置基线时会配置基线告警时间
基线sla平台
基线sla等级
例如L1-L4,等级越低,基线分配资源越多
容灾备份快恢能力
痛点:核心任务产出不及时,以及值班同学及任务负责人夜间未起来,无法保障数据及时交付下游
解决办法:通常给下游临时任务切换为t-2数据,恢复整体任务进行,但数据资产、数据应用模型较多不能顾全还容易出现误操作情况,所以需要容灾备份任务还原所有数据资产,保障sla补破线能够及时交付
数据问题上报
痛点:下游缺少反馈数据问题渠道,也不清楚提出的问题是否解决,问题提出过于分散,需要平台管理整体流程
数据问题上报平台:
数据平台
需求平台:通过管理数仓需求方式来管理数据上报问题,业务方通过工单方式上报问题到数据仓库同学,数据仓库同学跟进,并记录问题跟进情况,使得双方相互了解,从而完成数据问题统一管理,统一解决
数据质量长期监测跟踪体系(面向下游)
痛点:数仓本身仍存在数据质量问题,解决了数据问题无法保障日后是否还出现此类数据问题产生,下游用户无法感知具体产生什么数据问题及问题具体明细
整体代码架构
流程:
1.现状梳理:对目前现有数据问题,存在隐患的问题进行收集归类,制作规则维表
2规则构建:将目前存在的数据问题按照每个规则进行模块化规则配置,为每个规则配置规则内容,包括规则类型、规则id/名、以及存在问题的字段/表等
3数据开发:建设相应dwd数据模型进行明细数据存放,并做维度退化,可按照规则种类开设二级业务域(模型为二级分区,分区1为ds(业务日期),分区2为rule (规则)),内容包括规则id规则名称,监控字段1-5,来源表,规则是否触发,规则是否加白,规则上线/变更/下线日期,规则状态,负责人等等
4数据应用:将数据明细插入最终报表数据模型中,最后通过报表的数据汇总呈现
数据质量监测门户
可与前端配合完成,或者低代码平台,或者数据可视化平台搭建
如何推动上下游开展数据质量活动
初期
早期未做平台时候,可以通过组建数据问题答疑大群方式,与业务方进行沟通,明确业务方数据问题痛点,同时也能解决群里业务方提出的问题,其次与下游交流明确产出保障,打好基础
成熟期
当平台完善后,要经常开设培训讲座,带着下游了解数据质量体系,明自该如何按照流程进行数据问题上报,解决,验收,保障大家维护同一个规则,其次要适当给予下游奖励,例如每月一次统计数据问题提出贡献及数据问题解决个数、程度,并通过这些考核为下游提供奖励,让下游有了参与感
数据质量保障如何量化产出
产出统计数据模型
问题发生数/率
问题解决数/率
问题复发数/率
周/月报告
数据问题趋势
数据问题分类
本期解决数
本期新增数
重点问题解决数
数据问题贡献榜
数据质量思考
全链路数据保障是整个数据仓库中的核心,好的数据质量基建要从需求分析->开发->提交/发布->应用,每一个流程都有相应的数据质量保障卡点,保障流程中每一步都不可缺失,如果大家都能遵守流程中每一步去执行,能降低线上问题产生频率,提升下游整体用数信心