一、什么是數據倉庫
數據倉庫，英文名稱為DataWarehouse，可簡寫為DW或DWH。數據倉庫，是為企業所有級別的決策制定過程，提供所有類型數據支持的戰略集合。它出于分析性報告和決策支持目的而創建。為需要業務智能的企業，提供指導業務流程改進、監視時間、成本、質量以及控制。
1、數據倉庫的特點
- 面向主題：傳統數據庫面向應用進行數據組織的特點相對應，數據倉庫中的數據是面向主題進行組織的。面向主題的數據組織方式，就是在較高層次上對分析對象的數據的一個完整、一致的描述，能完整、統一地刻劃各個分析對象所涉及的企業的各項數據，以及數據之間的聯系。
-
集成：數據倉庫的數據是從原有的分散的數據庫數據抽取來的。操作型數據與DSS分析型數據之間差別甚大。數據進入數據倉庫之前，必然要經過統一與綜合，這一步是數據倉庫建設中最關鍵、最復雜的一步，所要完成的工作有：
（1）要統一源數據中所有矛盾之處，如字段的同名異義、異名同義、單位不統一、字長不一致，等等。
（2）進行數據綜合和計算。數據倉庫中的數據綜合工作可以在從原有數據庫抽取數據時生成，但許多是在數據倉庫內部生成的，即進入數據倉庫以后進行綜合生成的。 - 不可更新：數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一般情況下并不進行修改操作。數據倉庫的數據反映的是一段相當長的時間內歷史數據的內容，是不同時點的數據庫快照的集合，以及基于這些快照進行統計、綜合和重組的導出數據，而不是聯機處理的數據。數據庫中進行聯機處理的數據經過集成輸入到數據倉庫中，一旦數據倉庫存放的數據已經超過數據倉庫的數據存儲期限，這些數據將從當前的數據倉庫中刪去。因為數據倉庫只進行數據查詢操作，所以數據倉庫管理系統相比數據庫管理系統而言要簡單得多。數據庫管理系統中許多技術難點，如完整性保護、并發控制等等，在數據倉庫的管理中幾乎可以省去。但是由于數據倉庫的查詢數據量往往很大，所以就對數據查詢提出了更高的要求，它要求采用各種復雜的索引技術；同時由于數據倉庫面向的是商業企業的高層管理者，他們會對數據查詢的界面友好性和數據表示提出更高的要求。
-
隨時間不斷變化：這一特征表現在以下3方面：
（1）數據倉庫隨時間變化不斷增加新的數據內容。數據倉庫系統必須不斷捕捉OLTP數據庫中變化的數據，追加到數據倉庫中去，也就是要不斷地生成OLTP數據庫的快照，經統一集成后增加到數據倉庫中去；但對于確實不再變化的數據庫快照，如果捕捉到新的變化數據，則只生成一個新的數據庫快照增加進去，而不會對原有的數據庫快照進行修改。
（2）數據倉庫隨時間變化不斷刪去舊的數據內容。數據倉庫的數據也有存儲期限，一旦超過了這一期限，過期數據就要被刪除。只是數據倉庫內的數據時限要遠遠長于操作型環境中的數據時限。在操作型環境中一般只保存有60-90天的數據，而在數據倉庫中則需要保存較長時限的數據（如5~10年），以適應DSS進行趨勢分析的要求。
（3）數據倉庫中包含有大量的綜合數據，這些綜合數據中很多跟時間有關，如數據經常按照時間段進行綜合，或隔一定的時間片進行抽樣等等。這些數據要隨著時間的變化不斷地進行重新綜合。因此，數據倉庫的數據特征都包含時間項，以標明數據的歷史時期。
2、數據倉庫發展史
數據倉庫的發展大致經歷了這樣的三個過程：
（1）簡單報表階段
這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的匯總數據。這個階段的大部分表現形式為數據庫和前端報表工具。
（2）數據集市階段
這個階段，主要是根據某個業務部門的需要，進行一定的數據的采集，整理，按照業務人員的需要，進行多維報表的展現，能夠提供對特定業務指導的數據，并且能夠提供特定的領導決策數據。
（3）數據倉庫階段
這個階段，主要是按照一定的數據模型，對整個企業的數據進行采集，整理，并且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表數據，能夠通過數據倉庫生成對對業務具有指導性的數據，同時，為領導決策提供全面的數據支持。
通過數據倉庫建設的發展階段能夠看出，數據倉庫的建設和數據集市的建設的重要區別就在于數據模型的支持。
3、數據倉庫架構分層
數據倉庫標準上可以分為四層： ODS（臨時存儲層）、 PDW（數據倉庫層）、 DM（數據集市層）、 APP（應用層）
數據倉庫的標準分層只是一個建議性質的標準，實際實施時需要根據實際情況確定數據倉庫的分層，不同類型的數據也可能采取不同的分層方法。
（1）臨時存儲層/數據采集層
ODS 層的表通常包括兩類，一個用于存儲當前需要加載的數據，一個用于存儲處理完后的歷史數據。歷史數據一般保存 3-6 個月后需要清除，以節省空間。但不同的項目要區別對待，如果源系統的數據量不大，可以保留更長的時間，甚至全量保存
數據源種類可以有多種：
日志：所占份額最大，存儲在備份服務器上
業務數據庫：如Mysql、Oracle
來自HTTP/FTP的數據：合作伙伴提供的接口
其他數據源：如Excel等需要手工錄入的數據
（2）數據倉庫層
這層的數據是干凈的數據，也就是清洗后的數據，它會保存BI系統中所有歷史數據。
HDFS是大數據環境下數據倉庫/數據平臺最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，Hive是不錯的選擇。Spark性能比Hive好很多，適合做準實時計算。
（3）數據集市層
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那么就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據。
這里的數據集市，其實指的是前面數據分析與計算后的結果存放的地方，其實就是關系型數據庫和NOSQL數據庫。
這層的數據從數據的組織方式來說，通常是星形或雪花結構的數據。從數據粒度來說，是輕度匯總級的數據，已經不存在明細數據了。從數據的時間跨度來說，通常是 PDW 層的一部分，主要的目的是為了滿足用戶分析的需求，而從分析的角度來說，用戶通常只需要分析近幾年（如近三年的數據）的即可。 從數據的廣度來說，仍然覆蓋了所有業務數據。
（4）應用層
數據粒度高度匯總，倒不一定涵蓋所有業務數據，只是數據集市層數據的一個子集。
報表：報表所使用的數據，一般也是已經統計匯總好的，存放于數據共享層。
接口：接口的數據都是直接查詢數據共享層即可得到。
即席查詢：即席查詢通常是現有的報表和數據共享層的數據并不能滿足需求，需要從數據存儲層直接查詢。一般都是通過直接操作SQL得到。
4、星型模型和雪花模型
在多維分析的商業智能解決方案中，根據事實表和維度表的關系，又可將常見的模型分為星型模型和雪花型模型。在設計邏輯型數據的模型的時候，就應考慮數據是按照星型模型還是雪花型模型進行組織。
（1）星型模型
當所有維表都直接連接到“ 事實表”上時，整個圖解就像星星一樣，故將該模型稱為星型模型。
星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗余，如在地域維度表中，存在國家 A 省 B 的城市 C以及國家 A 省 B 的城市 D 兩條記錄，那么國家 A 和省 B 的信息分別存儲了兩次，即存在冗余。
（2）雪花模型
當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型。
雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的層次結構，這些被分解的表都連接到主維度表而不是事實表。
如上圖所示，將地域維表又分解為國家，省份，城市等維表。它的優點是：通過最大限度地減少數據存儲量以及聯合較小的維表來改善查詢性能。 雪花型結構去除了數據冗余。
（3）星型模型和雪花模型對比
星型模型因為數據的冗余所以很多統計查詢不需要做外部的連接，因此一般情況下效率比雪花型模型要高。 星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。雪花型模型由于去除了冗余，有些統計就需要通過表的聯接才能產生，所以效率不一定有星型模型高。正規化也是一種比較復雜的過程，相應的數據庫結構設計、數據的 ETL、以及后期的維護都要復雜一些。因此在冗余可以接受的前提下，實際運用中星型模型使用更多，也更有效率。
總之，雪花模型使得維度分析更加容易，比如“針對特定的廣告主，有哪些客戶或者公司是在線的?”星形模型用來做指標分析更適合，比如“給定的一個客戶他們的收入是多少?”
