【数据中台】数据质量稽查的一些思考

1. 数据质量的重要性

在日常工作中，我们经常会遇到各种数据问题。往往大项目会有专人去做持续的数据治理工作，而体量较小的项目其实也可以做一些轻数据治理-数据质量监控工作。

数据最终是要服务于业务价值的，那么保证数据质量一定是数据分析和数据挖掘结论有效性和准确性的基础，也是数据驱动决策的前提。

数据质量，主要从四个方面进行评估，即完整性、准确性、一致性和及时性。

1. 完整性：指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。简单来讲，如果要做监控，需要考虑两个方面：一是，数据条数是否少了，二是，某些字段的取值是否缺失。完整性的监控，多出现在日志级别的监控上，一般会在数据接入的时候来做数据完整性校验。

2. 准确性：指数据中记录的信息和数据是否准确，是否存在异常或者错误信息。一般准确性的监控多集中在对业务结果数据的监控，比如每周的来电量等。需要注意的是，数据准确性是建立在合理的业务口径下，从口径角度去统一才会获得准确的结果。而不是仅仅认为从某个面去看这个数据是准确的就要做统一，不应从数据去逆推口径。

3. 一致性：指同一指标在不同地方的结果是否一致，数据不一致的情况，多出现在数据系统达到一定的复杂度后，同一指标会在多处进行计算，由于计算口径或者开发人员的不同，容易造成同一指标出现的不同的结果。

4. 及时性：分离线与实时，离线方面主要考虑数据计算出来的速度是否够快，监控可以体现在监控结果数据数据是否在指定时间点前计算完成。实时方面还需考虑数据是准时的，还是过时无效的。

2. 从技术的角度看数据问题

数据质量监控之所以难做，主要是因为在数据的各个环节都会出现数据质量的问题。

拿离线数仓举一个例子，将整个数据流程分为三个阶段：

• 数据入库
• 数据清洗加工
• 数据成果

1. 数据入库阶段，最容易出问题的就是完整性问题。一方面要特别注意数量是否陡增和陡降，另一方面，也要检查不同字段的的取值是否有丢失，比如来电时间和手机号字段是否出现大量空值等异常。
2. 数据清洗加工阶段，数据清洗的范围局限在数据仓库的中间层（dwd至dws层）。在这一环节，最容易出现的是数据一致性和数据准确性的问题。数据中间层保障来数据是从统一出口而出，让数据一起对或者一起错。但是很难保证数据准确性的问题，因此在数据清洗阶段需要尽量保障数据的准确性。
3. 数据成果阶段，主要是强调对外提供数据的过程，一般是从中间表中计算或直接取得的可展示数据。这里是业务方和老板最容易感知的到的地方，因此在这环节，主要关注的是数据准确性和数据及时性。

但由于数据质量问题是一个持续治理的问题，又因为数据在各个阶段都会出现问题，所以治理工作可以先从几个主要的核心问题出发（如具体到指标口径，核心字段）解决问题。

3. 如何实现数据质量监控

首先识别出业务核心数据，公司内外部的数据有很多，如果全部监控的话就会很浪费资源，所以首先需要筛选出对运营、服务、监管等应用场景成败与否最至关重要的数据。

那如何识别出核心业务数据呢？
第一步：业务专家提出候选核心数据
业务专家为数据专家解释业务过程中的商业逻辑，阐明该业务的输入和输出数据都有哪些。
第二步：业务评价标准为数据元素评分
进一步的筛选就需要一个可以量化的科学体系，将标准的重要性得分和数据对于该标准的得分两两相乘再求和，便得到每个元素的总分，并根据这个总分把它们从高到低排序。

标准权重	10	7	4	7
评价标准	标准1	标准2	标准3	标准4	总分
字段1	4	10	7	7	187
字段2	7	10	4	7	205

第三步：进行相关性分析，进一步精简核心数据元素
采用相关性分析,检查多个数据数据元素之间的相关性。这是因为如果两个元素的相关性非常高，那么我们只监测其中一个即可。

第四步：通过信噪比分析，确定最终核心数据元素名单
根据信噪比的定义说明信噪比低的 CDE 有更大的波动性。数据的波动性往往说明产生这个数据的业务过程有更大的不确定性、因此需要实时的监控。

接下来就是数据质量监测，简单做的话，可以写一些定时脚本，扫表出数据质量报告即可。

举例一些比较常用的监控内容：

1. 数据落地监控
2. 数据掉0监控：实际扩展一下就是数据量阈值监控，少于某个量就告警
3. 重复数据监控：很多表一定要监控重复数据的，这点至关重要。
4. 数据量、指标值同比环比监控
5. 重要枚值字段的离散值监控
6. 业务规则监控
7. 重要字段的非空监控
8. 数据对账：体现到实时数据上，特别是Kafka数据落地，必须要有一个监控机制来知道我们的数据落地情况，离线数据同样需要数据对账，比如可以和业务库来对比

可以利用hql，spark做一个规则引擎，上面提到的都做到规则里面，哪个表需要了就配一下就行了。

4. 会遇到的挑战

假设你的结果表要经过多层的中间表计算，你怎么保证每个环节都是正确的，且最终结果是正确的？

从两个点考虑：

1. 每一层代码有 Code Review，保证代码逻辑正常。
2. 单独一条计算流，对关键指标从原始数据直接计算结果，和日常的结果表做对比，发现不同则告警。这种方式也可以理解为是结果数据和源数据的对账。

5. 实现方案

可以分为物理表级与字段级稽查方案。

5.1 物理表级

1. 表数据量监控
   一张表的记录数在一个已知的范围内，或者上下浮动不会超过某个阈值

• SQL结果：var 数据量 = count（“昨天”（如果设置了时间字段的话）满足“过滤条件”的记录）
• 数值检测：如果数据量不在[数值下限, 数值上限]， 则触发报警
• 同比增加：如果((今天的数据量 - 上周的数据量)/上周的数据量*100)不在 [比例下线，比例上限]，则触发报警
• 环比增加：如果((今天的数据量 - 昨天的数据量)/昨天的数据量*100)不在 [比例下线，比例上限]，则触发报警
• “阈值配置”的六个数值当中，至少配置一个阈值. 对于没有配置的阈值，不做监控

2. 跨表数据量对比
   主要针对同步流程与数仓各层级之间，监控两张表的数据量是否一致

• SQL结果：count(本表) - count(关联表)
• 阈值配置与“5.2.1中的空值检测”相同

5.2 字段级

1. 字段空值数量检测
   某个字段为空的记录数在一个范围内，或者占总量的百分比在某个阈值范围内

• 目标字段：选择要监控的字段，不能选“无”
• SQL结果：var 异常数据量 = count（"目标字段"为空的记录）
• 单次检测：如果(异常数据量)不在[数值下限, 数值上限]，则触发报警

2. 字段值域检测
   某个字段的值在一个范围内

• 目标字段：选择要监控的字段，一般为关键业务指标字段
• SQL结果：var 异常数据量 = count（"目标字段"为不在值域范围内的记录，可根据case when 打标计数统计）
• 单次检测：如果(异常数据量)不在[数值下限, 数值上限]，则触发报警

3. 字段重复值检测
   一个或多个字段是否满足某些规则

• 目标字段：选择要监控的字段，group by 这里的字段列表后，没有重复
• 单次检测：如果(异常数据量)不在[数值下限, 数值上限]， 则触发报警