如何建設數據倉庫？

01-06

1.系統分析，確定主題

建立數據倉庫的第一個步驟就是通過與業務部門的充分交流，了解建立數據倉庫所要解決的問題的真正含義，確定各個主題下的查詢分析要求。

業務人員往往會羅列出很多想解決的問題，信息部門的人員應該對這些問題進行分類匯總，確定數據倉庫所實現的業務功能。一旦確定問題以後，信息部門的人員還需要確定一下幾個因素：

·操作出現的頻率，即業務部門每隔多長時間做一次查詢分析。

·在系統中需要保存多久的數據，是一年、兩年還是五年、十年。

·用戶查詢數據的主要方式，如在時間維度上是按照自然年，還是財政年。

·用戶所能接受的響應時間是多長、是幾秒鐘，還是幾小時。

由於雙方在理解上的差異，確定問題和了解問題可能是一個需要多次往複的過程，信息部門的人員可能需要做一些原型演示給業務部門的人員看，以最終確定系統將要實現的功能確實是業務部門所需要的。

2.選擇滿足數據倉庫系統要求的軟體平台

在數據倉庫所要解決的問題確定後，第二個步驟就是選擇合適的軟體平台，包括資料庫、建模工具、分析工具等。這裡有許多因素要考慮，如系統對數據量、響應時間、分析功能的要求等，以下是一些公認的選擇標準：

·廠商的背景和支持能力，能否提供全方位的技術支持和諮詢服務。

·資料庫對大數據量（TB級）的支持能力。

·資料庫是否支持並行操作。

·能否提供數據倉庫的建模工具，是否支持對元數據的管理。

·能否提供支持大數據量的數據載入、轉換、傳輸工具（ETT）。

·能否提供完整的決策支持工具集，滿足數據倉庫中各類用戶的需要。

3.建立數據倉庫的邏輯模型

具體步驟如下：

（1）確定建立數據倉庫邏輯模型的基本方法。

（2）基於主題視圖，把主題視圖中的數據定義轉到邏輯數據模型中。

（3）識別主題之間的關係。

（4）分解多對多的關係。

（5）用範式理論檢驗邏輯數據模型。

（6）由用戶審核邏輯數據模型。

4.邏輯數據模型轉化為數據倉庫數據模型

具體步驟如下：

（1）刪除非戰略性數據：數據倉庫模型中不需要包含邏輯數據模型中的全部數據項，某些用於操作處理的數據項要刪除。

（2）增加時間主鍵：數據倉庫中的數據一定是時間的快照，因此必須增加時間主鍵。

（3）增加派生數據：對於用戶經常需要分析的數據，或者為了提高性能，可以增加派生數據。

（4）加入不同級別粒度的匯總數據：數據粒度代表數據細化程度，粒度越大，數據的匯總程度越高。粒度是數據倉庫設計的一個重要因素，它直接影響到駐留在數據倉庫中的數據量和可以執行的查詢類型。顯然，粒度級別越低，則支持的查詢越多；反之，能支持的查詢就有限。

對數據操作的效率與能得到數據的詳細程度是一對矛盾，通常，人們希望建成的系統既有較高的效率，又能得到所需的詳細資料。實施數據倉庫的一個重要原則就是不要試圖包括所有詳細數據，因為90%的分析需求是在匯總數據上進行的。試圖將粒度細化到最低層，只會增加系統的開銷，降低系統的性能。5.數據倉庫數據模型優化

數據倉庫設計時，性能是一項主要考慮因素。在數據倉庫建成後，也需要經常對其性能進行監控，並隨著需求和數據量的變更進行調整。

優化數據倉庫設計的主要方法是：

·合併不同的數據表。

·通過增加匯總表避免數據的動態匯總。

·通過冗餘欄位減少表連接的數量，不要超過3~5個。

·用ID代碼而不是描述信息作為鍵值。

·對數據表做分區。

6.數據清洗轉換和傳輸

由於業務系統所使用的軟硬體平台不同，編碼方法不同，業務系統中的數據在載入到數據倉庫之前，必須進行數據的清洗和轉換，保證數據倉庫中數據的一致性。

在設計數據倉庫的數據載入方案時，必須考慮以下幾項要求：

·載入方案必須能夠支持訪問不同的資料庫和文件系統。

·數據的清洗、轉換和傳輸必須滿足時間要求，能夠在規定的時間範圍內完成。

