???? 目录
数据质量问题的剖析
针对质量问题的锦囊
数据质量的问题影响业务是十分常见的，比如某个数据应用（报表A）的数据出现了异常，使用方就会因为出了异常不会使用，这样子会很影响业务的开展。一个好的数据服务应该是需要对这些质量问题有一个“预知”能力，简单来说就是需要先于业务知道问题，从而提前解决。
???? 数据质量问题的剖析
正所谓“知己知彼，百战不殆”，我们需要对数据质量进行控制，那么一开始就需要对数据质量做问题的归类，对症下药，根据郭忆老师的介绍总结，数据质量问题大致可以分为3大类。
业务系统变更
数据开发BUG
物理资源不足
01 ???? 业务系统变更
这种情况真的是要爆炸的????，这是直接从源头上影响数据，那么涉及并且影响到的下游任务就很多很多了，这类业务系统变更导致的数据质量问题，也是可以大致归为2类。
源系统数据库表结构变更：因为有些时候业务数据库的运维开发人员会因为业务调整或者是版本迭代优化直接修改了库表结构，比如新增一个字段，删除一个字段，又或者是修改字段的枚举值、数据类型等，而这些操作又没有及时通知数据开发部门，从而导致数据同步任务或者ETL任务出现异常，从而影响所有下游的任务。
源系统环境变更： 这种情况也是很常见的，有的时候数据不断累积，小数据还好，万一是大数据（比如日志类），可能就会对服务器进行扩容，那么就会新增服务器了，数据就会被存储在新旧服务器上，但是以前配置的数据同步任务，就不包含新服务器的日志同步任务，虽然不会报错，但是数据就不完整了，也就出数据质量问题了。
02 ☠️ 数据开发BUG
这种错误其实是占比最多的，因为开发不规范、开发人员经验问题、开发进度问题等都会可能引起这类错误的发生，简单举几个栗子????：
开发过程中错误删除了正式库的表，导致相关下游任务出错；
任务正式发布上线的时候，代码里的测试库没有及时修改为正式库，导致测试数据被加载到生存数据中了(污染线上数据)；
开发没有考虑更多的异常情况并对其做相关的处理，导致生产中实际出现问题的时候直接报错；
任务配置异常，它通常表现在任务没有配置依赖，前一个任务没有运行完，后一个任务就开始运行，输入数据不完整，导致下游数据产出错误。
03 ???? 物理资源不足
这种情况发生的原因也是比较复杂，可能是因为业务暴增（比如双11、618）导致数据量增加，平时1小时后能跑完的数据可能得2小时，需要消耗更多的资源。也有可能是因为新上线的调度任务，写的SQL极其低效，从而占据大量的资源。
因为在多租户下，Hadoop 生态的大数据任务（MR，Hive，Spark）一般运行在 yarn 管理的多个队列上（调度器为 CapacityScheduluer），每个队列都是分配了一定大小的计算资源（CPU、内存），因此在有限的资源下就会出现抢资源的情况了。
✍️ 针对质量问题的锦囊
面对数据质量问题，有两个基本原则，那就是“早发现、早恢复”，也就是早点发现数据的异常点，同时尽快能够恢复正常。下面有一些方法可以参考一下的：
???? 锦囊1：添加稽核校验任务
这个很好理解了，就是通过预先设置好的一些规则来验证当前调度任务执行结果表的质量，如果触发规则就自动发送预警给到相关的开发人员。
这里，规则可以划分重要等级，不同登记的规则可以采取不同的预警方式和处理方式，比如重要规则的，就停止调度任务的执行（那么后续链路的任务就会处理等待状态，等到上游任务结束才执行），同时通知运维人员对当前任务进行处理（建议通过电话通知）。如果是一些不那么重要的规则，就可以通过短信或者推送的方式告知。
那么大家会问了，具体稽核指标该如何设计呢？大家可以从下面的3个维度去思考：
完整性规则：主要就是确保我们的数据记录数是完整的，不出现因为上游出bug而导致数据记录的变化很大的情况。常见的稽核规则可以有对数据表的数据量的绝对值监控和波动率监控，另外就是主键唯一性监控，判断数据是否有重复的情况，也有对字段级别的监控，比如某个重要字段空值占比和0值占比。
-
一致性规则：就是有些指标是通过模型中的两个指标进行计算而出的，所以结果应该是一致的。举个栗子：
商品购买率是通过商品购买用户数除以商品访问 uv 计算而来的，如果在不同的模型中，商品购买用户数是 1W、商品访问 uv10W，商品购买率 20%，那这三个指标就存在不一致。
准确性规则：主要解决数据记录正确性的问题。常见的稽核规则有，一个商品只能归属在一个类目，数据格式是不是正确的 IP 格式，订单的下单日期是还没有发生的日期等等。
???? 锦囊2：建立全链路的监控
中台建设的目的就是抽象出可以公用的模型，这样子往往会有一个比较现实的问题，那就是数据加工的链路可能会很长，那么应用层上的指标出现问题了，排查问题也会比较困难了，所以我们需要对中台的数据模型的数据质量进行质量监控，也就是对链路中的表增加了一些稽核校验规则，如果结果数据出现问题，可以快速排查链路上的相关表的质量报告，快速定位到问题所在然后进行修复。
???? 锦囊3：智能预警功能
这个idea很棒！它其实就是通过分析过去任务运行的时间以及任务需要输出的时间节点，然后根据当前物理资源的情况，自动判断这个调度任务是否可以在规定的时间节点前完成计算，如果不行的话就发起预警，让开发人员暂停一些低级别的任务或者说对时效性不高的任务，释放资源给重要任务使用。
???? 锦囊4：规范化管理制度
我们上面讲了这么多，其实都是建立在我们配置了完整的数据链路以及稽核规则之上的，万一一开始我们就没有配置这些东西呢？那么一切都是浮云了。
所以我们必须得设计一些规范化的管理制度，比如评审机制，从而确保依赖关系的完整配置，同时对稽核规则也要进行评审，确保规则的完备性。
???? Reference
07 | 如何统一管理纷繁杂乱的数据指标 —— 极客时间 · 郭忆