1.1 什么是數據倉庫

數據倉庫的概念可以追溯到20世紀80年代，當時IBM的研究人員開發出了“商業數據倉庫”。本質上，數據倉庫試圖提供一種從操作型系統到決策支持環境的數據流架構模型。數據倉庫概念的提出，是為了解決和這個數據流相關的各種問題，主要是解決多重數據復制帶來的高成本問題。在沒有數據倉庫的時代，需要大量的冗余數據來支撐多個決策支持環境。在大組織里，多個決策支持環境獨立運作是典型的情況。盡管每個環境服務于不同的用戶，但這些環境經常需要大量相同的數據。處理過程收集、清洗、整合來自多個數據源的數據，并為每個決策支持環境做部分數據復制。數據源通常是早已存在的操作型系統，很多是遺留系統。此外，當一個新的決策支持環境形成時，操作型系統的數據經常被再次復用。用戶訪問這些處理后的數據。

1.1.1 數據倉庫的定義

數據倉庫之父Bill Inmon在1991年出版的Building the Data Warehouse 一書中首次提出了被廣為認可的數據倉庫定義。Inmon將數據倉庫描述為一個面向主題的、集成的、隨時間變化的、非易失的數據集合，用于支持管理者的決策過程。這個定義有些復雜并且難以理解。下面我們將它分解開來進行說明。

● 面向主題

傳統的操作型系統是圍繞組織的功能性應用進行組織的，而數據倉庫是面向主題的。主題是一個抽象概念，簡單地說就是與業務相關的數據的類別，每一個主題基本對應一個宏觀的分析領域。數據倉庫被設計成輔助人們分析數據。例如，一個公司要分析銷售數據，就可以建立一個專注于銷售的數據倉庫，使用這個數據倉庫，就可以回答類似于“去年誰是我們這款產品的最佳用戶”這樣的問題。這個場景下的銷售，就是一個數據主題，而這種通過劃分主題定義數據倉庫的能力，就使得數據倉庫是面向主題的。主題域是對某個主題進行分析后確定的主題的邊界，如客戶、銷售、產品都是主題域的例子。

● 集成

集成的概念與面向主題是密切相關的。還用銷售的例子，假設公司有多條產品線和多種產品銷售渠道，而每個產品線都有自己獨立的銷售數據庫。此時要想從公司層面整體分析銷售數據，必須將多個分散的數據源統一成一致的、無歧義的數據格式后，再放置到數據倉庫中。因此數據倉庫必須能夠解決諸如產品命名沖突、計量單位不一致等問題。當完成了這些數據整合工作后，該數據倉庫就可稱為是集成的。

● 隨時間變化

為了發現業務變化的趨勢、存在的問題，或者新的機會，需要分析大量的歷史數據。這與聯機事務處理（OLTP）系統形成鮮明的對比。聯機事務處理反應的是當前時間點的數據情況，要求高性能、高并發和極短的響應時間，出于這樣的需求考慮，聯機事務處理系統中一般都將數據依照活躍程度分級，把歷史數據遷移到歸檔數據庫中。而數據倉庫關注的是數據隨時間變化的情況，并且能反映在過去某個時間點的數據是怎樣的。換句話說，數據倉庫中的數據是反映了某一歷史時間點的數據快照，這也就是術語“隨時間變化”的含義。當然，任何一個存儲結構都不可能無限擴展，數據也不可能只入不出地永久駐留在數據倉庫中，它在數據倉庫中也有自己的生命周期。到了一定時候，數據會從數據倉庫中移除。移除的方式可能是將細節數據匯總后刪除、將老的數據轉儲到大容量介質后刪除和直接物理刪除等。

● 非易失

非易失指的是，一旦進入到數據倉庫中，數據就不應該再有改變。操作型環境中的數據一般都會頻繁更新，而在數據倉庫環境中一般并不進行數據更新。當改變的操作型數據進入數據倉庫時會產生新的記錄，這樣就保留了數據變化的歷史軌跡。也就是說，數據倉庫中的數據基本是靜態的。這是一個不難理解的邏輯概念。數據倉庫的目的就是要根據曾經發生的事件進行分析，如果數據是可修改的，將使歷史分析變得沒有意義。

