BI有沒有前途 數據倉庫之路如何繼續下去

這篇論壇文章(賽迪網技術社區)根據筆者的個人經曆論述了以下幾個問題:

1.數據倉庫是什麽?2.BI是什麽?3.自己的數據倉庫之路如何繼續下去?4.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!

關于BI與“數據倉庫”在企業何時進行實施的討論
由于前天聽到一個說法,集團公司需要部署數據倉庫及BI的相關功能,一直以來,據我了解的是,BI只有在企業信息化達到了一定的層次才開始部署的,而且部署BI主要不是以軟件功能爲主,而是以企業建模爲主的,因此,就這...查看完整版>>關于BI與“數據倉庫”在企業何時進行實施的討論
 
關于BI與“數據倉庫”在企業何時進行實施的討論
由于前天聽到一個說法,集團公司需要部署數據倉庫及BI的相關功能,一直以來,據我了解的是,BI只有在企業信息化達到了一定的層次才開始部署的,而且部署BI主要不是以軟件功能爲主,而是以企業建模爲主的,因此,就這...查看完整版>>關于BI與“數據倉庫”在企業何時進行實施的討論
 
深入講解如何填平數據倉庫與實時系統鴻溝
這篇論壇專題(賽迪網技術社區)主要介紹了如何解決數據倉庫與實時系統之間的交互問題,詳細內容請大家參考下文: 在當今信息密集的環境下,對于數據倉庫的需求日益增長。的確,衆多的應用程序,如CRM、ERP、信息門戶...查看完整版>>深入講解如何填平數據倉庫與實時系統鴻溝
 
如何找到適合你的數據倉庫
  如同選擇汽車一樣,車內裝修、音響、座椅固然重要,但是發動機性能、底盤堅固性等肉眼看不見的東西恐怕對産品質量更具有決定性。可惜的是,研究數據倉庫的一些人把注意力集中在一些非常漂亮、非常吸引人的前端程...查看完整版>>如何找到適合你的數據倉庫
 
如何創建一個成功的數據倉庫(data warehouse) (想了解數據倉庫的人士快看)
如何創建一個成功的數據倉庫(data warehouse) (想了解數據倉庫的人士快看) 如何創建一個成功的數據倉庫(data warehouse) (想了解數據倉庫的人士快看) 如何創建一個成功的數據倉庫(data warehose)...查看完整版>>如何創建一個成功的數據倉庫(data warehouse) (想了解數據倉庫的人士快看)
 
如何構建銀行數據倉庫
如何構建銀行數據倉庫 如何構建銀行數據倉庫 如何構建銀行數據倉庫河南省鄧州市新華東路11號市人行 宋玉長...查看完整版>>如何構建銀行數據倉庫
 
如何創建一個成功的數據倉庫(data warehouse) (想了解數據倉庫的人士快看)
如何創建一個成功的數據倉庫(data warehose),下面的故事將告訴你! The company's first data warehouse project began with a casual conversation between several executives on their way to lunch. The pe...查看完整版>>如何創建一個成功的數據倉庫(data warehouse) (想了解數據倉庫的人士快看)
 
如何構建銀行數據倉庫
如何構建銀行數據倉庫河南省鄧州市新華東路11號市人行 宋玉長 數據倉庫技術作爲一項數據管理領域的新技術,其精髓在于針對聯機分析處理(OLAP)提出了一種綜合的解決方案,與以往很多技術不同的是,它主要是一種概念,...查看完整版>>如何構建銀行數據倉庫
 
數據抽取、清洗與轉換 BI項目中ETL設計
ETL是將業務系統的數據經過抽取、清洗轉換之後加載到數據倉庫的過程,目的是將企業中的分散、零亂、標准不統一的數據整合到一起,爲企業的決策提供分析的依據。 ETL是BI項目最重要的一個環節,通常情況下ETL會花掉整...查看完整版>>數據抽取、清洗與轉換 BI項目中ETL設計
 
 
回到王朝網路移動版首頁