[轉載] 我的資料倉儲之路

http://www.itpub.net/thread-716197-1-1.html 

資料倉儲是什麼？BI是什麼？自己的資料倉儲之路如何繼續下去？BI到底有沒有前途？雖然從開始到現在已經過去兩年了，但是我的疑問還在繼續也將繼續下去.......

曾經在國內某民族通訊企業(透過CMM5級認證)工作過一段時間，因厭倦了客戶無休止的需求導致程式無休止的修改，也厭倦了某不懂編碼X士專案經理無休止的加班要求(一個月只休息了一天)，便走上了BI這條不歸路。

最初的BI知識，是由在公司接受了2周培訓的哥們給我培訓的，兩個人兩眼一抹黑便開始廣東XX局點BI的開局工作，大家對BI知識懵懵懂懂的，還好對 SQLServer2000和Oracle我還不陌生，畢竟也用了4、5年的時間做過資料庫程式開發(不管怎麼樣寫個SQL指令碼還是沒問題的)。XX局點的資料倉儲現在看起來並不太複雜，ETL工具是使用微軟SQLServer2000的DTS作了一層包裝，然後呼叫了SQLServer2000寫的一堆儲存過程，還有公司內部開發的一個資料遷移和處理二進位制話單的工具，配置起來頗有些麻煩(開發者頗有些功底，但以後也不會再使用了)；業務資料庫只有 Oracle，還有些二進位制檔案；報表工具是國內一家廠商提供的，說實話開發效率挺高的，但土了點，穩定性也差了點；OLAP就是Analysis Service了。那時候不懂架構，只知道比葫蘆畫瓢，按照原來的樣子進行程式碼編寫。有一件比較搞笑的事，使用者要求出一類報表，我和同事還不會OLAP，我就靈機一動寫了數十張報表，滿足不同維度和層次的要求，雖然效率很低。培訓了兩週後，就讓我到某某移動開局去了，當然什麼都沒搞起來，這讓我很沒面子，同時也很沒績效。

現在已經離開了那家曾經有過過勞死的企業(也許程式設計師就是IT民工吧，今天可以招上10000萬，明天也可以離去3000人，反正民工多的是啊)，該結的都結清了，誰也不再欠誰，我也失去了憎恨和愛戴的心情了。

這些都成為歷史了，還是寫寫資料倉儲的所謂架構吧。

資料倉儲的設計主要是這樣的：

業務系統—>ETL(DTS)—>原始資料庫—>事實資料庫—>OLAP—>前端報表。

業務系統就是使用者的Oracle資料庫了，裡面有一些業務資料(當然自己的系統資料字典還是有的)，此外還有一些二進位制話單檔案。

ETL過程就是一堆儲存過程(維度的抽取、原始資料的抽取、事實資料的日結)，然後透過DTS任務包排程起來。

原始資料庫就應該是ODS資料庫了，負責把資料原封不動的從業務系統抽取過來(部分也經過轉化和清洗)；出於對SQLServer2000效能的考慮，將每個業務資料表都分成歷史表和當前表，當前表根據資料量的情況決定保留資料週期並定時轉移到歷史表中。

事實資料庫儲存著聚合資訊的資料，完成KPI指標的計算，以及維度的抽取工作；同時在進行聚合的同時完成資料清洗工作。其實清洗很簡單的，就是對NULL 的處理，連對主外來鍵的判斷都沒有，也許是業務系統的資料質量還算不錯吧，維度的處理僅作更新和插入處理，來保證外來鍵資料的匹配。不過 SQLServer2000的效能實在不敢恭維，大於1000萬的資料表處理的勉勉強強的，只好建了許多了分割槽表(實際上就是每個月一張資料表，用檢視 Union起來，這也是微軟推薦的方式)。

OLAP採用VBScript指令碼對CUBE進行資料增量更新，說實話到現在也沒太看明白每條語句的意思，對於每個分析主題建立分割槽(按月)，主要是對MSOLAP的效能實在太不放心了。

