最近負(fù)責(zé)的兩塊主要是統(tǒng)計報表，具體有差不多400個報表需要開發(fā)。在開發(fā)過程中使用到了潤乾的報表軟件，也使用了潤乾的OLAP組件，建立了一大堆的中間表，然后使用Oracle的ODI做定時任務(wù)晚上抽取數(shù)據(jù)到中間表，第二天提供給客戶統(tǒng)計。也有一些比較復(fù)雜的業(yè)務(wù)沒有辦法使用ODI抽取，只能寫成JAVA的方式晚上做批處理。批處理數(shù)據(jù)量都比較大，代碼質(zhì)量不高的話很容易內(nèi)存溢出；ODI對開發(fā)人員的SQL語句要求較好，因為源數(shù)據(jù)可能需要經(jīng)過很多處理，建立為VIEW然后才使用ODI抽取。如何提高SQL語句的效率是關(guān)鍵的問題，建立必要的索引，不斷的優(yōu)化SQL語句。但是，不管是批處理還是ODI都不是最麻煩的，最麻煩的是400張報表涉及到上千個數(shù)據(jù)項的分析工作。下面5個人，2個在做JAVA批處理，1個在做ODI，2個在做報表，不停的問我數(shù)據(jù)項，而我不是一個數(shù)據(jù)項倉庫，N多不清楚的只有打電話給客戶或者詢問我們這邊對應(yīng)的子系統(tǒng)的負(fù)責(zé)人。而系統(tǒng)從原來的CS模式遷移過來的歷史數(shù)據(jù)，質(zhì)量很難保證，數(shù)據(jù)遷移工作存在很大的質(zhì)量問題。很多數(shù)據(jù)項知道怎么查，但是一個SQL語句過去，查出來的數(shù)據(jù)差了十萬八千里，客戶那里肯干。總之，報表開發(fā)數(shù)據(jù)項麻煩，性能是大問題，對歷史數(shù)據(jù)的報表更加困難。
9月份公司安排不加班，我希望可以陸續(xù)整理點關(guān)于ODI開發(fā)的文檔。感覺對ODI的使用還是比較深入，從最開始簡單的抽取數(shù)據(jù)，到后來的定時任務(wù)，到現(xiàn)在修改KM進行簡單的優(yōu)化處理。對ODI的使用逐步深入，感覺Oracle的這個產(chǎn)品還是相當(dāng)不錯的。相對于我們使用的另外一個Oracle的產(chǎn)品BAM來說，這個產(chǎn)品買的是相當(dāng)劃算了。BAM我們也買了，但是最終定的技術(shù)方案還是沒有使用。主要是支持太差勁了，網(wǎng)上也沒有多少文檔。那個產(chǎn)品在國內(nèi)應(yīng)該是使用的非常的少，上次BAM的產(chǎn)品經(jīng)理來中國，說是來直接和BAM的客戶面對面，了解客戶的需求然后改進他們的產(chǎn)品。好像是一個USA，結(jié)果不知怎么Oracle這邊安排到了我們公司來面對面。可是我們根本沒有使用這個產(chǎn)品，公司領(lǐng)導(dǎo)沒有人甩他，安排了幾個人去和他一起開了個小座談會。記憶最深的就是，老外講了N久之后說要喝水，我馬上給拿了開水一杯過來了。可是他搖頭，后來和他一起來的美女告訴我，外國人說喝水都是要加點東西要么茶要么咖啡，不然就喝冷水。后來隨便哪里抓了點茶葉丟了進去，那次算是我第一次和老外親密接觸。
談到BAM扯遠(yuǎn)了。在這個項目2年時間，先后參與了很多子系統(tǒng)。90%的系統(tǒng)都是業(yè)務(wù)系統(tǒng)，什么審查、審批、質(zhì)檢等等，典型的電子政務(wù)模式。業(yè)務(wù)系統(tǒng)做完了，剩下的這10%就是統(tǒng)計查詢系統(tǒng)了。項目組90%的系統(tǒng)都差不多結(jié)了，而我手中這10%才剛剛開始，郁悶。手里有5個人在一起做統(tǒng)計查詢這塊的工作，但是面對這么大的項目，需要統(tǒng)計的數(shù)據(jù)項都是業(yè)務(wù)系統(tǒng)產(chǎn)生的數(shù)據(jù)，我們只能一邊看PDM一邊和客戶、其他子系統(tǒng)負(fù)責(zé)人溝通。而客戶以前的報表是基于原有系統(tǒng)產(chǎn)生的，或者是采用逐層上報加體外循環(huán)，利用VBA產(chǎn)生的，他們對新系統(tǒng)還很陌生。子系統(tǒng)負(fù)責(zé)人當(dāng)前的任務(wù)是保證自己負(fù)責(zé)的業(yè)務(wù)系統(tǒng)順利上線，他們每天都在客戶現(xiàn)場做測試做支持，管不到我這邊。項目組前期對統(tǒng)計查詢不夠重視，相關(guān)的工作沒有啟動，人員也一直沒有保證。是不是別的項目也是這樣對待查詢統(tǒng)計的？不知道別的大型的項目類似這種統(tǒng)計查詢系統(tǒng)后來是怎么開發(fā)的。希望有做過類似項目的高手給點指點。