最近負責的兩塊主要是統計報表，具體有差不多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產生的，他們對新系統還很陌生。子系統負責人當前的任務是保證自己負責的業務系統順利上線，他們每天都在客戶現場做測試做支持，管不到我這邊。項目組前期對統計查詢不夠重視，相關的工作沒有啟動，人員也一直沒有保證。是不是別的項目也是這樣對待查詢統計的？不知道別的大型的項目類似這種統計查詢系統后來是怎么開發的。希望有做過類似項目的高手給點指點。