報表工具採用國內一家專業廠商的報表工具，有一個應用伺服器，定義知識庫和報表許可權之類的內容，報表的開發還是比較容易的，託託拽拽的就成了，二次開發的函式有點困難，還好使用者要求不高，經過摸索作了一些自定義處理。就是應用伺服器有點不穩定，在我的長期摸索下也逐漸掌握了規律，寫了一些案例；哎現在再也用不到了。說實話其實OLAP功能還是蠻強大的(主要是能夠滿足國內企業的報表功能和變態查詢要求)，OLTP報表功能就不敢恭維了。

對於業務資料到原始資料的處理，完全採用增量抽取的原則(因為每個表都有了時間點)；對於原始資料到事實資料的處理，則增加了一張log表，記錄每次抽取的週期、跨度、與當前時間的差距和狀態等等。對於OLAP的增量處理也是靠一張日誌表決定處理的範圍。唯一比較獨特的可能是部分業務資料使用者可能會更新，需要重新抽取、聚集和OLAP處理，這個時候在處理之前首先刪除這段時間的資料，重新抽取、聚集和OLAP處理，當然是靠指令碼來完成的。

總體來講這就是我一年多做BI的經驗和所謂架構吧，當然也有許多問題，例如SQLServer2000的穩定性、效能考驗等等問題，DTS處理過程中來時發生任務中斷，需要察看日誌，作進一步處理，對於源抽取、事實日結、OLAP處理的中斷處理方式均不一致。對於SQLServer2000的死鎖以及記憶體洩漏等問題也有了一定經驗。對報表工具的理解也是我後來對各種報表工具學習的基礎。

經過一年多7、8個局點的鍛鍊，臉皮也變厚了，學習也麻木了，現成的版本，統一的流程，自己以為這就是BI的全部了，總之自己就是搞過資料倉儲的人了，加上做過那麼點資料庫最佳化和資料遷移，感覺自己算是小牛一個了，呵呵。

不幸的是今年年初又折騰到老路上去了，拼了老命幹了1個月的java和WebService，搞得心神俱疲，才發現自己不年輕了，也不是做編碼的料。

於是乎辭職了，不管好歹也是從國內數一數二的大公司出來的，找個世界五百強還是沒什麼問題的，而且專業對口，屬於那種天生就可以外出和客戶交流的人，這可能是新公司對我的期望，要不然英語那麼差勁，怎麼可能輕易進來呢，待遇也還算不錯，是原公司的1.5倍。其實我根本就不是那樣的人，呵呵，不太喜歡和客戶交流，不善於言辭，技術也是樣樣都知道樣樣不精通的那種。

既然進來了，又開始搞BI了，不過已經下班了，回去後再續寫新公司的BI篇章，呵呵。

在新公司轉眼已經呆了5個月，前三個月除了培訓就是學習，向領導要了幾次活幹之後再也不要活幹了，因為大家都無活可幹，於是每天上上itpub學習一下 Oracle，或者交流一下資料倉儲，積累一下人脈(剛學會的名詞)，英語本來是一個很重要的目標，可惜我總是不開竅，而且連半個假洋鬼子英語也說不好，現在要做國內專案了，英語成了我永遠的痛。

資料倉儲知識沒學到多少，Oracle知識卻感覺長進了不少，每天培訓不少，可有質量的培訓卻不多，當然即使有質量的培訓也輪不到我等剛入公司的去學習。外企就是外企，每天總是拿著工資不幹活，天天喝著咖啡、橙汁，總感覺像是被恩賜似的，很不爽，還是得找點事來做，不過三個月的懈怠確確實實把我從一個勤勤懇懇兢兢業業的老黃牛變成了一個徹頭徹尾的懶蟲了，每天早9晚6準時的很，也許這才是生活，名片也列印了，上面沒有手機，就是八個小時之外不用來找我的意思吧。