除了以上四個特性外，數據倉庫還有一個非常重要的概念就是粒度。粒度問題遍布于數據倉庫體系結構的各個部分。粒度是指數據的細節或匯總程度，細節程度越高，粒度級別越低。例如，單個事務是低粒度級別，而全部一個月事務的匯總就是高粒度級別。

數據粒度一直是數據倉庫設計需要重點思考的問題。在早期的操作型系統中，當細節數據被更新時，幾乎總是將其存放在最低粒度級別上；而在數據倉庫環境中，通常都不這樣做。例如，如果數據被裝載進數據倉庫的頻率是每天一次，那么一天之內的數據更新將被忽略。

粒度之所以是數據倉庫環境的關鍵設計問題，是因為它極大地影響數據倉庫的數據量和可以進行的查詢類型。粒度級別越低，數據量越大，查詢的細節程度越高，查詢范圍越廣泛，反之亦然。

大多數情況下，數據會以很低的粒度級別進入數據倉庫，如日志類型的數據或單擊流數據，此時應該對數據進行編輯、過濾和匯總，使其適應數據倉庫環境的粒度級別。如果得到的數據粒度級別比數據倉庫的高，那將意味著在數據存入數據倉庫前，開發人員必須花費大量設計和資源來對數據進行拆分。

1.1.2 建立數據倉庫的原因

現在你應該已經熟悉了數據倉庫的概念，那么數據倉庫里的數據從哪里來呢？通常數據倉庫的數據來自各個業務應用系統。業務系統中的數據形式多種多樣，可能是Oracle、MySQL、SQL Server等關系數據庫里的結構化數據，可能是文本、CSV等平面文件或Word、Excel文檔中的非結構化數據，還可能是HTML、XML等自描述的半結構化數據。這些業務數據經過一系列的數據抽取、轉換、清洗，最終以一種統一的格式裝載進數據倉庫。數據倉庫里的數據作為分析用的數據源，提供給后面的即席查詢、分析系統、數據集市、報表系統、數據挖掘系統等。

從以上描述可以看到，從存儲的角度看，數據倉庫里的數據實際上已經存在于業務應用系統中，那么為什么不能直接操作業務系統中的數據用于分析，而要使用數據倉庫呢？實際上在數據倉庫技術出現前，有很多數據分析的先驅者已經發現，簡單的“直接訪問”方式很難良好工作，這樣做的失敗案例數不勝數。下面列舉一些直接訪問業務系統無法工作的原因：

● 某些業務數據由于安全或其他因素不能直接訪問。

● 業務系統的版本變更很頻繁，每次變更都需要重寫分析系統并重新測試。

● 很難建立和維護匯總數據來源于多個業務系統版本的報表。

● 業務系統的列名通常是硬編碼，有時僅僅是無意義的字符串，這讓編寫分析系統更加困難。

● 業務系統的數據格式，如日期、數字的格式不統一。

● 業務系統的表結構為事務處理性能而優化，有時并不適合查詢與分析。

● 沒有適當的方式將有價值的數據合并進特定應用的數據庫。

● 沒有適當的位置存儲元數據。

● 用戶需要看到的顯示數據字段，有時在數據庫中并不存在。

● 通常事務處理的優先級比分析系統高，所以如果分析系統和事務處理運行在同一硬件之上，分析系統往往性能很差。

● 有誤用業務數據的風險。

● 極有可能影響業務系統的性能。

盡管需要增加軟硬件的投入，但建立獨立數據倉庫與直接訪問業務數據相比，無論是成本還是帶來的好處，這樣做都是值得的。隨著處理器和存儲成本的逐年降低，數據倉庫方案的優勢更加明顯，在經濟上也更具可行性。

