對數據倉庫探討

申請免費試用、咨詢電話：400-8352-114

業(yè)務知識遠遠重于技術-當今數據倉庫真正實施的是一些國家機構或些國有企業(yè)。真正估算數據倉庫的效益是一件十分困難的事情，因此，對于多數私有企業(yè)來說， 不明確的軟件投資往往存在很大的風險，這就決定了數據倉庫的運用對于目前來說它的范圍對于私人企業(yè)這一塊是來是比較狹隘的。

而對于是否該上數據倉庫時，按數據質量這一層面來說，往往是一些銷售系統，一些產品軟件的數據質量比較高，而對于一些大型定制系統，系統本身可能就不是一 個完整可靠的系統，可能存在著很多潛在的錯誤，因此，在此基礎上要做好數據倉庫，是一個十分艱巨的任務，而在現實環(huán)境中，往往上數據倉庫的就是建立在此基 礎上的。存在既是道理。那么我們來分析數據倉庫中存在的各種困難及如何把不成功因素降為最小。

(本人按自己所在項目及一些心得體會在此進行探討，在此談論的數據倉庫主要針對本人經歷項目-省級集中稅務數據倉庫)

首先：是否該上數據倉庫

對于這個問題，作為公司方來說，這個問題幾乎就等于問賣東西的人我該不該買這東西。而對于甲方來說，他們上不上數據倉庫無非是想在工作中多得到些有用的信 息(不排除其中有很多是面子工程)，多些原系統中無法滿足的查詢、分析及一些能為決策提供的多方面宏觀數據。因此，在項目競標中，公司必然會說出客戶需求 上數據倉庫項目的N個理由及好處。項目競標成功，那么售前人員的工作算是取的了成功，而他們所許下的很多承諾也不是他們所要做的，我做為一個項目開發(fā)及實 施人員，關注的是后者，不管怎樣，項目競標的成功才有我們要做的事。所以，上不上數據倉庫已不是我們關注的，我們專注的是，最大努力做好它。

其次：數據需求編寫階段

客戶方經過前期競標時公司方的講解及數據倉庫的一些初步了解后，此時可能在客戶方的頭腦中會有一種，數據倉庫就是無所不能的東西，只要自己能想到的，那么 就能實現它。這是一個比較危險的暗號，在他們編寫需求的時候，很有可能天馬行空，閉門造車，想出很多不切實際、過細過雜的需求。需求是一項目成敗的關鍵因 素，主要問題有已下幾點：

(1),需求該由誰來撰寫，現實中多數情況下是客戶方，

個人認為快速可行的方案是由公司方提出較核心的大部分需求，當然提出此需求必須在了解源數據的結構，確保需求實施中有取數的來源及取數的準確性，因此此步 驟的技術含量相當高，且對于繁雜的業(yè)務系統的分析也不可能是一時半伙就能解決的。公司方必須經過調查或其它實施中經驗的總結，確保此部分需求為相對核心、 有實施意義及可實施的。而且此需求并非一成不變的，隨著對業(yè)務的發(fā)展及自身認識的加深，以及各個項目中經驗及教訓，必須對其進行部分的取舍，以適應市場及 現狀的要求。而為兼顧地方的特有的需求，由業(yè)務方提出部分需求，然后由公司及業(yè)務方共同討論對其進行取舍，我們必須認識到，并非所有需求都能在未實施之前 確定它是否可實施，很多需求由于各種原因，只有在實施過程中才發(fā)現是不可行的、有問題的需求。

這種由公司方提出絕大部分客戶方西方結合自身特點提出小部分需求的方法，可以最大可能地保證需求的快速構建及實施過程的相對暢通(公司方提出的需求一般是 以公司實施為前提，一般為可行的方案，當然源業(yè)務系統與數據倉庫都為本公司開發(fā)更容易實現)。當需求編寫完成后，也并不意味著需求的定型，在以后開發(fā)的過 程中，可能是個不斷修改不斷完善的過程。

再次，項目開發(fā)階段

"由客戶方提出源系統數據詳細清單，通過與客戶方的溝通定義目標區(qū)數據模型，定制出源到目標的MAPPING清單, 然后ETL人員根據此清單進行數據抽取，報表開發(fā)人員通過數據模型進行語義層設計、報表展現" ，仿佛一個開發(fā)過程十分的清晰簡單，但現在中，困難可謂是無所不在，源系統數據理解、模型的定義、ETL的程序設計等各方面都可能出現潛在的、必然的、意 想不到的困難。

