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

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

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

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

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

图1 数据的具体层级

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

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

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

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