记一次架构设计的经验--数据质量监控

在工做中跟同事沟通很重要，有多重要呢，一个月前，领导给分派了一个工做：要作一套针对线上实时数据的质量监控。监控这种工做首先第一点也是最重要的一点要跟生产流程解耦，这个性质也间接的致使了这份工做优先级别无限降低，最后只有我一我的搞这个项目。

不知道有多少人有过一我的开发整个项目的过程，从零到一，从无到有，时间比较急，来不及用一些比较成熟可是复杂的开源框架，这种状况下只能针对需求敲代码开发。以前没有搞过监控类的项目，只能从网上找案例，找相关的文章，看看前辈们是怎么思考的怎么开发的。

当时浏览了一整个晚上网站，总结出要实现这个功能至少须要三步：1.数据收集；2.规则引擎；3.数据展现及报警

从功能上讲整个系统分为三类以后，就要开始设计你的表结构和文档了，这个过程就是我以前写的一篇架构那些事中的抽象过程了。抽象这个事情颇有意思，咱们不妨先一步一步把各方以及需求都写到一张纸上，发现他们的相同点与不一样点。

图1 数据的具体层级

上图是我根据数据性质以及业务方需求把每个变量做为一个单元，由数据来源将每个变量级的数据传过来，而后由我方存储。因此三张表油然而出，数据来源表，数据集表，变量表，具体每个变量是咱们应该对监控的对象，因此接下来的规则引擎类的表就要针对每个变量作文章了。

常见的数据质量规则是数据偏移，数据偏移就是咱们常见的psi公式了，将一个变量分多份，固然分的种类也不一样，通常常见的有等宽和等频。而后根据公式：

psi = sum(（实际占比-预期占比）* ln(实际占比/预期占比))开始计算psi值。计算psi值通常小于0.1属于很是稳定，在0.1与0.25之间属于正常，再大了就须要报警了，同时也能够把每个分区的预期比例和当前占比作一个比较，能够很好的显示出数据偏移方向，针对状况能够作出针对性的策略，举个简单的现实中的例子：若是一些注册用户的性别年龄区间相较于预期的比较大，这种状况下必须赶忙分析一下当前的推广活动啊等等的。

到如今为止设计工做数据收集模块和规则引擎模块已经有一个大致的印象了。提早剧透咱们的数据量很是大，一天的数据有接近一个T的大小，后期我会接着写第二篇，讲一下具体用到的技术框架和数据展现报警模块以及数据存储的设计。