1.數(shù)據(jù)倉庫是什么？2.BI是什么？3.自己的數(shù)據(jù)倉庫之路如何繼續(xù)下去？4.BI到底有沒有前途？

更多內(nèi)容請讀者參考下文：

雖然從開始到現(xiàn)在已經(jīng)過去兩年了，但是我的疑問還在繼續(xù)也將繼續(xù)下去.......

曾經(jīng)在國內(nèi)某民族通信企業(yè)(通過CMM5級認(rèn)證)工作過一段時(shí)間，因厭倦了客戶無休止的需求導(dǎo)致程序無休止的修改，也厭倦了某不懂編碼X士項(xiàng)目經(jīng)理無休止的加班要求(一個月只休息了一天)，便走上了BI這條不歸路。

最初的BI知識，是由在公司接受了2周培訓(xùn)的哥們給我培訓(xùn)的，兩個人兩眼一抹黑便開始廣東XX局點(diǎn)BI的開局工作，大家對BI知識懵懵懂懂的，還好對 SQLServer2000和Oracle我還不陌生，畢竟也用了4、5年的時(shí)間做過數(shù)據(jù)庫程序開發(fā)(不管怎么樣寫個SQL腳本還是沒問題的)。XX局點(diǎn)的數(shù)據(jù)倉庫現(xiàn)在看起來并不太復(fù)雜，ETL工具是使用微軟SQLServer2000的DTS作了一層包裝，然后調(diào)用了SQLServer2000寫的一堆存儲過程，還有公司內(nèi)部開發(fā)的一個數(shù)據(jù)遷移和處理二進(jìn)制話單的工具，配置起來頗有些麻煩(開發(fā)者頗有些功底，但以后也不會再使用了)；業(yè)務(wù)數(shù)據(jù)庫只有 Oracle，還有些二進(jìn)制文件；報(bào)表工具是國內(nèi)一家廠商提供的，說實(shí)話開發(fā)效率挺高的，但土了點(diǎn)，穩(wěn)定性也差了點(diǎn)；OLAP就是Analysis Service了。那時(shí)候不懂架構(gòu)，只知道比葫蘆畫瓢，按照原來的樣子進(jìn)行代碼編寫。有一件比較搞笑的事，用戶要求出一類報(bào)表，我和同事還不會OLAP，我就靈機(jī)一動寫了數(shù)十張報(bào)表，滿足不同維度和層次的要求，雖然效率很低。培訓(xùn)了兩周后，就讓我到某某移動開局去了，當(dāng)然什么都沒搞起來，這讓我很沒面子，同時(shí)也很沒績效。

現(xiàn)在已經(jīng)離開了那家曾經(jīng)有過過勞死的企業(yè)(也許程序員就是IT民工吧，今天可以招上10000萬，明天也可以離去3000人，反正民工多的是啊)，該結(jié)的都結(jié)清了，誰也不再欠誰，我也失去了憎恨和愛戴的心情了。

這些都成為歷史了，還是寫寫數(shù)據(jù)倉庫的所謂架構(gòu)吧。

數(shù)據(jù)倉庫的設(shè)計(jì)主要是這樣的：

業(yè)務(wù)系統(tǒng)—>ETL(DTS)—>原始數(shù)據(jù)庫—>事實(shí)數(shù)據(jù)庫—>OLAP—>前端報(bào)表。

業(yè)務(wù)系統(tǒng)就是用戶的Oracle數(shù)據(jù)庫了，里面有一些業(yè)務(wù)數(shù)據(jù)(當(dāng)然自己的系統(tǒng)數(shù)據(jù)字典還是有的)，此外還有一些二進(jìn)制話單文件。

ETL過程就是一堆存儲過程(維度的抽取、原始數(shù)據(jù)的抽取、事實(shí)數(shù)據(jù)的日結(jié))，然后通過DTS任務(wù)包調(diào)度起來。

原始數(shù)據(jù)庫就應(yīng)該是ODS數(shù)據(jù)庫了，負(fù)責(zé)把數(shù)據(jù)原封不動的從業(yè)務(wù)系統(tǒng)抽取過來(部分也經(jīng)過轉(zhuǎn)化和清洗)；出于對SQLServer2000性能的考慮，將每個業(yè)務(wù)數(shù)據(jù)表都分成歷史表和當(dāng)前表，當(dāng)前表根據(jù)數(shù)據(jù)量的情況決定保留數(shù)據(jù)周期并定時(shí)轉(zhuǎn)移到歷史表中。