無論是建立數據倉庫還要實施別的項目，都要從時間、成本、功能等幾個角度權衡比較，認真研究一下是否真正需要一個數據倉庫，這是一個很好的問題。當你的組織很小，人數很少，業務單一，數據量也不大，可能你真的不需要建立數據倉庫。畢竟要想成功建立一個數據倉庫并使其發揮應有的作用還是很有難度的，需要大量的人、財、物力，并且即便花費很大的代價完成了數據倉庫的建設，在較短一段時間內也不易顯現出價值。在沒有專家介入而僅憑組織自身力量建立數據倉庫時，還要冒相當大的失敗風險。但是，當你所在的組織有超過1000名雇員，有幾十個部門的時候，它所面臨的挑戰將是完全不同的。在這個充滿競爭的時代，做出正確的決策對一個組織至關重要。而要做出最恰當的決策，僅依據對孤立維度的分析是不可能實現的。這時必須要考慮所有相關數據的可用性，而這個數據最好的來源就是一個設計良好的數據倉庫。

假設一個超市連鎖企業，在沒有實現數據倉庫的情況下，最終該企業會發現，要分析商品銷售情況是非常困難的，比如哪些商品被售出，哪些沒有被售出，什么時間銷量上升，哪個年齡組的客戶傾向于購買哪些特定商品等這些問題都無從回答。而給出這些問題的正確答案正是一個具有吸引力的挑戰。這只是第一步，必須要搞清楚一個特定商品到底適不適合18～25歲的人群，以決定該商品的銷售策略。一旦從數據分析得出的結論是銷售該商品的價值在降低，那么必須實施后面的步驟分析在哪里出了問題，并采取相應的措施加以改進。

在輔助戰略決策層面，數據倉庫的重要性更加凸顯。作為一個企業的經營者或管理者，他必須對某些問題給出答案，以獲得超越競爭對手的額外優勢。回答這些問題對于基本的業務運營可能不是必需的，但對于企業的生存發展卻必不可少。下面是一些常見問題的例子：

● 如何把公司的市場份額提升5%？

● 哪些產品的市場表現不令人滿意？

● 哪些代理商需要銷售政策的幫助？

● 提供給客戶的服務質量如何？哪些需要改進？

回答這些戰略性問題的關鍵一環就是數據倉庫。就拿“提供給客戶的服務質量如何？”這一問題來說，這是管理者最為關心的問題之一。我們可以把這一問題分解成許多具體的小問題，比如第一個問題是，在過去半年中，收到過多少用戶反饋？可以在數據倉庫上發出對應的查詢，并對查詢結果進行分析。之所以能夠這樣做，是因為數據倉庫中含有每一條用戶反饋信息。

你可能已經想到了，第二個問題自然就是，在這些用戶反饋當中，給出“非常滿意”“一般”“不滿意”的人數分別有多少？下面的問題就是客戶所強調的需要改進的地方和廣受批評的地方是哪些？這在數據倉庫的用戶反饋信息中也有一列來表示，它也能從一個側面反映出客戶關心的問題是哪些。以上這三個問題的答案聯合在一起，就可以得出客戶服務滿意度的結論，并且準確定位哪些地方急需改進。

下面簡單總結一下使用數據倉庫的好處：

● 將多個數據源集成到單一數據存儲，因此可以使用單一數據查詢引擎展示數據。

● 緩解在事務處理數據庫上因執行大查詢而產生的資源競爭問題。

● 維護歷史數據。

● 通過對多個源系統的數據整合，使得在整個企業的角度存在統一的中心視圖。

● 通過提供一致的編碼和描述，減少或修正壞數據問題，提高數據質量。

● 一致性地表示組織信息。

● 提供所有數據的單一通用數據模型，而不用關心數據源。

● 重構數據，使數據對業務用戶更有意義。

● 向復雜分析查詢交付優秀的查詢性能，同時不影響操作型系統。

● 開發決策型查詢更簡單。