谈数据稽核(2)

本篇谈下在大数据或海量数据处理技术在数据稽核整个解决方案中可能的应用场景。

对于数据采集和ETL部分

首先谈下数据采集部分，在这部分可以基于传统的ETL工具或模式来完成，对于非结构化文件或日志的采集可以通过Flume等分布式开源数据采集平台来完成。对于数据采集部分主要是数据采集和传输效率的提升问题。

对于数据采集，可以大家分布式的数据采集集群，如果对于单个ETL不拆分，那么可以对多个数据库，多个数据表的数据采集均衡的分配到多台数据采集和处理服务器上，实现数据的并行采集处理，加快数据的采集速度和降低IO瓶颈。对于实时采集方面，可以考虑直接采用类似BinLog日志采集模式，可以实时的采集到变更数据。对于ETL而言，首先对于数据的unLoad和Load过程，最好的方法就是采用适配数据库的原始批量数据文件导出和导入接口，例如Oracle的SqlLoader，Sybase和SqlServer数据库的BCP工具等，这种原生接口对于大数据批量导出性能最好，而且导出的文件还可以在ETL处理过程中进行压缩传输。

对于上亿条记录的大表，那么单个表的导出本身也是一个相当耗时的工作。在这里我们可以考虑对这种大型表进行行拆分和列拆分操作，将一个任务作业拆分为多个子任务，每个子任务在分配到集群中的多个节点机去运行，最好进行数据的汇总处理。在这块暂时没有做过具体的试验，无法预估实际的效果和性能提升情况。

对于ETL中的Transfer部分，在Oracle的ODI工具中我们看到，已经将ETL更多的转换为了ELT模式，即在数据采集完成后在目标端数据库再做具体的数据转换和处理等相关工作。在这种情况下将比传统的ETL方法获取到更高的性能。如果仍然是采用类似ELT模式的数据采集和处理，我们可以考虑将转换规则进行分步骤的拆解，将步骤分解到多台节点机器进行处理再进行最终结果的归并，类似MapReduce的并行计算模式。

总之，对于数据采集部分我们期望达到的就是并行采集，并行写入，同时在处理环节进行数据分流和数据转换。在传输过程中做好数据的压缩，提升数据采集和写入的性能和速度。

对于数据处理和分析部分

对于数据分析部分是两一个很重要的内容，在大数据总体解决方案中也经常谈到数据分析部分的性能问题。在这里有商用的GreenPulm，开源的Hive，也有针对MySQL数据库的开源Infobright等。在这里的几个重点是分布式数据库集群，内存数据库，列式数据库，MPP大规模并行处理，数据库DaaS层，数据查询任务分解和汇聚等关键词。对于数据分析部分最关心的还是在海量数据下面的查询效率问题。

对于数据稽核中存在基于某种规则的实时性的数据分析和一致性比对工作，而这种是典型的海量数据下实时查询和汇总统计过程。因此在我们对目标数据库的考虑上不再是简单的单数据库模式，而应该是一种支撑高性能和线性扩展的数据库集群模式，在这种模式下可以很好的解决数据查询的性能问题。

对于定时处理的数据稽核任务，也存在数据处理的效率问题，对于电信行业话单和计费结算数据的比对分析往往需要7，8个小时才能够完成。说明在数据处理过程中还有很多具体的性能提升点。包括数据稽核规则本身的分解，将稽核任务分配到多个节点去运行然后再进行数据的聚合。个人任务在数据稽核中的数据处理部分MapReduce有很多具体的用武之地，而我们更多的是需要考虑如何对MapReduce框架根据典型的数据稽核规则场景进行更好的二次封装，能够方便规则更加灵活的配置和调度。

对于实时数据分析和比对

对于这个有明确的需求场景，即实时采集数据并动态的监控数据差异化和比对情况。这个将是后续数据稽核平台的一个重要发展点。在这种场景下基本基于一种持续的不落地的数据流处理方式下。对于前面有文章谈到的实时流处理平台如S4和Storm等将有很好的借鉴意义。

实时流处理打破了传统的数据分析和处理的模式，即数据最终积累和落地后再针对海量数据进行拆分处理，然后进行分析统计，传统的模式很难真正达到实时性和速 度要求。而实时流处理模型的重点正是既有类似Hadoop中MapReduce和PIG一样的数据处理和调度引擎，由解决了直接通过输入适配接驳到流的入 口，流实时达到实时处理，实时进行分组汇聚等增量操作。

在这种模式下一个重点就是前面谈到过的对于数据稽核规则需要进行拆分，形成多个可以并行处理的PE任务，对实时达到的数据流进行处理，形成某种结果信息后再向后续节点推送，最终实时的监控和查询数据比对结果。这是一种实时动态监控的模式，对于在实时性要求高的数据质量监控中可以使用。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密