（学习笔记）数据基建-数据质量

数据质量

概念：数据质量，意如其名，就是数据的准确性，他是数据仓库的基石，控制好数据质量，是做数据仓库基本要求，也使得下游业务方对数据用的放心

痛点：
数据问题该如何上报修复，缺少流程化。
数据链路缺少卡点保障。
数据不能及时产出影响到下游用数。
用户无感知，除了发现的数据问题，隐藏的数据问题仍存在。

疑问：
很多人会有一种想法，做了这么久的数仓为什么还存在质量问题?

数据质量保障措施

数据质量保障措施-全流程卡点总览

上线/变更规范
模型上线/变更流程

模型上线：设计模型–>组内模型评审–>代码编写–>提交运行(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数据应用:将数据明细插入最终报表数据模型中，最后通过报表的数据汇总呈现

数据质量监测门户

可与前端配合完成，或者低代码平台，或者数据可视化平台搭建

如何推动上下游开展数据质量活动

初期
早期未做平台时候，可以通过组建数据问题答疑大群方式，与业务方进行沟通，明确业务方数据问题痛点，同时也能解决群里业务方提出的问题，其次与下游交流明确产出保障，打好基础

成熟期
当平台完善后，要经常开设培训讲座，带着下游了解数据质量体系，明自该如何按照流程进行数据问题上报，解决，验收，保障大家维护同一个规则，其次要适当给予下游奖励，例如每月一次统计数据问题提出贡献及数据问题解决个数、程度，并通过这些考核为下游提供奖励，让下游有了参与感

数据质量保障如何量化产出

产出统计数据模型
问题发生数/率
问题解决数/率
问题复发数/率

周/月报告
数据问题趋势
数据问题分类
本期解决数
本期新增数
重点问题解决数
数据问题贡献榜

数据质量思考

全链路数据保障是整个数据仓库中的核心，好的数据质量基建要从需求分析->开发->提交/发布->应用，每一个流程都有相应的数据质量保障卡点，保障流程中每一步都不可缺失，如果大家都能遵守流程中每一步去执行，能降低线上问题产生频率，提升下游整体用数信心

全链路数据质量保障项目