·支持各種轉換方法，各種轉換方法可以構成一個工作流。

·支持增量載入，只把自上一次載入以來變化的數據載入到數據倉庫。

7.開發數據倉庫的分析應用

建立數據倉庫的最終目的是為業務部門提供決策支持能力，必須為業務部門選擇合適的工具實現其對數據倉庫中的數據進行分析的要求。

信息部門所選擇的開發工具必須能夠：

·滿足用戶的全部分析功能要求。數據倉庫中的用戶包括了企業中各個業務部門，他們的業務不同，要求的分析功能也不同。如有的用戶只是簡單的分析報表，有些用戶則要求做預測和趨勢分析。

·提供靈活的表現方式。分析的結果必須能夠以直觀、靈活的方式表現，支持複雜的圖表。使用方式上，可以是客戶機/伺服器方式，也可以是瀏覽器方式。

事實上，沒有一種工具能夠滿足數據倉庫的全部分析功能需求，一個完整的數據倉庫系統的功能可能是由多種工具來實現，因此必須考慮多個工具之間的介面和集成性問題，對於用戶來說，希望看到的是一致的界面。

8.數據倉庫的管理

只重視數據倉庫的建立，而忽視數據倉庫的管理必然導致數據倉庫項目的失敗。數據倉庫管理主要包括資料庫管理和元數據管理。

資料庫管理需要考以下幾個方面：

·安全性管理。數據倉庫中的用戶只能訪問到他的授權範圍內的數據，數據在傳輸過程中的加密策略。

·數據倉庫的備份和恢復。數據倉庫的大小和備份的頻率直接影響到備份策略。

·如何保證數據倉庫系統的可用性，硬體還是軟體方法。

·數據老化。設計數據倉庫中數據的存放時間周期和對過期數據的老化方法，如歷史數據只保存匯總數據，當年數據保存詳細記錄。

然而，元數據管理貫穿於整個系統的建設過程中，元數據是描述數據的數據。在數據採集階段，元數據主要包括下列信息：

·源數據的描述定義：類型、位置、結構。

·數據轉換規則：編碼規則、行業標準。

·目標數據倉庫的模型描述：星型/雪花模型定義，維/事實結構定義。

·源數據到目標數據倉庫的映射關係：函數/表達式定義。

·代碼：生成轉換程序、自動載入程序等。

在數據管理階段，元數據主要包括下列信息：

·匯總數據的描述：匯總/聚合層次、物化視圖結構定義。

·歷史數據存儲規則：位置、存儲粒度。

·多維數據結構描述：立方體定義、維結構、度量值、鑽取層次定義等。

在數據展現階段，元數據主要包括以下信息：

·報表的描述：報表結構的定義。

·統計函數的描述：各類統計分析函數的定義。

·結果輸出的描述：圖、表輸出的定義。

元數據不但是獨立存放，而且對用戶是透明的，標準元數據之間可以互相轉換。

歡迎登錄長風網獲取最新物流資訊。

一，解決什麼問題？實際存在的業務問題，領導的KPI問題，現在沒有提出未來可能出現的問題，這是數據倉庫建立的核心所在。方法：調研。業務人員，領導方不管溝通，不斷調研。輸出問題清單。

具體業務人員：源端目標端資料庫有哪些？業務數據有哪些？業務報表需求有哪些？數據質量是否有問題？各個業務部門的數據字典是否一致？...
領導：期望，預算，想法？

二，概要設計可落地方案階段。應用技術應用工具如何解決如上問題。是自研開發還是購買現成的BI產品？不管是哪一種，都要輸出解決問題的技術方案文檔。

三，詳細設計落地開發階段。DW的建模大同小異，ODS、DW、DM層、報表展現層……每一層目的，如何實現？哪些表哪些數據哪些欄位……

抽取裝載清洗轉換
建模：OLAP建模
報表設計。

四，用戶測試驗證階段

大概如上幾個步驟，但是很多技術細節都要反覆磋商。

資料庫建模設計需要實踐經驗沉澱。好的數據倉庫架構師不可多得。

聊，找各個有數據需求的部門的姑娘們負責人們聊，把要的東西聊透，匯總，提煉，統一建模，考慮擴展，然後ETL，小規模試驗，展示，迭代，加班。。。

數據分層：Ods，edw,dm,app