以前做过一个数据质量的项目，但是我对当初的数据资料项目是抱有怀疑的。
当初的项目只支持对数据进行SQL检查。但是我不确定通过SQL检查可以满足哪些实际的业务需求，也可以说当初的平台实际上是与实际业务是脱离的。
另一方面，我也看了一些业绩方面关于数据质量的说明，除了异常值的检查之外，还有数据分布等情况。通过数据分布的异常，也可以发现一些潜在的趋势性问题。
最近又接触到了一些客户提出的程序故障，我发现客户对于功能上的问题提议较少，并且也不会觉得功能的问题是着严重的问题。
更多被客户关注的是数据上的问题，也就是业务数据上的差异。例如合同签完毕之后，金额却大于一个历史的值，这违反了在采购业务当中，同一物料的价格不能高于历史价格的规范。
但是在程序当中已经是加以约束，但是由于程序流程过程过长，不确定哪个环节出现了问题造成异常数据。如果等到客户发现数据之后再投诉，作为IT部门就非常的被动。所以我想直接从数据质量入手，对于数据进行定期检查，在客户投诉之前发现数据质量问题，这样就可以在客户投诉之前完成问题的修复。至于产生的根本原因再慢慢的去解决。
从这些问题中，我发现可以根据客户的业务规则，制定出后台对应的数据质量检查规则，并且定时进行运行与检查。例如数据一致性方面，在a系统的合同值和在B系统的合同值理论上要一致。如果不一致就会造成后期所有业务的偏差。
还有就是客户在报价的时候，每一轮新的报价要低于上一轮报价，不管什么原因，一旦出现了数据异常，只会对企业的采购业务产生重大的影响。
基于以上业务领域当中显而易见的数据异常，可以建立对应的数据检查规范，但是不限于SQL语句。毕竟实际业务场景当中有很多是通过SQL就无法实现了。
最后就是选型，我发现现在单纯的数据质量产品很少，大部分都是依据现有的数据处理平台上进行的一些场景化配置。所以我找了一个和数据处理相关的平台，在上面进行一些数据的读取数据的检查，数据的校验以及告警的相关工作。
目前先这样，后续看看持续的效果。
网友评论