数仓-数据质量
文章内容参考：
数仓建设实践路线-第八讲-数据质量_哔哩哔哩_bilibili经过一段时间打磨开启全新篇章《数仓建设实践路线》，从0-1搭建数据体系，让大家更有体感，并将《数仓建设学习路线》课程内容落地。也欢迎大家可以私聊我加入我们社区，同时也有对应课件提供。, 视频播放量 3610、弹幕量 40、点赞数 94、投硬币枚数 54、收藏人数 208、转发人数 29, 视频作者 语兴呀, 作者简介 前阿里数据中台（数据技术及产品部）下数据研发，现网易数据KOL，与大家一起了解数仓体系建设。微信_yuxing，相关视频：数仓建设实践路线-第十五讲-人力资源业务数仓绩效域主题建设，数仓建设实践路线-第九讲-数据质量监测跟踪体系建设，数仓建设实践路线-第十二讲-数据治理，数仓建设学习路线-第九讲-数据资产2，数仓建设实践路线-第七讲-ADS晋升过程专题分析（独立且较大的项目），数仓建设实践路线-第十三讲-实时技术，数仓建设实践路线-第四讲-数据基建-DWD层建设（字幕版），数仓建设实践路线-第二讲-数仓标准，数仓建设学习路线-第十二讲-数仓评价，数仓建设学习路线-第四讲-数据质量
https://www.bilibili.com/video/BV1Uj411o7bW/?spm_id_from=333.999.0.0
目录
一、数据质量简介
1.1概念
1.2痛点
1.2.1 缺失开发规范化&对业务了解不足
1.2.2 缺少上线前保障
1.2.3 数据链路缺少质量卡点保障
1.2.4 数据不能及时产出影响到下游用数
1.2.5 数据问题上报缺少流程化机制
二、数据质量保障措施
2.1 模型及指标的上线/变更规范
2.1.1模型上线/变更流程
2.1.2指标变更规范
2.1.3 业务理解
2.2 数据上线前保障（代码检验）
2.2.1数据探查
2.2.2数据比对
2.3 数据质量监控DQC
2.3.1 dqc概念
2.3.2 dqc种类
强规则
弱规则
2.3.3 dqc划分
2.3.4 dqc处理
2.3.5 dqc告警
2.3.6 dqc平台
2.4 数据产出保障（基线&SLA）
2.4.1 数据基线
2.4.3 基线值班手册
2.5 容灾备份快恢能力
2.5.1 痛点
2.5.2 解决办法
2.6数据问题上报
2.6.1 痛点
2.6.2 概述
2.6.3 数据问题上报平台
2.7数据质量长期监测跟踪体系
2.7.1 痛点
2.7.2 整体架构
2.7.3 流程
三、如何推动上下游参与到数仓数据质量建设中
3.1 数仓建设初期
3.2 数仓建设成熟期
四、数据质量如何量化产出
4.1 产出统计数据模型
4.2 周/月报告
五、全链路的数据质量保障
5.1 数据质量保障措施-全流程卡点
5.2 个人思考
一、数据质量简介
1.1概念
数据质量是指数据的准确性，控制好数据质量是做数据仓库的基本要求，同时也能提升下游业务方对取数的放心。
1.2痛点
1.2.1 缺失开发规范化&对业务了解不足
业务前中期快速扩张，数仓需要覆盖更多场景应用，对业务理解浅显、未按照规范开发的问题一直存在。
1.2.2 缺少上线前保障
开发时没有对数据进行事先探查，添加字段后没对测试环境与线上环境的表结构比对，导致历史数据对不上。
1.2.3 数据链路缺少质量卡点保障
数据质量0保障建设，导致问题数据等传输至下游，对业务决策造成一定损失。
1.2.4 数据不能及时产出影响到下游用数
数据不能及时产出，下游的可视化大屏/看板/产品端无数据相应，影响到下游用数体验。
1.2.5 数据问题上报缺少流程化机制
对于数据问题，下游不知道通过什么渠道进行反馈，问题处理负责人、处理进度不可知。
二、数据质量保障措施
2.1 模型及指标的上线/变更规范
制定模型上线、模型变更、指标变更等规范解决开发未规范化问题，降低开发风险。
2.1.1模型上线/变更流程
-
模型上线规范
模型上线的流程：设计模型-->组内模型评审-->代码编写-->提交运行(dev环境进行试运行)-->代码审核数据校验-->配置DQC-->数据初始化
-
模型变更规范
例如下游风控、产品等要求新增一个字段、或者新开发一个模型，此时模型变更的基本流程是：确定需求(了解需求背景)-->代码编写-->提交运行(dev环境进行试运行)-->代码审核&数据校验->配置DQC-->数据初始化
2.1.2指标变更规范
如果字段变更后对下游自己负责的报表产生影响，修改代码并让其他同学进行代码审核、数据质量审核且任务运行成功后方可发布线上。如果不是自己负责的报表，给下游报表owner发送通知，如联系不上需要向owner的leader说明问题。
2.1.3 业务理解
- 需求理解及评审
数仓在接到需求后不能贸然去干，需要让业务方阐述需求背景、口径、这个需求能对业务带来什么价值？（帮助数仓从业务层面深入理解指标）。
通常参与需求评审的有数据产品、数据分析师、数仓以及业务方。针对业务方提出的需求，产品一般会考虑支撑该需求的底层数据目前是否在数仓存在，该需求是否有必要去做、任务优先级、任务排期？（并不是所有的需求都要做）
- 数据表理解
设计dwd模型表时需厘清业务库的核心业务流程， 每个流程下的数据表之间的关联关系。
2.2 数据上线前保障（代码检验）
通过平台工具或写sql自测的方式进行数据探查和数据比对
2.2.1数据探查
对表，字段，数据内容等进行全面摸查，表数据量、关键性字段（特指主键）的最大最小值/长度，空值占比；其余字段的最大最小值/长度、枚举值占比等。
2.2.2数据比对
代码上线前，对开发环境数据表（dev表）与线上环境（pro表）的进行比对，包括表数据量、表去重后数据量、字段总体/个别一致率等。
2.3 数据质量监控DQC
增强业务数据质量保障，提升数据监控覆盖度和准确度，减少线上问题发生。通过配置基础dqc和业务dqc等解决数据链路缺少卡点保障痛点，保障高质量数据向下输出。
2.3.1 dqc概念
dqc全称是Data Quality Center，中文称数据质量监控，用于监控表/字段数据的质量，防止问题数据流入下游任务，每个任务执行后，根据执行情况触发相应的dqc。平台上配置的dqc规则本质是SQL代码。
2.3.2 dqc种类
-
强规则
强规则可以中断任务的进行，将任务置于失败，并对任务负责人及值班人发送任务失败的消息（消息包括电话、邮件、短信、钉钉、飞书等）
-
弱规则
弱规则不能中断任务的进行，只对任务负责人及值班人发送任务失败的消息（消息包括电话、邮件、短信、钉钉、飞书等）
2.3.3 dqc划分
- 基础dqc
数仓每层（ods/dwd/dws/ads）表的核心字段都需要配置基础dqc，主要有以下四个维度：
唯一性校验：校验主键或联合主键唯一性
准确性校验：校验数据和客观实体特征是否相一致，关注数据的真实性，是否正确，是否存在异常值。校验内容包括表行数、表行数的1天波动率（与前一天对比）
完整性校验：校验数据的缺失程度。校验内容包括主键不为空值或null值
一致性校验：同一业务主体在不同的数据集中是否相同。
- 业务dqc
一般是数仓dws/ads表的核心字段配置业务dqc，保障指标产出的准确性、一致性等。
（1）文本类
字段不为空或空串、json字符串的中key不为空、敏感字段是否脱敏
（2）数值类
数值在区间范围、字段不为0
（3）枚举类
枚举值类型是否正常、枚举值波动、枚举值占比
（4）日期类
字段不为空
2.3.4 dqc处理
（1）以表行波动率为例（与前一天），如果是轻微波动，虽然定的阈值范围为0-20%，最终产出结果是21%，那也可以置为成功任务 ，dqc不会对任务进行拦截；
（2）以表行波动率为例（与前一天），如果是大波动，例如表行数为空，需要排查上游任务产出情况，可能是没做好依赖，需要等上游跑完再重跑任务；
（3）如果是重要字段为空或者主键不唯一、需要依据具体数据情况及时调整，例如通过group by去重或者临时填补；
2.3.5 dqc告警
dqc任务运行会触发相应的质检规则，检测出质量问题后，根据规则的强弱，采取不同的告警方式（邮件、钉钉等）去通知负责人进行修复处理。
2.3.6 dqc平台
如果购买的有商业平台，可以直接进行模板规则的配置，如下图：
如果没有购买商业平台，可以基于开源的dolphinscheduler（海豚调度）进行二次开发，ds工具有任务质量校验模块，基本的dqc功能是支持的。官网指路：https://dolphinscheduler.apache.org/zh-cn/docs/3.2.0
当然也可以自己写python脚本去调sql触发相应的dqc规则。
2.4 数据产出保障（基线&SLA）
建设各场景下的任务基线、通过设置SLA预警、SLA告警及值班手册等保障核心任务产出的及时性及稳定性，从而解决数据运维（基线破线）不及时痛点。
2.4.1 数据基线
数据基线是指数仓内部对数据产出严格把控标准，当数据产出较晚会通知对应的值班人及任务负责人解决。保障底层数据按时产出，在布置基线时会配置基线告警时间。
2.4.2 SLA
SLA是指数仓与下游约定好的数据产出时间，当数据产出较晚会通知对应的值班人及任务负责人解决。保障底层数据按时产出，在布置基线时会配置基线告警时间。
SLA破线：突破了时间节点，数据未能及时交付
SLA等级：例如L1-L4，等级越低，基线分配资源越多（核心的基线分配的资源一定是最多的）
SLA预警：一般ods -> dwd -> dws -> ads的etl核心任务都会配置到基线上。 当遇到任务报错、资源告警、任务超时等导致SLA即将破线的时候（破线：超出与业务方约定好的数据交付时间），提前xx小时进行预警（缓冲时间），通知负责人及时采取应对措施。
SLA告警：
SLA平台：
2.4.3 基线值班手册
通过wiki维护值班进度，找出常出现的问题，形成解决步骤，例如看到基线告警可以快速定位到预警原因，方便夜间值班同学能在夜间犯困情况下及时翻阅手册通过夜间值班培训处理好基线问题，降低出错频率。
2.5 容灾备份及快恢能力
2.5.1 痛点
核心任务产出不及时、值班同学及任务负责人夜间未起来，无法保障数据及时交付下游，数仓被下游投诉。
2.5.2 解决办法
兜底方案：将下游临时任务切换为t-2数据（将 t-2的数据回填到t-1）保障SLA不破线并能够及时交付。由于下游数据应用服务较多、容易出现误操作情况，所以需要事先备份任务、保障误操作后应用服务可还原之前的数据。（一般要求在半小时内完成快恢）
2.6数据问题上报
2.6.1 痛点
下游缺少反馈数据问题渠道，也不清楚提出的问题是否解决，问题过于分散，需要平台管理整体流程。
2.6.2 概述
上游数据源 ->数仓 -> 下游数分/算法。问题上报分为： 下游发现数仓数据有问题，上报无渠道，问题分散；数仓发现上游数据源的问题，反馈无渠道。
2.6.3 数据问题上报平台
通过问题上报平台方式对当前数据问题新进行跟踪记录、让下游、上游可以随时查阅问题处理进度。
如果没有平台，可以通过Wiki、飞书等管理数据上报问题，业务方/下游数分等通过工单方式将问题传递到数仓，数仓记录问题跟进情况，使得双方相互了解，从而完成数据问题统一管理归纳，对齐问题处理进度。
2.7数据质量长期监测跟踪体系
2.7.1 痛点
（1）上游经常出现数据质量问题，下游数据使用方对于隐藏的数据问题不得而知。通过建设数据质量长期监测跟踪体系，达到上游下游都有感知的效果。
（2）数仓修复了多少bug，完成了多少质量监控任务等，如果没有可视化工具，数仓内部对质量监控的实施水平无法把控，后期进行dqc迭代优化的时候，缺乏参照依据。另一方面，如果没有可视化的窗口，质量监控的量化成果不好呈现给下游。
（3）有些业务方对数据链路并不了解，源头数据问题很容易让数仓背锅，建设质量跟踪体系，将上下游都参与到数仓数据质量保障中。
2.7.2 整体架构
监测白名单表：对表/字段配置了质量规则，后期质量问题已经解决，那对该表进行加白处理。将规则逻辑落成对应的规则维表，例如rule001。
2.7.3 流程
- 数据质量现状梳理：对目前现有数据问题，存在隐患的问题进行收集归类
- 质量规则维表构建：将目前存在的数据问题按照每个规则进行模块化规则配置，为每个规则配置规则内容，包括规则类型、规则id/名、以及存在问题的字段/表，规则严重程度等。
- 规则模型设计：建表存放质量规则校验结果数据，例如DDL建表语句：
CREATE TABLE `ads`.`ads_dq_rule_target_d`(
`rule_id` string COMMENT '规则id',
`rule_name` string COMMENT '规则名',
`rule_start_date` string COMMENT '规则开始日期',
`rule_end_date` string COMMENT '规则结束日期',
`rule_state` string COMMENT '规则状态',
`rule_end_reason` string COMMENT '规则下线理由',
`rule_cnt` bigint COMMENT '扫描基数',
`rule_trigger_cnt` bigint COMMENT '规则命中数',
`rule_trigger_null_cnt` bigint COMMENT '规则为空命中数',
`rule_trigger_business_cnt` bigint COMMENT '规则业务情况命中数',
`rule_unmonitored_cnt` bigint COMMENT '规则无需监控数',
`rule_unrepair_cnt` bigint COMMENT '规则无法修复数')
COMMENT 'ads层-数据质量监控规则相关指标'
PARTITIONED BY (
`ds` string COMMENT '业务日期')- 数据质量监测可视化：将规则校验的落到olap，对接bi看板进行可视化呈现。
三、如何推动上下游参与到数仓数据质量建设中
3.1 数仓建设初期
早期未做平台时候，可以建立数据问题答疑群与业务方进行沟通，明确业务方数据问题痛点，其次与下游明确产出保障，打好基础。
3.2 数仓建设成熟期
当平台完善后，可以给下游培训数据问题上报，解决，验收的流程、保障大家遵守一套流程规范。其次可通过每月统计数据问题反馈及解决的top榜单，适当为下游提供奖励，让其积极参与到数仓数据质量保障工作中。
四、数据质量如何量化产出
4.1 产出统计数据模型
- 问题发生数/率
- 问题解决数/率
- 问题复发数/率
4.2 周/月报告
将质检报表信息通过邮件发送至相关部门，让下游用数方及leader看到数仓数据质量的产出结果，提高对数仓价值的认可。
- 数据问题趋势
- 数据问题分类
- 本期解决数
- 本期新增数
- 重点问题解决数
- 数据问题贡献榜
五、全链路的数据质量保障
5.1 数据质量保障措施-全流程卡点
开发上线流程及变更机制-->数据质量监控dqc --> 任务基线及sla -->容灾备份及快恢能力 --> 数据质量问题上报 --> 数据质量长期跟踪监测体系（及可视化）
5.2 个人思考
全链路数据保障是整个数据仓库中的核心，需求分析->开发->提交/发布->应用，每一个流程都要有相应的数据质量保障卡点，从而降低线上问题发生的频率，提升下游整体用数信心。