数据质量规范
数据质量监控规范
一、前置知识
参考文章:https://blog.csdn.net/qq_41116027/article/details/124392530
数据质量的定义
数据质量:一个评估规则维度提供一种测量与管理信息和数据的方式;
数据质量就是通过一组维度来测量数据的方式。就如同判断东西的好坏和性价比一样,数据也有一些好坏的评判标准;
1、完整性
完整性(Completeness):用来描述信息的完整程度;
完整性:指的是数据信息是否存在缺失的状况,数据缺失的情况可能是整个数据记录缺失,也可能是数据中某个字段信息的记录缺失;
数据完整性问题包括:
- 模型设计不完整,例如:唯一性约束不完整、参照不完整;
- 数据条目不完整,例如:数据记录丢失或不可用;
- 数据属性不完整,例如:数据属性空值;
不完整的数据所能借鉴的价值就会大大降低,也是数据质量问题最为基础和常见的一类问题;
2、唯一性
唯一性(Uniqueness):用来描述数据是否存在重复记录;
比如真实成交 1 万条,但数据表有 3000 条重复了,成了 1.3 万条成交记录,这种数据不符合数据唯一性;
重复数据、冗余数据是导致业务无法协同、流程无法追溯的重要因素,也是数据治理需要解决的最基本的数据问题;
3、有效性
有效性(Validity): 用来描述模型或数据是否满足用户定义的条件(也称为数据规范性)。通常从命名、数据类型、长度、代码值域、取值范围、内容规范等方面进行约束;
代码值域约束:描述检核对象的代码值是否在对应的代码表内。如业务规则定义“性别”的取值应该是“1-男性”、“2-女性”、“3-未知的性别”,如果出现“A”、“B”这样的取值,则认为“性别”的代码值域存在问题;
长度约束:描述检核对象的长度是否满足长度约束。如交付中心编码的规定长度为6位,如果出现非6位的值,则判定为不满足长度约束,不是一个有效的交付中心编码;
内容规范约束:描述检核对象的值是否按照一定的要求和规范进行数据的录入与存储。如银行卡号应满足仅含数字的规范,根据银行不同,卡号位数也应该满足位数规范,如果与规范不匹配,则不是一个有效的银行卡号,不满足内容规范约束;
取值范围约束:描述检核对象的取值是否在预定义的范围内。如“授信额度”取值范围应大于等于 0,如果出现小于 0 的情况,则超出了取值范围的约束,不是一个有效的“授信额度”;
4、准确性
准确性(Accuracy):用来描述数据是否与其对应的客观实体的特征相一致(需要一个确定的和可访问的权威参考源);
数据准确性主要是指取值的准确性,描述该检核对象是否与其对应的客观实体的特征相一致。例如:用户的性别代码为 0-女性,虽然满足代码值域约束,但却不满足取值准确性约束,因为该用户性别代码与身份证解析为男性,或与其他权威性更高的判断不一致,其性别代码应为 1-男性;
准确性要求不仅数据的取值范围和内容规范满足有效性的要求,其值也是客观真实世界的数据。由此可见,有效的数据未必是准确的,反之成立。准确性通常需要业务人员或其他当事人手工核查;
对待这种情况,数据质量规则没办法直接统一处理,只能通过即使查询的方式对数据结果进行详细核查;
5、一致性
一致性(Consistency):用来描述同一信息主体在不同的数据集中信息属性是否相同,各实体、属性是否符合一致性约束关系;
数据质量的一致性主要体现在数据记录的规范和数据是否符合逻辑,一致性并不意味着数值上的绝对相同,而是数据收集、处理的方法和标准的一致。常见的一致性指标有:ID 重合度、属性一致、取值一致、采集方法一致、转化步骤一致;
等值一致性:一个检核对象数据取值必须与另一个或多个检核对象在一定规则下相等。一般指外键关联的场景。例如:支付订单表,订单表的支付订单号存在支付订单主表,同一张表,两个字段之间的关联关系;
存在一致性:一个检核对象的数据值必须在另一个检核对象满足某一条件时存在。主要是强调业务的关联性,一个状态发生了则某个值一定会如何。例如:订单状态为已开票或已交付,则开票时间或交付时间不应为空;
逻辑一致性:一个检核对象上的数据值必须与另一个检核对象的数据值满足某种逻辑关系(如大于、小于等)。 主要强调的是字段间的互相约束关系。例如:开票时间一定小于交付时间;
6、及时性
及时性(Timeless):用来描述从业务发生到对应数据正确存储并可正常查看的时间间隔程度,也叫数据的延时时长,数据在及时性上应能尽可能贴合业务实际发生时点;
数仓层面:由于不与业务有交互,仅提供数据支持。因此,及时性体现在数据支持快慢与否,即与承诺交付时间的延迟时长;
当然,如果业务方有相关的指标需求,可以通过数据同步到业务系统的落表技术字段(比如:CREATE_TIME),与真正的业务发生时间进行差值比较,来判断数据的及时性是否符合需求;
二、数据质量命名规范
主题域(数据域)_监控规则名称_监控周期_负责人
主题域(数据域):明确主监控对象的所属,用来做通知上下游以及数据质量统计,对数据治理工作进行评价;
- 1、主题域:主要是指标层面的监控,如DWS、ADS层,监控规则一般为:指标是否产出、某指标与其他指标之前的业务逻辑是否满足等;并且明确主题负责人,如有指标告警,及时通知下游负责人;
- 2、数据域:主要是监控明细层面,如ODS、DWD层,监控规则一般为:数据有无,主键是否重复,原始层与建模层主键是否有差异等,具体业务具体配置;并且明确数据负责人,如有上游数据问题,及时反馈上游负责人;
监控规则名称:一般命名为主监控指标名称或字段名称_监控规则,如累计发运⻋辆数_一致性(发运=库存+在途+交付数)、税务发票号码_唯一性等;
监控周期:与业务方确认,一般情况是以天为单位;
负责人:如果出现告警,可以直接找到数仓负责人,并跟进问题处理进度;
三、数据质量规则记录规范
1、记录内容
主题域OR数据域、数据源系统、监控任务名称、监控规则名称、监控指标、监控规则、预期结果、告警⽅式、异常处理机制、监控周期、上线⽇期;
2、记录形式:表格
| 主题域OR数据域 | 数据源系统 | 监控任务名称 | 监控规则名称 | 监控指标 | 监控规则 | 预期结果 | 告警⽅式 | 异常处理机制 | 监控周期 | 上线⽇期 |
|---|
3、记录内容描述和作用
主题域OR数据域:同上述数据质量命名规范;
数据源系统:用来记录数据的上游系统,如果出现告警,并且确认是上游数据问题,可直接找到系统以及对应负责人;
监控任务名称:一般与生成指标或数据的任务名称一致,用来关联任务;但尾部添加monitor后缀;
监控规则名称:同上述数据质量命名规范;
监控指标:该监控所包含的指标名称或字段中文名称(带表名,方便溯源);
监控规则:文字描述,例如发运=库存+在途+交付数,或者字段唯一性;
预期结果:用来判断监控结果是否满足预期;满足,不会触发报警;否则,触发报警;
告警⽅式:一般为钉钉或企微,也有电话方式;用来通知负责人处理问题,如果处理不及时,会用电话告警;
异常处理机制:一般为排查问题的流程;数仓问题,及时解决。上游问题,及时反馈到上游与下游以及项目经理或领导;
监控周期:同上述数据质量命名规范;
上线⽇期:即规则发布日期;
三、告警记录规范
1、记录内容
告警日期、监控规则名称、告警内容描述、处理结果、解决日期;
2、记录形式:表格
| 告警日期 | 监控规则名称 | 告警内容描述 | 处理结果 | 解决日期 |
|---|
3、记录内容描述与作用
告警日期:记录监控任务的告警日期,主要用来从BUG方面评价数仓好坏(仅计算数仓内部问题),还会计算告警时效,即从告警开始到告警解决的时间间隔,亦可以从问题解决时效方面评价数仓好坏;
监控规则名称:同上述数据质量命名规范,主要起到标识作用,找到具体负责人以及主题域OR数据域;
告警内容描述:描述具体告警内容、告警最终原因以及影响范围等信息;
处理结果:即从问题产生到问题解决之间的记录;如2022-10-21日,告警产生、反馈上游,等待结果,2022-10-22,了解问题处理进度,2022-10-23日,问题解决;
解决日期:最终问题解决的时间;部分用来计算数仓时效;

浙公网安备 33010602011771号