以下簡單列出些常見的問題

1)，對源系統的數據理解，在項目中，可能存在客戶方很難給出源系統的詳細清單，特別是對于業(yè)務繁多的大系統而言，可能源系統表有幾百個之多，而且關系復雜，這將給mapping制定帶來巨大的困難。

2)，數據抽取困難

一般情況下，數據的抽取都有時間的限制，當數據量過大且模塊加工繁雜時，必然存在很大的難度。除此之外，以下因素也是經常存在。

(1),表記錄變化無相應的系統時間戳，此問題在系統中一般都存在。(Oracle解決辦法，物化視圖、CDC等)
(2),數據來源復雜，存在多個業(yè)務系統及外部數據的集中。
(3),抽取工具不成熟及自己使用的不熟練(主觀及客觀因素)。
(4)，業(yè)務系統的不斷變更增大數據倉庫抽取的難度，etl抽取程序可能要有N個版本。
3)， 怎樣說服客戶數據倉庫的正確性--對于一大型數據倉庫的實施運行的檢查，如果證明數據倉庫的準確性在某些模塊是個十分困難的事情，主要原因有以下幾點：

(1)，在其它業(yè)務系統中沒有相應的指標進行對比。
(2)，原始數據中垃圾數據的存在且難于判定。
數據倉庫中存在最多的是各維度對比及各方面分析，對于一些數據存在維度錯誤及關系錯誤而難于確定修復策略，當然此時數據倉庫的建立也能發(fā)現源業(yè)務系統的不足及促進源系統的不斷完善。
(3)，業(yè)務規(guī)則與原始數據業(yè)務系統難于對應。
例如 A業(yè)務及B業(yè)務是有聯系的，但可能在原業(yè)務系統中沒有此類需求，因此AB找不到對應的關系，而在數據倉庫中AB的聯系自然就無法體現了。，

特別對于稅務數據倉庫來說，主題多，業(yè)務廣，涉及面廣，因此對于成千上萬的業(yè)務關系中，怎樣抽取有效的、核心的、有決策意義、多數人所關心的需求成為一個很大的難點。

對于數據抽取，給幾點建議

一，必須先構建數據平臺，對于一個長期的數據倉庫項目，必須構建完整的數據平臺，這個中轉在前期可能要花費些時間，但對于后期是很有必要的，我想以數據為驅動相對業(yè)務驅動來說，實踐更容易快捷。

二，在項目未開始階段，公司必須有足夠的技術積累，最大程度地不讓技術成為一個開發(fā)及實施的拌腳石，選擇自己熟練的技術出發(fā)，若客戶的硬性規(guī)定，那在開發(fā)的前期盡最大努力掌握它吧。

稅務數據倉庫實施簡易步驟：最后，項目的運行實踐

數據倉庫的開發(fā)不同于一般的業(yè)務系統開發(fā)，特別是測試驗收，開發(fā)環(huán)境和生產環(huán)境對于數據倉庫項目來說可能存大很大的區(qū)別，數據倉庫的運行是一個不斷向前的 過程，數據倉庫的初始化及增量是密不可分的，但其中的測試遠比任何業(yè)務系統難，原因有，抽取時間一般過長、網絡因素、數據抽取失敗的預防及處理，容錯性等 這些都必須考慮，而且，數據倉庫程序的發(fā)布也可能是多方面的，(可能有存儲過程，etl工具mapping程序的遷移)，應盡可能的把程序發(fā)布作為一統一 過程(過多的步驟出差的概率自然會高)，程序版本的控制等。

看到這里，我在此十分感謝，浪費了您很多寶貴時間，上面我可能提出了很多數據倉庫中出現的問題，而沒有討論它的解決之道，我想，任何問題解決方法不可能是 絕對的，在此也希望大家共同探討，數據倉庫難在哪里，主要是數據倉庫是要收拾別人的攤子。攤子實在是太爛的話，我想，再牛的人也不可能上出好的數據倉庫項 目。

BTW：數據倉庫之路多的是教訓，吾將上下而求索…(techtarget)