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