其他
所谓的数据质量
点击上方蓝色字体,选择“设为星标”
回复”资源“获取更多资源
将维度与业务需求相匹配,并且划分评估的先后顺序;
了解从每一维度的评估中能够/不能够得到什么;
在时间和资源有限的情况下,更好地定义和管理项目计划中的行动顺序。
唯一性(Uniqueness):用来描述数据是否存在重复记录,没有实体多余出现一次。
有效性(Validity):用来描述模型或数据是否满足用户定义的条件。通常从命名、数据类型、长度、值域、取值范围、内容规范等方面进行约束。
一致性(Consistency):用来描述同一信息主体在不同的数据集中信息属性是否相同,各实体、属性是否符合一致性约束关系。
准确性(Accuracy):用来描述数据是否与其对应的客观实体的特征相一致(需要一个确定的和可访问的权威参考源)。
及时性(Timeless):用来描述从业务发生到对应数据正确存储并可正常查看的时间间隔程度,也叫数据的延时时长,数据在及时性上应能尽可能贴合业务实际发生时点。
可信性(credibility):用来描述数据发生是否符合客观规律。每一规则维度可能需要不同的度量方法、时机和流程。这就导致了完成检核评估所需要的时间、金钱和人力资源会呈现出差异。数据数据质量的提升不是一蹴而就的,在清楚了解评估每一维度所需工作的情况下,选择那些当前较为迫切的检核维度和规则,从易到难、由浅入深的逐步推动数据质量的全面管理与提升。规则维度的初步评估结果是确定基线,其余评估则作为继续检测和信息改进的一部分,作为业务操作流程的一部分。
当然非空约束可以通过设置非空约束的方式限制数据无法写入数据库,如果支持这种方式可以避免事后的数据非空检查。
长度约束:描述检核对象的长度是否满足长度约束。如“金融机构编码”在《人民银行金融机构编码规范》中规定长度为14位,如果出现非14位的值,则判定为不满足长度约束,不是一个有效的“金融机构编码”;
内容规范约束:描述检核对象的值是否按照一定的要求和规范进行数据的录入与存储。如“存款账号”应仅含数字,如果出现字母或其他非法字符,则不是一个有效的“存款账号”,不满足内容规范约束;
取值范围约束:描述检核对象的取值是否在预定义的范围内。如“授信额度”取值范围应大于等于 0,如果出现小于 0 的情况,则超出了取值范围的约束,不是一个有效的“授信额度”;代码值域约束描述检核对象的值是否按照一定的要求和规范进行数据的录入与存储。
例 1 : 依业务规则性别只有 “0:男” ,”1:女”,则性别字段只应出现0或1。
例 2 : 货币代码 (CURCODE) 只应有RMB或是USD值。
数据质量中代码值域首先要指定企业级的统一编码表,然后按照对照关系进行 etl 转换,至于出报告只需要通过 sql 查询不再范围内的数值就可以了。长度约束描述检核对象的长度是否满足长度约束。
例如身份证号是 18 位。
长度约束可以通过建表时指定字符长度去限制,如果业务系统最初没有做限制,只能通过 sql 判断长度的方式获取异常值再进行处理。内容规范约束描述检核对象的值是否按照一定的要求和规范进行数据的录入与存储。
例如:余额或者日期等一般都会按照固定类型存储,如果最初设计为字符型后续应按照对应类型调整。
首先这种情况最好一开始就建立好统一规范,按照业务含义去指定技术类型。如果最初做的不好,可以通过类型进行数据探查,对数据统一格式化。取值范围约束描述检核对象的取值是否在预定义的范围内。
例如:余额不能为负数,日期不能为负数等等。
如果业务初始没有做限制,只能通过 sql 去对数据过滤查询,对有问题数据集中 etl 处理。
存在一致性依赖约束:描述检核对象之间数据值存在关系的约束规则。一个检核对象的数据值必须在另一个检核对象满足某一条件时存在。
逻辑一致性依赖约束:描述检核对象之间数据值逻辑关系的约束规则。一个检核对象上的数据值必须与另一个检核对象的数据值满足某种逻辑关系(如大于、小于等)。等值一致性依赖约束 一般指外键关联的场景。例如:保单表,理赔表的保单号存在保单主表,同一张表,两个字段之间的关联关系。存在一致性依赖约束 主要是强调业务的关联性,一个状态发生了则某个值一定会如何。
例如:投保状态为已投保,则投保日期不应为空;逻辑一致性依赖约束 主要强调的是字段间的互相约束关系。
例如:投保开始时间小于等于投保结束时间。
再如:国际保函业务的手续费应录入为国际担保手续费收入,却录入成国内担保手续费收入。
准确性要求不仅数据的取值范围和内容规范满足有效性的要求,其值也是客观真实世界的数据。由此可见,有效的数据未必是准确的,反之成立。
准确性通常需要业务人员或其他当事人手工核查。对待这种情况,数据质量规则没办法直接统一处理,只能通过即使查询的方式对数据结果进行详细核查。
例如:系统中贷款五级分类的分类比实际中的延迟几天变化;再如理财业务在理财系统中是成功状态,但在核心系统中却因通信的原因而没有入账。
及时性由于多个系统、通信等原因而造成,通常需要业务人员或系统人员手工核查。
一般来说数据同步都是基于业务系统的落表技术字段(比如:CREATE_DT),而真是业务发生的时间可能与该字段存在时间间隔。可以通过简单的sql对两个时间比较,判断数据的及时性是否符合需求。
例如:保单数据的每日分区数据较前日一般有 10% 增长,突然数据增长变为200%,这种情况有可能时数据同步出现问题。
再如:每月的营收总额一般都按一定规律上涨,突然数据波动较大则一般都可能出现问题。
可信性要求数据的总量波动符合基本客观规律,一般通过对 7,15,30 日数据进行比较,如果出现差距较大则进行详细的问题探查。