國外專案談了將近一年了沒談成，我就失業了；另外一個國內外企的專案因為領導感覺我不善言辭，把我換掉了；只好做一個徹頭徹尾的國內專案了，做一個小小的工程師也很不錯，不用擔責任想事情，反正我就是一個懶惰的人。一個月就換了3個工作，雖然什麼都還沒做。

言歸正傳，國內企業就是國內企業，外表很光鮮，做起專案來尾巴就露出來了，大概是一個應景之作吧，客戶要求一個資料倉儲專案1個半月就要完成，半個月的需求，一個月的設計開發和測試；更要命的是現在需求絲毫沒有些許的概念，客戶要求用國際化的行業經驗來幫助制定相應的KPI，理論聯絡實際，怎麼招，我也不知道怎麼招，反正有售前人員請的國外顧問，能忽悠就忽悠吧。不過說歸說，前期的工作還是要開展的。

所謂的資料倉儲架構，我也是第一次聽說，改改一些概念，乾脆一起來分享一下吧，沒準還能成為行業標準，呵呵！該架構主要分為四層結構體系：
> ODS層
主要負責採集業務系統並儲存一定期限內的相關業務資料。當然也可以滿足使用者對明細資料的查詢要求，姑且也可以算作明細資料倉儲。
> 資料倉儲層
將ODS層經過質量檢查、清洗、轉換後，形成符合質量要求的公共資料中心。實際上與ODS層差別不大，都是建立以ER為中心的資料關係，方便以後的資料的聚合。
> 明細資料集市層即前面所說的事實層
按主題及KPI指標對資料倉儲層資料進行進一步轉換，將指標與維度組成資料集市。這是OLAP的資料基礎。
> 聚合資料集市層即OLAP
在明細資料集市層的基礎上，提供基於聯機分析處理(OLAP)引擎的多維分析能力，解決聯機分析功能和決策支援要求。
> 資料展現層
按照使用者報表要求，提供使用者報表介面及預警分發機制。

其中前3層都是屬於ETL層的，問題是層次出來了我的疑問也出來了，都是屬於那種別人不操心我瞎操心的事。畢竟算是搞資料庫出身的(搞過一些索引和簡單的 SQL調優)，最關心的還是效能問題。資料倉儲是企業級的資料中心，每天上G的資料的企業不在少數，那麼多的層次，使用工具能抽的完資料嗎？說實話我實在不信任ETL工具，總感覺他沒我寫的SQL語句效率高；即使抽的完資料，那麼多的層次轉換能處理的完嗎；即使處理完，如果萬一一個環節出現問題，能回退或重新處理嗎；處理完後那OLAP該怎麼排程啊；資料質量（清洗轉換）到底在哪個環節處理；資料質量到底包括哪些東西(除了主外來鍵缺失和NULL值)，兄弟比較愚笨，一直想不明白；不合質量要求的資料如何處理；入庫的資料在業務庫發生更改怎麼辦；業務資料沒有時間戳怎麼辦；資料核對和校驗工作如何進行；不管工具也好程式碼也好，到底有沒有通用的處理流程(比如維度資料處理，原始業務資料抽取，事實表日結處理)；還有就是到現在也沒搞到合適的需求設計文件的模板 (如果哪位兄弟有可以幫忙提供一下)。這一系列問題我是橫豎想不明白的，反正我的問題總是比別人多，學東西總比別人慢，還是人年齡大了真的退化了。

關於資料倉儲的逐步學習，發現不懂得越來越多了，希望大家多提點提點，資料探勘我是一竅不通，高等數學沒學好，演算法自然也學不會，只怪我高中文科出身，資訊管理系的文憑拿的還是文學學士，簡直沒臉見人了；業務建模和需求分析也不是我擅長的，因此我只能關心純技術的東西，可是ETL工具把人寫程式碼的權力也剝奪了，因此我只能關心一些大的方面了，這難道就是所謂的架構嗎？不知道，哎，學吧！

完了，希望不要佔用大家的時間,還是帶一句E文吧，TKS！