資料倉儲和我們常見的RDBMS系統有些親緣關係,但它又有所不同。如果你沒有實施過資料倉儲,那麼從設定目標到給出設計,從建立資料結構到編寫資料分析程式,再到面對挑剔的使用者的評估,整個過程都會帶給你一種與以往的項目完全不同的體驗。一句話,如果你試圖以舊有的方式建立資料倉儲,那你所面對的不是預算超支就是所建立的資料倉儲無法良好運作。
在處理一個資料倉儲項目時需要注意的問題很多,但同時也有很多有建設性的參考可以協助你更順利的完成任務。開放思維,不斷嘗試新的途徑,對於找到一種可行的資料倉儲實現方法來說也是必需的。
1. 配備一個全職的專案經理或你自己全面負責專案管理
在通常情況下,專案經理都會同時負責多重專案的實施。這麼做完全是出於資金和IT資源方面的考慮。但是對於資料倉儲項目的管理,絕對不能出現一人身兼數個項目的情況。由於你所處的領域是你和你的團隊之前沒有進入過的領域,有關資料倉儲的一切-資料分析、設計、編程、測試、修改、維護-全都是嶄新的,因此你或者你指派的專案經理如果能全心投入,對於項目的成功會有很大協助。
2. 將專案管理職責推給別的專案經理
由於資料倉儲實現過程實在是太困難了,為了避免自虐,你可以在當前階段的項目完成後就將專案管理職責推給別的專案經理。當然,這個新的專案經理一定要複合第一條所說的具有全職性。為什麼要這麼做呢?首先,從專案經理的角度看,資料倉儲實施過程的任何一個階段都足以讓人身心疲憊。從實體儲存體裝置的開發到Extract-Transform-Load的實現,從設計開發模型到OLAP,所有階段都明顯的比以前接觸的項目更加困難。每個階段不但需要新的處理方法、新的管理方法,還需要創新性的觀點。所以將管理職責推給別的專案經理不但不會對項目有損害,還可以起到協助作用。
3.與使用者進行溝通
這裡所講的內容遠比一篇文章本身要重要的多。你必須明白,在資料倉儲的設計階段,那些潛在使用者自己也不清楚他們到底需要資料倉儲為他們做什麼。他們在不斷的探索和發現自己的需求,而你的Team Dev也在和客戶的接觸中做著同樣的事情。更加頻繁的與客戶接觸,多做記錄,並讓你的團隊更關注於項目需求討論的結果而不是討論的過程本身。
既然你和客戶的交流是為了瞭解儲存的資料是何種類型以及如何有效儲存資料,你也許需要(和你的使用者一起)採用一種新的方法觀察資料,而不是直接處理資料。你可以嘗試從中找出隱藏的資訊,比如在一段時期內的數字漲落等。不要試圖追尋項目需求的答案,而是要讓答案找上門來。
4. 以技術/資訊庫作為領導
由於資料倉儲實施的各個階段都有很大不同,因此你需要有人能起到維持整個項目的連續進行的作用,不過這個職責並不需要那種全職性。項目實施有三個重要方面:架構、技術和業務。將架構作為重點可以保證在整個項目中,資料倉儲的架構從物理層往上,都會受到良好的維護。而我們應該將技術作為重點,因為Team Dev和關鍵使用者都在使用他們以前從未用過的工具,必須有人監督開發過程以及工具使用的一致性。
最後,在資料倉儲的應用過程中浮現出來的業務需求必須被詳細分析和記錄,以促機開發過程持續下去。如果使用者不能很好的開發人員以及其它使用者溝通,那麼資料分析和度量方面的開發進程就會延期,所以必須有人關注業務方面的開發,推動開發進入更進階別。
5. 跳出反覆修改程式的陷阱
第一次實現的資料倉儲肯定不會是最終交付的版本。為什麼呢?實際上在真正見到產品前,你無法確定的知道自己的目標是什麼。或者說,終端使用者只有在使用資料倉儲產品一段時間後,才能明確告訴你這個產品是不是他所希望的。與你以往處理的項目不同,業務智能還處於發展的初期,每個公司對業務智能都有不同的解釋,因此你的項目決不會一次成功。
為了以正確的格式獲得資料,你需要在不斷變化的狀況中摸索前進。BI具有很強的個性,不同的環境、不同的市場以及不同的企業都有不同的BI。這又代表什麼呢?這表示你需要把資料庫管理員放在一個訊息相對封閉的環境中,不要讓他知道資料倉儲的資料結構以及ETL程式在不斷的改變。對此沒有別的辦法。這樣可以減輕你和DBA所承受的壓力。
6. 對大量的前端資源進行資料來源分析
在資料倉儲實現過程中,你不得不在舊有的資料中艱難跋涉,這些資料來自老的資料庫、老的磁帶機以及遠端資料。它們中的大部分都淩亂不堪,並且難以擷取。你要對這些資料進行大量處理,並且還要設計ETL程式來尋找其中的有用資訊。如果你希望整個項目做起來比較順利,並且找到一種方法能夠一次成功,那就需要你的開發人員必須花費足夠的時間來充分研究這些舊有資料,將淩亂的資料規則化,並儘力設計和實現強壯的資料擷取和轉換過程。資料倉儲的ETL部分會佔用整個項目資源的百分之八十,所以一定要確定你的資源都用在刀刃上了。
7. 將人際關係處理放在首位
在資料倉儲實現過程中真正的地獄不是來自技術或者開發方面,而是來自你周圍的人。你也許會遇到一個對項目並不樂觀而又沒時間聽你陳述的領導。你也許會遇到一些開發人員將進度拖延太長時間還抱怨為什麼不能用老方法實施。你也許還會遇到一些抱有不切實際的幻想的使用者,他們希望輕點滑鼠就能實現想象中的功能,但卻不願在他們那邊多做些智力投資,更好的培訓他們自己的員工。而你也已經疲憊不堪,鼓勵投資,以及在Team Dev和使用者(甚至老闆)中推廣新的開發技巧。
總之你要保持微笑。當一切搞定,你的煩惱也就一掃而空了,笑到最後才笑得最輕鬆。