统计查询开发的一点整理

统计查询开发的一点整理

  最近负责的两块主要是统计报表，具体有差不多400个报表需要开发。在开发过程中使用到了润乾的报表软件，也使用了润乾的OLAP组件，建立了一大堆的中间表，然后使用Oracle的ODI做定时任务晚上抽取数据到中间表，第二天提供给客户统计。也有一些比较复杂的业务没有办法使用ODI抽取，只能写成JAVA的方式晚上做批处理。批处理数据量都比较大，代码质量不高的话很容易内存溢出；ODI对开发人员的SQL语句要求较好，因为源数据可能需要经过很多处理，建立为VIEW然后才使用ODI抽取。如何提高SQL语句的效率是关键的问题，建立必要的索引，不断的优化SQL语句。但是，不管是批处理还是ODI都不是最麻烦的，最麻烦的是400张报表涉及到上千个数据项的分析工作。下面5个人，2个在做JAVA批处理，1个在做ODI，2个在做报表，不停的问我数据项，而我不是一个数据项仓库，N多不清楚的只有打电话给客户或者询问我们这边对应的子系统的负责人。而系统从原来的CS模式迁移过来的历史数据，质量很难保证，数据迁移工作存在很大的质量问题。很多数据项知道怎么查，但是一个SQL语句过去，查出来的数据差了十万八千里，客户那里肯干。总之，报表开发数据项麻烦，性能是大问题，对历史数据的报表更加困难。

  9月份公司安排不加班，我希望可以陆续整理点关于ODI开发的文档。感觉对ODI的使用还是比较深入，从最开始简单的抽取数据，到后来的定时任务，到现在修改KM进行简单的优化处理。对ODI的使用逐步深入，感觉Oracle的这个产品还是相当不错的。相对于我们使用的另外一个Oracle的产品BAM来说，这个产品买的是相当划算了。BAM我们也买了，但是最终定的技术方案还是没有使用。主要是支持太差劲了，网上也没有多少文档。那个产品在国内应该是使用的非常的少，上次BAM的产品经理来中国，说是来直接和BAM的客户面对面，了解客户的需求然后改进他们的产品。好像是一个USA，结果不知怎么Oracle这边安排到了我们公司来面对面。可是我们根本没有使用这个产品，公司领导没有人甩他，安排了几个人去和他一起开了个小座谈会。记忆最深的就是，老外讲了N久之后说要喝水，我马上给拿了开水一杯过来了。可是他摇头，后来和他一起来的美女告诉我，外国人说喝水都是要加点东西要么茶要么咖啡，不然就喝冷水。后来随便哪里抓了点茶叶丢了进去，那次算是我第一次和老外亲密接触。

  谈到BAM扯远了。在这个项目2年时间，先后参与了很多子系统。90%的系统都是业务系统，什么审查、审批、质检等等，典型的电子政务模式。业务系统做完了，剩下的这10%就是统计查询系统了。项目组90%的系统都差不多结了，而我手中这10%才刚刚开始，郁闷。手里有5个人在一起做统计查询这块的工作，但是面对这么大的项目，需要统计的数据项都是业务系统产生的数据，我们只能一边看PDM一边和客户、其他子系统负责人沟通。而客户以前的报表是基于原有系统产生的，或者是采用逐层上报加体外循环，利用VBA产生的，他们对新系统还很陌生。子系统负责人当前的任务是保证自己负责的业务系统顺利上线，他们每天都在客户现场做测试做支持，管不到我这边。项目组前期对统计查询不够重视，相关的工作没有启动，人员也一直没有保证。是不是别的项目也是这样对待查询统计的？不知道别的大型的项目类似这种统计查询系统后来是怎么开发的。希望有做过类似项目的高手给点指点。