谈数据稽核(3)

在2013年4月时候，当时写过两篇谈 数据 稽核的 文章 ，具体地址在：

谈数据稽核1： http ://blog.sina.com.cn/s/blog_493a84550101edo2.html

谈数据稽核2： http://blog.sina.com.cn/s/blog_493a84550101een4.html

在前面谈这两篇文章的时候，对于数据稽核本身业务 需求 的出现场景和借助 大数据 平台下来实现数据稽核两点没有阐述的太清楚。这篇文章主要是对数据稽核本身业务需求已经在大数据技术辅助下数据稽核本身能力的提升两方面进一步进行阐述。

首先对于数据稽核出现的场景，最主要的可以理解为两个方面， 其一是同样一个基础数据或共享数据在多个业务系统中各自维护 ，出现数据不一致或者说无法映射的问题；其二是在我们数据集成的实现过程中，将同样一份数据分发和 同步 到多个业务系统中，同时由于数据集成本身出现问题，或者说 目标业务系统本身允许了对数据的CUD操作都会导致随着 时间 的变化同样的数据变来不一致 。

对于数据不一致或数据缺失带来的最大问题就是影响到跨多个IT系统的也流转。类似的场景有很多，类似项目信息从 项目管理 系统同步到采购系统后，可能发现项目类型本身不对导致无法根据项目下达采购订单。或者说一个完整的采购订单从采购系统同步到ERP的时候会发现因为ERP缺失了某个物料而同步失败。这些都直接影响到我们的业务协同，而我们往往经常的应对就是出了问题才通过IT系统手工从后台修复数据或者进行数据清理后重新导入或同步。对于做IT系统日常运维的可能就必须清楚，运维中本身硬件环境或 服务器 宕机的时候往往很少，而更多的时间都在手工后台修改数据，同步数据，解决数据不一致的问题。

前面一篇文章刚好谈到过我们经常的思维都是解决问题应该从源头抓起，类似数据不一致的问题应该严格的控制住数据源头并制定相关的数据 管理 和治理规范，但是实际的情况确是从根源上解决问题的方法看起来很完美，但是短期有诸多业务本身方面的原因而无法落地。

那么在彻底从根源解决问题和出了问题再手工解决之间就有一个更好的解决方案，即我们可以提前的发现数据不一致的问题并预警，而不是真正到了业务协同出现问题再去临时应急 。而一个优秀的数据稽核平台就是基于以上背景条件产生的。

一个最小化的数据稽核系统核心应该包括三个方面的内容， 其一是数据采集和存储，其二是规则引擎，其三是数据分析和展示 。而一个高效的数据稽核系统必须具备数据不一致的准实时预警能力，对于准实时的实现本身又包括了数据采集的准实时和数据分析的高效性能。

首先来谈下数据采集和存储 ，前面谈到过基于ETL技术来实现数据采集，在ETL方式下要实现数据本身的准实时采集是相当困难的。而真正可以考虑的方式则是类似数据实时复制和同步技术，对于 Oracle 数据库 我们可以采用Logminer实时捕获增量归档日志信息，对于My sql 数据库可以采用Binlog日志分析等。但是这里面一个重点就是需要对业务系统本身的DB数据库开放相关的权限和初始化 参数 ，能否推动业务系统去做这个调整本身存在困难。

采集回来的数据存储在哪里？常规做法是仍然存储在关系型数据库里面，那么我们可以想象下如果对于两张相关结构的有50个字段的数据库表。两张表如果都有1000万条数据，如果我们要比较出两张表存在的数据差异，对于这种大量的全部扫描和比对，性能本身是存在大问题的。

正是由于这个原因，我们可以考虑将采集来的数据直接导入到 HDFS 库里面，然后采用大数据分析方法和技术进行数据比对。而数据入到HDFS，当前的Sqoop组件是支持增量数据采集的，即可以通过我们制定的关键字段对源表数据进行增量采集。这种采集方式虽然比不上实时的数据同步复制，但是满足准实时性的要求基本不会有太大的问题。

其次，我们来谈下数据分析 ，对于这种数据稽核本身的数据量如果在大数据环境里面本身就是小数据了，你当然可以采用Hive进行数据比对分析，但是性能估计也很难好太多。更好的方法则是采用Spark进行相应的数据比对分析，由于Spark本身是基于内存计算的，对于这种量级在内存中进行不对分析是最合适不过的。 同时当前Spark本身就已经支持Spark Sql和Hive集成，也支持直接的JDBC集成等。这些都为数据比对分析上提供了相当的方便性。

还有一种设想就是是否可以将数据库的变更日志信息直接送到类似kafka的消息中间件中，采用通过spark和kafka的集成即可以实现类似数据采集的流处理和后续的内存计算分析，整个过程中由于数据本身不会二次落地都直接在内存中完成，整体性能的提升应该更大。

最后，谈下数据稽核平台里面另外一个重要的内容即规则引擎，规则引擎本身就是需要将数据稽核的各种校验方式和规则全部做到可 配置 化，即任何一个稽核流程都可以通过规则配置出来。比如我们需要检查三个业务系统中三张表数据的一致性，具体的检验规则是如何的，转换规则是如何的，当发现不一致的时候预警规则是如何的都需要做到灵活可配置。

可配置的数据稽核规则最终需要动态来生成数据稽核算法，或者说动态来生成稽核SQL语句等，这个也是整个稽核平台里面最难的部分 ，只有实现了该点整个数据稽核系统才谈得上是一个可以灵活可扩展的稽核平台。

对于数据稽核的结果，稽核平台本身应该提供上层分析报表能力，但是如果考虑到稽核结果的实时性，即数据稽核的结果应该可以通过消息发布订阅的方式向外部发布。只要订阅了某类数据稽核结果的订阅方，都可以实时的收集到最终的数据稽核结果信息。

将Spark和流处理，消息中间件，规则引擎等技术应用到数据稽核系统绝对不是大材小用，而是大数据技术能够更好的服务于传统业务系统，解决业务系统问题的重要尝试。即并不是我们的业务系统必须到了海量数据存储后才谈得上用大数据技术，而是在业务需求本身在实时性，效率，架构可扩展性等多个方面都可以采用大数据技术来解决真实业务场景下的业务问题。