事實(shí)數(shù)據(jù)庫保存著聚合信息的數(shù)據(jù)，完成KPI指標(biāo)的計(jì)算，以及維度的抽取工作；同時(shí)在進(jìn)行聚合的同時(shí)完成數(shù)據(jù)清洗工作。其實(shí)清洗很簡單的，就是對NULL 的處理，連對主外鍵的判斷都沒有，也許是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)質(zhì)量還算不錯吧，維度的處理僅作更新和插入處理，來保證外鍵數(shù)據(jù)的匹配。不過 SQLServer2000的性能實(shí)在不敢恭維，大于1000萬的數(shù)據(jù)表處理的勉勉強(qiáng)強(qiáng)的，只好建了許多了分區(qū)表(實(shí)際上就是每個月一張數(shù)據(jù)表，用視圖 Union起來，這也是微軟推薦的方式)。

OLAP采用VBScript腳本對CUBE進(jìn)行數(shù)據(jù)增量更新，說實(shí)話到現(xiàn)在也沒太看明白每條語句的意思，對于每個分析主題建立分區(qū)(按月)，主要是對MSOLAP的性能實(shí)在太不放心了。

報(bào)表工具采用國內(nèi)一家專業(yè)廠商的報(bào)表工具，有一個應(yīng)用服務(wù)器，定義知識庫和報(bào)表權(quán)限之類的內(nèi)容，報(bào)表的開發(fā)還是比較容易的，托托拽拽的就成了，二次開發(fā)的函數(shù)有點(diǎn)困難，還好用戶要求不高，經(jīng)過摸索作了一些自定義處理。就是應(yīng)用服務(wù)器有點(diǎn)不穩(wěn)定，在我的長期摸索下也逐漸掌握了規(guī)律，寫了一些案例；哎現(xiàn)在再也用不到了。說實(shí)話其實(shí)OLAP功能還是蠻強(qiáng)大的(主要是能夠滿足國內(nèi)企業(yè)的報(bào)表功能和變態(tài)查詢要求)，OLTP報(bào)表功能就不敢恭維了。

對于業(yè)務(wù)數(shù)據(jù)到原始數(shù)據(jù)的處理，完全采用增量抽取的原則(因?yàn)槊總€表都有了時(shí)間點(diǎn))；對于原始數(shù)據(jù)到事實(shí)數(shù)據(jù)的處理，則增加了一張log表，記錄每次抽取的周期、跨度、與當(dāng)前時(shí)間的差距和狀態(tài)等等。對于OLAP的增量處理也是靠一張日志表決定處理的范圍。唯一比較獨(dú)特的可能是部分業(yè)務(wù)數(shù)據(jù)用戶可能會更新，需要重新抽取、聚集和OLAP處理，這個時(shí)候在處理之前首先刪除這段時(shí)間的數(shù)據(jù)，重新抽取、聚集和OLAP處理，當(dāng)然是靠腳本來完成的。

總體來講這就是我一年多做BI的經(jīng)驗(yàn)和所謂架構(gòu)吧，當(dāng)然也有許多問題，例如SQLServer2000的穩(wěn)定性、性能考驗(yàn)等等問題，DTS處理過程中來時(shí)發(fā)生任務(wù)中斷，需要察看日志，作進(jìn)一步處理，對于源抽取、事實(shí)日結(jié)、OLAP處理的中斷處理方式均不一致。對于SQLServer2000的死鎖以及內(nèi)存泄漏等問題也有了一定經(jīng)驗(yàn)。對報(bào)表工具的理解也是我后來對各種報(bào)表工具學(xué)習(xí)的基礎(chǔ)。

經(jīng)過一年多7、8個局點(diǎn)的鍛煉，臉皮也變厚了，學(xué)習(xí)也麻木了，現(xiàn)成的版本，統(tǒng)一的流程，自己以為這就是BI的全部了，總之自己就是搞過數(shù)據(jù)倉庫的人了，加上做過那么點(diǎn)數(shù)據(jù)庫優(yōu)化和數(shù)據(jù)遷移，感覺自己算是小牛一個了，呵呵。

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

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

既然進(jìn)來了，又開始搞BI了，不過已經(jīng)下班了，回去后再續(xù)寫新公司的BI篇章，呵呵。

在新公司轉(zhuǎn)眼已經(jīng)呆了5個月，前三個月除了培訓(xùn)就是學(xué)習(xí)，向領(lǐng)導(dǎo)要了幾次活干之后再也不要活干了，因?yàn)榇蠹叶紵o活可干，于是每天上上itpub學(xué)習(xí)一下 Oracle，或者交流一下數(shù)據(jù)倉庫，積累一下人脈(剛學(xué)會的名詞)，英語本來是一個很重要的目標(biāo)，可惜我總是不開竅，而且連半個假洋鬼子英語也說不好，現(xiàn)在要做國內(nèi)項(xiàng)目了，英語成了我永遠(yuǎn)的痛。

