1. 程式人生 > >資料倉庫建設失敗的主要原因

資料倉庫建設失敗的主要原因

一、國內資訊化的現狀
1、資訊化建設的發展歷史:
在國內資訊化建設過程中,基本上是按照當時業務系統的需求進行建設,例如:在一個企業中,財務部門為了減少工資發放的差錯,提高發放的效率,先建設一個工資發放和管理程式;為了報賬和核對的需求,建設一個財務管理程式;在銀行首先為了業務處理的方便,將最基本的手工記帳和處理的業務建成一個系統,過一段時間,如果有新的業務推出,就再建設一個新的系統,或在原系統的基礎上增加新的業務處理。這樣的結果使每個系統和系統之間缺少真正的資訊溝通和資訊交換。
2、為何要建立資料倉庫:
前面我們講過,業務系統各自為政,相互獨立。當很多業務系統建立後,由於領導的要求和決策的需求,需要一些指標的分析,在相應的業務系統基礎上再增加分析和相應的報表功能,這樣每個系統就增加了報表和分析功能。但是,由於資料來源不統一導致了對同一個指標分析的結果不相同。為了解決該問題,Bill Inmon提出了資料倉庫的概念,其目的是為了分析和決策的需要,將相互分離的業務系統的資料來源整合在一起,可以為領導和決策層提供分析和輔助決策。
3、國內企業對資料倉庫建設認識的誤區:
大家對資料倉庫的認識是將業務系統的資料進行資料抽取、遷移和載入(ETL),將這些資料進行整合存放在一起,統一管理,需要什麼樣的分析就可提供什麼樣的分析,這就是資料倉庫。這樣做的結果是花了一年到兩年的時間都無法將整個企業業務系統的資料整合在一起,花錢多、見效慢、風險大。一年後領導問起資料倉庫專案時,回答往往是資金不足,人力不夠,再投入一些資源、或者再延長半年的時間就會見到效果,但是往往半年過後還是僅僅可以看到十幾張或者幾十張報表。領導不滿意,專案負責人壓力也很大,無法交待。這時,專案經理或者專案負責人才意識到,專案有問題,但是誰也不敢說專案有問題,因為這樣顯然是自己當時的決策失誤。怎麼辦?尋找諮詢公司或者一些大的廠商,答案往往是資料倉庫缺乏資料模型,應該考慮資料模型。如果建設時考慮到整個企業的資料模型,就可以建設成企業級的資料倉庫(EDW)。什麼是資料模型,就是滿足整個企業分析要求的所有資料來源。結果會如何,我個人認為:這樣做企業級資料倉庫成功的可能性太小。什麼是企業級資料倉庫,這是一個相對的概念,因為企業的業務系統會在不斷的改善和升級,所以資料倉庫的建設也會不斷的完善和修改。資料倉庫的建設是一個過程,它一定伴隨著企業新的應用和企業各種各樣新的需求而逐步完成。所以從資料整合入手、從企業級資料模型入手,均會給企業資料倉庫的建設帶來很大的風險。失敗的概率太大了。
二、以應用驅動,資料倉庫建設應由後向前規劃
前面講了資料倉庫建設從資料來源入手,先進行資料整合的方法會導致失敗,特別是對資訊化建設比較快而且資料量特別大的企業。這是因為資料倉庫的理論均是講從企業級的資料整入手,建立資料倉庫。要麼是大家對Bill Inmon的理論由誤解,要麼就是資料倉庫的祖師爺害了大家。資料倉庫到底應該怎麼建設?我一貫的主張是應用驅動。什麼樣的應用呢?從企業績效管理的角度出發,一個企業最重要的四項關鍵指標為:財務指標、客戶指標、企業內部的流程指標和學習創新的指標。應用從那個開始,應考慮企業的現狀和決策層最關心的問題入手。在一般情況下,老總和董事會最關心的問題是企業的財務指標。其次是內部流程和員工績效考核,再下來是客戶的資訊和決策支援。實際上在一個企業中最先上線的系統也是企業的財務管理和業務系統,這樣相對財務分析是最容易實現的。因為資料較齊全,最完整,所以分析是較容易實現的,加之上市公司對財務報表的要求是最緊迫的。對財務分析從那入手,應該分析那些指標,這些指標通過什麼公式(數學模型)計算,這些模型需要那些資料,這些資料又來自於那些業務系統,這些資料是否在業務系統中存在,能否進行分析,也就是這些主題的分析是否可行,應該先進行評估。這樣從應用主題入手,就可以知道需要什麼樣的資料,來自那些業務系統和資料來源,這些資料的全體進行一定的整合,按照分析的要求儲存就組成了一個數據集市(Data Mart)。
三、“想大做小”(整體設計、分佈實施)
為了避免原有業務系統相對獨立而形成的一個個資訊孤島,以應用驅動建設資料倉庫,往往會造成新的資訊孤島。這是因為應用往往是部門級的或者是某一方面的應用,不能完全覆蓋企業級的所有應用。當然我們這裡不提倡一次建設企業級的應用。如何避免這個問題,是我這裡著重要要強調的。這裡分兩種情形進行設計。
1、如果該公司的資訊化建設相對較晚,或者才開始進行資訊化建設,或者原有的業務系統已經無法支援現有的業務而需要重新改造原有業務系統,均應該整體設計,將各個系統的資料來源統一存放管理,有一個統一的入口和出口。這樣就避免了資料來源的不統一而會導致資訊孤島,這樣資料倉庫的建設也就無意義了。因為企業級的資料本身就按照業務的需求和分析的需求進行設計和存放管理。在這種情況下要特別注意業務系統的安全性和效率問題。如何解決該問題,最近的網格計算正是為解決該類問題而設計的。除了統一資料來源外,可以根據企業的需要,可利用一個個小型機進行不同需求的應用,OLTP和OLAP可以在不同的伺服器上完成,同時可以將各個伺服器的資源共享、時間任務優化分配。這樣既解決了統一資料來源的問題,又解決了執行安全和效率問題( Oracle 10g就是這種思想)。
2、如果該企業是一個資訊化建設較早並且業務系統仍在應用,現在還需要大量的分析和輔助決策,那麼就應該建設資料倉庫,最少是資料集市。在設計時要考慮到企業的資料倉庫,但是在實施時應該從企業最需求的資料集市入手,要考慮到該資料集市和將來慢慢一步一步建設的資料倉庫應該共享一個數據源。方法步驟如下:
第一步、確立好應分析的主題(或專案),如客戶關係管理系統;
第二步、設定研究分析的具體問題,如客戶流失率分析,客戶貢獻度分析;
第三步、從這些問題出發,考察每個問題應使用的模型;
第四步、所有模型所需要那些資料;將所有分析問題所需要的資料按照分析的型別進行分類儲存,建立資料集市。
當完成這個專案後,如果需要建設第二個應用(系統),如資產負債系統;重複以上四步,但是在設計時一定要考慮已經存在的客戶關係管理系統,將第二個應用系統和第一個應用系統共有的資料要共享,這時應考慮兩個系統上了以後的效率問題。如果存在著效率問題,則將第一個資料集市保留,並且做一個備份作為資料倉庫的一部分,將第二個資料集市的資料來源和第一個備份的集市進行整體合併作為現在企業級資料倉庫。將第二個資料集市單獨建立,但是資料來源來自於共同的資料倉庫,這樣既保證了資料倉庫的效率,也保證了資料來源的同一性。這樣一步一步將會建成企業級的資料倉庫。
四、三分段的設計思想
在資料倉庫建設中,我們知道可以將整體的系統化分為三個大的部分:業務系統、資料倉庫、分析和展現。隨著時間的發展,這三個部分隨時都可能發生變化。比如:業務系統要進行升級改造或者重新建立核心業務系統,像銀行的第三代;像電信的BOSS系統的改造等等。需求分析也會隨著時間的發展、新的需求會不斷提出,所以在資料倉庫專案建設時一定要考慮三分段的設計思想。什麼是三分段的設計思想:就是儘量將業務系統、資料倉庫和分析展現分離設計。當業務系統發生變化時,儘量保證資料倉庫的結構不變。如何做到這一點呢,那就需要在資料遷移時使用公式體系,作為資料倉庫資料計算的公式,所以當業務系統發生變化時,可以通過對應關係將對應重新對映。關於業務系統變化,資料倉庫的一些結構必須變化的情形我們下面將討論。同樣,當資料分析展現的要求發生變化時,資料倉庫應保持相對的獨立。這樣資料倉庫才能保證有生命力。
但是當資料倉庫不得不發生變化時,是否有先進的工具可進行多維立方體的可和性計算。也就是業務系統發生變化後,有先進的工具保證資料倉庫的結構不發生變化,僅僅需要進行新的立方體計算、以及和老的立方體合併,而不需要將原資料倉庫的資料全部重新重新整理。這樣在大型企業中非常重要,因為往往一次資料重新整理需要幾天或幾十天的時間。
五、最佳實施方案
前面考慮了資料倉庫建設應該整體設計、分佈實施;從應用出發,建立資料集市;然後將資料集市擴充套件為資料倉庫。資料倉庫的設計應該注意三分段的結構。資料倉庫的建設是一個過程。那麼,最重要的問題和步驟就是:
1、如何定義主題:
在這方面,可以有兩個辦法:一是企業急需解決的問題,二是藉助於同行或者國外的先進經驗決定主題。對於第一種情況,也需要借鑑於國內外成熟和先進的經驗。需要了解成熟的主題了在國際先進的企業內成功使用的方案和工具。例如:資產負債系統、轉移定價、風險管理、客戶關係管理等。
2、主題設定後,應該分析那些問題:
這些問題也應該借鑑於成熟的方案和工具,加上具體的本企業的需求,這就是客戶化。例如在客戶關係管理系統中分析:客戶的貢獻度、客戶的流失分析和預警、客戶的忠誠度、前十位帶來效益的客戶和最後十位帶來最大損失的客戶等等;這些問題應該由企業和解決方案供應商共同討論決定。
3、這些問題應該如何定義,也就是模型或者計算公式是什麼:
當定義了這些問題後,公式該如何定義,很多的公式是標準的,可以應用公認的標準公式,對於其他非標準的公式,應該借鑑國際上先進的企業使用的公式和模型。在方案供應商是否有現成的工具和方案,不僅僅是方案,還應該有現成的可以靈活客戶化的工具或產品。
4、當定義完公式後,資料結構應如何設計:
首先要考慮公式中的資料是否在業務系統或者其他的系統中存在,如果不存在,該如何解決?如果存在,在那個系統中,如何抽取、整理和載入。資料應該以什麼樣的結構進行儲存和管理。源資料該如何設計?在這方面如果有成熟的工具和產品,將對專案的成功帶來了多半的希望。資料的儲存一定要考慮到業務系統的變化帶來的資料倉庫結構的變化,一般也要考慮到五年儲存的資料,當第六年的資料匯入時,需要將五年前的一年資料遷移到磁碟陣列或其他的儲存裝置時,如何將多維立方體分割。要考慮如何將新的業務資料增加到資料倉庫時多維立方體的可和性。
5、當解決了資料的儲存和管理後,資料倉庫應用該如何展現:
展現是使用者十分關注的問題,展現的易用性、直觀性和靈活性是十分重要的,可以採用流覽器方式,報表、圖形和多維展現或動畫。但是一定要注意速度和效率。
6、展現確定後,速度效率如何提高:
對於一個非常重要的報表,例如:現金流、資產負債表和損益表,企業的三、四位老總可能非常關心,每天或者季度初的第一天早上上班先要察看該報表的結果,第一個老總很快看到了結果,但是第二個、第三個需要三十秒、一分鐘的時間哪就無法忍受。所以系統一定要考慮做壓力測試,採用好的解決方案。如將常用的報表做上幾個備份,或者多開上幾個監聽器。為了提高效率,資料的儲存結構是十分重要的,比如對離散資料可以進行轉置儲存、對於一年都很少改變幾次的資料,如信貸資料,可以採取時間壓縮的方法等等。
7、硬體如何配置,才能保證安全性、效率問題得到圓滿的解決:
考慮了資料儲存的結構後,要考慮資料需要保留幾年,需要估計儲存資料量的大小,以保證硬體的採購和效率。
8、要考慮到資料的安全、系統的安全。
六、最佳實踐
除了以上講的以外,如果產品或者解決方案已經經過國際的認可應用,那應該是最佳實踐。比如:在銀行推廣的巴塞爾協議的應用產品就屬於最佳實踐。這些專案我們可以將應用直接拿來使用,以規範我們的管理和流程。對於一些不滿足國內應用的我們加以分析,進行調整,實現客戶化。這些應用的主題、問題和模型是經過很多實踐得來的,是可信並值得借鑑應用的。
--轉自《暢享網》。對比本文中的觀點,仁者見仁,智者見智;僅供自己及他人蔘考......