数据质量的问题影响业务是十分常见的,比如某个数据应用(报表A)的数据出现了异常,使用方就会因为出了异常不会使用,这样子会很影响业务的开展。一个好的数据服务应该是需要对这些质量问题有一个“预知”能力,简单来说就是需要先于业务知道问题,从而提前解决。
正所谓“知己知彼,百战不殆”,我们需要对数据质量进行控制,那么一开始就需要对数据质量做问题的归类,对症下药,根据郭忆老师的介绍总结,数据质量问题大致可以分为3大类。
这种情况真的是要爆炸的?,这是直接从源头上影响数据,那么涉及并且影响到的下游任务就很多很多了,这类业务系统变更导致的数据质量问题,也是可以大致归为2类。
这种错误其实是占比最多的,因为开发不规范、开发人员经验问题、开发进度问题等都会可能引起这类错误的发生,简单举几个栗子?:
这种情况发生的原因也是比较复杂,可能是因为业务暴增(比如双11、618)导致数据量增加,平时1小时后能跑完的数据可能得2小时,需要消耗更多的资源。也有可能是因为新上线的调度任务,写的SQL极其低效,从而占据大量的资源。
因为在多租户下,Hadoop 生态的大数据任务(MR,Hive,Spark)一般运行在 yarn 管理的多个队列上(调度器为 CapacityScheduluer),每个队列都是分配了一定大小的计算资源(CPU、内存),因此在有限的资源下就会出现抢资源的情况了。
面对数据质量问题,有两个基本原则,那就是“早发现、早恢复”,也就是早点发现数据的异常点,同时尽快能够恢复正常。下面有一些方法可以参考一下的:
这个很好理解了,就是通过预先设置好的一些规则来验证当前调度任务执行结果表的质量,如果触发规则就自动发送预警给到相关的开发人员。
这里,规则可以划分重要等级,不同登记的规则可以采取不同的预警方式和处理方式,比如重要规则的,就停止调度任务的执行(那么后续链路的任务就会处理等待状态,等到上游任务结束才执行),同时通知运维人员对当前任务进行处理(建议通过电话通知)。如果是一些不那么重要的规则,就可以通过短信或者推送的方式告知。
那么大家会问了,具体稽核指标该如何设计呢?大家可以从下面的3个维度去思考:
中台建设的目的就是抽象出可以公用的模型,这样子往往会有一个比较现实的问题,那就是数据加工的链路可能会很长,那么应用层上的指标出现问题了,排查问题也会比较困难了,所以我们需要对中台的数据模型的数据质量进行质量监控,也就是对链路中的表增加了一些稽核校验规则,如果结果数据出现问题,可以快速排查链路上的相关表的质量报告,快速定位到问题所在然后进行修复。
这个idea很棒!它其实就是通过分析过去任务运行的时间以及任务需要输出的时间节点,然后根据当前物理资源的情况,自动判断这个调度任务是否可以在规定的时间节点前完成计算,如果不行的话就发起预警,让开发人员暂停一些低级别的任务或者说对时效性不高的任务,释放资源给重要任务使用。
我们上面讲了这么多,其实都是建立在我们配置了完整的数据链路以及稽核规则之上的,万一一开始我们就没有配置这些东西呢?那么一切都是浮云了。
所以我们必须得设计一些规范化的管理制度,比如评审机制,从而确保依赖关系的完整配置,同时对稽核规则也要进行评审,确保规则的完备性。
07 | 如何统一管理纷繁杂乱的数据指标 —— 极客时间 · 郭忆