數(shù)據(jù)倉庫知識沒學(xué)到多少，Oracle知識卻感覺長進(jìn)了不少，每天培訓(xùn)不少，可有質(zhì)量的培訓(xùn)卻不多，當(dāng)然即使有質(zhì)量的培訓(xùn)也輪不到我等剛?cè)牍镜娜W(xué)習(xí)。外企就是外企，每天總是拿著工資不干活，天天喝著咖啡、橙汁，總感覺像是被恩賜似的，很不爽，還是得找點(diǎn)事來做，不過三個月的懈怠確確實(shí)實(shí)把我從一個勤勤懇懇兢兢業(yè)業(yè)的老黃牛變成了一個徹頭徹尾的懶蟲了，每天早9晚6準(zhǔn)時(shí)的很，也許這才是生活，名片也打印了，上面沒有手機(jī)，就是八個小時(shí)之外不用來找我的意思吧。

國外項(xiàng)目談了將近一年了沒談成，我就失業(yè)了；另外一個國內(nèi)外企的項(xiàng)目因?yàn)轭I(lǐng)導(dǎo)感覺我不善言辭，把我換掉了；只好做一個徹頭徹尾的國內(nèi)項(xiàng)目了，做一個小小的工程師也很不錯，不用擔(dān)責(zé)任想事情，反正我就是一個懶惰的人。一個月就換了3個工作，雖然什么都還沒做。

言歸正傳，國內(nèi)企業(yè)就是國內(nèi)企業(yè)，外表很光鮮，做起項(xiàng)目來尾巴就露出來了，大概是一個應(yīng)景之作吧，客戶要求一個數(shù)據(jù)倉庫項(xiàng)目1個半月就要完成，半個月的需求，一個月的設(shè)計(jì)開發(fā)和測試；更要命的是現(xiàn)在需求絲毫沒有些許的概念，客戶要求用國際化的行業(yè)經(jīng)驗(yàn)來幫助制定相應(yīng)的KPI，理論聯(lián)系實(shí)際，怎么招，我也不知道怎么招，反正有售前人員請的國外顧問，能忽悠就忽悠吧。不過說歸說，前期的工作還是要開展的。

所謂的數(shù)據(jù)倉庫架構(gòu)，我也是第一次聽說，改改一些概念，干脆一起來分享一下吧，沒準(zhǔn)還能成為行業(yè)標(biāo)準(zhǔn)，呵呵！該架構(gòu)主要分為四層結(jié)構(gòu)體系：

> ODS層

主要負(fù)責(zé)采集業(yè)務(wù)系統(tǒng)并保存一定期限內(nèi)的相關(guān)業(yè)務(wù)數(shù)據(jù)。當(dāng)然也可以滿足用戶對明細(xì)數(shù)據(jù)的查詢要求，姑且也可以算作明細(xì)數(shù)據(jù)倉庫。

> 數(shù)據(jù)倉庫層

將ODS層經(jīng)過質(zhì)量檢查、清洗、轉(zhuǎn)換后，形成符合質(zhì)量要求的公共數(shù)據(jù)中心。實(shí)際上與ODS層差別不大，都是建立以ER為中心的數(shù)據(jù)關(guān)系，方便以后的數(shù)據(jù)的聚合。

> 明細(xì)數(shù)據(jù)集市層即前面所說的事實(shí)層

按主題及KPI指標(biāo)對數(shù)據(jù)倉庫層數(shù)據(jù)進(jìn)行進(jìn)一步轉(zhuǎn)換，將指標(biāo)與維度組成數(shù)據(jù)集市。這是OLAP的數(shù)據(jù)基礎(chǔ)。

> 聚合數(shù)據(jù)集市層即OLAP

在明細(xì)數(shù)據(jù)集市層的基礎(chǔ)上，提供基于聯(lián)機(jī)分析處理(OLAP)引擎的多維分析能力，解決聯(lián)機(jī)分析功能和決策支持要求。

> 數(shù)據(jù)展現(xiàn)層

按照用戶報(bào)表要求，提供用戶報(bào)表界面及預(yù)警分發(fā)機(jī)制。

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

關(guān)于數(shù)據(jù)倉庫的逐步學(xué)習(xí)，發(fā)現(xiàn)不懂得越來越多了，希望大家多提點(diǎn)提點(diǎn)，數(shù)據(jù)挖掘我是一竅不通，高等數(shù)學(xué)沒學(xué)好，算法自然也學(xué)不會，只怪我高中文科出身，信息管理系的文憑拿的還是文學(xué)學(xué)士，簡直沒臉見人了；業(yè)務(wù)建模和需求分析也不是我擅長的，因此我只能關(guān)心純技術(shù)的東西，可是ETL工具把人寫代碼的權(quán)力也剝奪了，因此我只能關(guān)心一些大的方面了，這難道就是所謂的架構(gòu)嗎？不知道，哎，學(xué)吧！

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