什麼是數據倉庫？
爲什麼需要數據倉庫？
傳統的數據庫中，存放的數據較多是一些定製性數據，表是二維的，一張表可以有很多字段，字段一字排開，對應的數據就一行一行寫入表中，特點就是利用二維表表現多維關係。
但這種表關係的上限和下限就定死了，比如 QQ 的用戶信息，直接通過查詢 info 表，對應的 username、introduce 等信息即可，而此時我想知道這個用戶在哪個時間段購買了什麼？修改信息的次數？諸如此類的指標時，就要重新設計數據庫的表結構，因此無法滿足我們的分析需求。
在產品腦圖中可以很清晰的看到根據業務需求設計所需的字段，因此也導致數據庫是根據業務需求進行設計。
那麼，爲什麼一開始就不考慮好這個擴展性呢？爲什麼數據庫一開始就不以數據倉庫的形式設計？
主要原因有二：
第一，數據倉庫，從字面上理解就可以感受到這是一個很大的空間，而且存儲的物品很雜，裏面會存放醬油、沐浴露、洗髮精等物品，而數據庫是存放醬油、鹽等廚房用品，洗浴又是一個數據庫。
第二，國內互聯網的發展，一開始大家都是做個軟件出來，大家一起用，這個時候只要滿足的了需求即可，現今不止是需求還有用戶的體驗等各種方面，需要根據這些分析指標做調整。
小結：
數據庫是跟業務掛鉤的，因此數據庫的設計通常是針對一個應用進行設計的。
數據倉庫是依照分析需求、分析維度、分析指標進行設計的。
什麼是數據倉庫？
數據倉庫（Data Warehouse）簡稱 DW 或 DWH，是數據庫的一種概念上的升級，可以說是爲滿足新需求設計的一種新數據庫，而這個數據庫是需容納更多的數據，更加龐大的數據集，從邏輯上講數據倉庫和數據庫是沒有什麼區別的。
爲企業所有級別的決策制定過程，提供所有類型數據支撐的戰略集合，主要是用於數據挖掘和數據分析，以建立數據沙盤爲基礎，爲消滅消息孤島和支持決策爲目的而創建的。
數據倉庫發展過程
2000年初，國內是簡單的報表階段，這個階段主要是彙總一些數據，解決業務人員想要的報表。
如：銷售額：xxx萬元、銷售量：20000件
2010年，數據集市階段，進行一定的數據採集、整理，按照某業務部門的需求進行採集、整理，按照業務人員需要，進行多維度報表的展現，能夠提供特定的領導決策數據。
如：1月~3月銷售額：xxx萬元、4月~6月銷售額：xxx萬元
2015年，各大公司開始注重用戶體驗，物流效率等問題，這個時候進入數據倉庫階段，主要按照數據模型，對整個企業的數據進行採集、整理，提供跨部門，完整一致性的業務報表數據，能夠通過數據倉庫生成對業務具有指導性的數據，爲決策者提供更全面的數據。
如：某個月某個地區的用戶數量下降，某個月某個地區的用戶數量上升。
數據倉庫特點
面向主題
是企業系統信息中的數據綜合、歸類並進行分析的一個抽象，對應企業中某一個宏觀分析領域所涉及的分析對象。
比如購物是一個主題，那麼購物裏面包含用戶、訂單、支付、物流等數據綜合，對這些數據要進行歸類並分析，分析這個對象數據的一個完整性、一致性的描述，能完整、統一的劃分對象所設計的各項數據。
如果此時要統計一個用戶從瀏覽到支付完成的時間時，在購物主題中缺少了支付數據或訂單數據，那麼這個對象數據的完整性和一致性就可能無法保證了。
數據集成
數據倉庫的數據是從原有分散的數據庫中的數據抽取而來的。
操作型數據和支持決策分析型（DSS）數據差別甚大，這裏需要做大量的數據清洗與數據整理的工作。
第一：每一個主題的源數據在原有分散數據庫中的有許多重複和不一致，且不同數據庫的數據是和不同的應用邏輯捆綁的。
第二：數據倉庫中的綜合性數據不能從原有的數據庫系統直接得到，因此在數據進入數據倉庫之前要進過統一和綜合。（字段同名異意，異名同義，長度等）
不可更新
數據倉庫的數據主要是提供決策分析用，設計的數據主要是數據查詢，一般情況下不做修改，這些數據反映的是一段較長時間內歷史數據的內容，有一塊修改了影響的是整個歷史數據的過程數據。
數據倉庫的查詢量往往很大，所以對數據查詢提出了更高的要求，要求採用各種複雜的索引技術，並對數據查詢的界面友好性和數據凸顯性提出更高的要求。
隨時間不斷變化
數據倉庫中的數據不可更新是針對應用來說，從數據的進入到刪除的整個生命週期中，數據倉庫的數據是永遠不變的。
數據倉庫的數據是隨着時間變化而不斷增加新的數據。
數據倉庫隨着時間變化不斷刪去久的數據內容，數據倉庫的數據也有時限的，數據庫的數據時限一般是60 ~ 90天，而數據倉庫的數據一般是5年~10年。
數據倉庫中包含大量的綜合性數據，這些數據很多是跟時間有關的，這些數據特徵都包含時間項，以標明數據的歷史時期。
數據倉庫和數據庫的區別
數據庫的操作：
一般稱爲聯機事務處理OLTP（On-Line Transaction Processing），是針對具體的業務在數據庫中的聯機操作，具有數據量較少的特點，通常對少量的數據記錄進行查詢、修改。
數據倉庫的操作：
一般稱爲聯機分析處理OLAP（On-Line Analytical Processing），是針對某些主題（綜合數據）的歷史數據進行分析，支持管理決策。
|
比較項 |
數據庫，操作型（OLTP） |
數據倉庫，分析性（OLAP） |
|
關注 |
細節 |
綜合或提煉 |
|
模型 |
實體 – 關係（E-R） |
星型或雪花 |
|
操作 |
可更新 |
只讀，只追加 |
|
操作粒度 |
操作一個單元 |
操作一個集合 |
|
場景 |
面向事務 |
面向分析 |
|
數據量 |
小 |
大 |
|
需求 |
日常操作 |
決策需求 |
|
業務方向 |
客戶信息、訂單等查詢 |
客戶登錄間隔時間，市場細分等 |
數據倉庫常用系統架構
ODS層（臨時存儲層）：
這一層做的工作是貼源，而這些數據和源系統的數據是同構，一般對這些數據分爲全量更新和增量更新，通常在貼源的過程中會做一些簡單的清洗，
DW層（數據倉庫層）：
將一些數據關聯的日期進行拆分，使得其更具體的分類，一般拆分成年、月、日，而 ODS 層到 DW 層的 ETL 腳本會根據業務需求對數據進行清洗、設計，如果沒有業務需求，則根據源系統的數據結構和未來的規劃去做處理，對這層的數據要求是一致、準確、儘量建立數據的完整性。
APP層（引用層）：
提供報表和數據沙盤展示所需的數據。
爲什麼要分層？
在未分層的情況下，數據之間的耦合性與業務耦合性是不可避免的，當源業務系統的業務規則發生變化時，可能影響整個數據的清洗過程。
數據分層簡化了數據清洗的過程，每一層的邏輯變得更加簡單和易於理解，當發生錯誤或規則變化時，只需要進行局部調整。
通過大量的預處理來提升應用系統查詢速度，進而提升的用戶體驗，因此數據倉庫會冗餘大量的數據，是典型的空間換時間的策略。
元數據
在操作數據倉庫時，操作的都是元數據，而元數據分爲技術元數據和業務元數據。
技術元數據：是指數據倉庫開發、管理、維護相關的數據，描述了數據的原信息，轉換描述、數據映射、訪問權限等。
業務元數據：爲管理層和業務分析人員服務，從業務的角度描述數據，包括行業術語、數據的可用性、數據的意義等。
元數據的存儲有常用的兩種，一種是以數據集爲基礎，每一個數據集有對應的元數據文件，每一個元數據文件對應數據集的元數據內容，另一種是以數據庫爲基礎，由若干項組成，每一項標識元數據的一個元素。
爲什麼需要爲數據倉庫建模？
進行全面的業務梳理時，我們可以通過業務模型，全面瞭解業務結構及運行情況，按照業務特定的規律分門別類和程序化，改進業務的流程。
通過模型的建設，我們可以很清晰的看到數據之間內在的關聯關係，從而建立起全方位的數據視角，並消滅信息孤島和數據差異化的問題，進而保證數據的一致性。
模型可以很好的幫助我們分離出底層技術的實現和上層業務的展現，當上層業務發生變化時，通過數據模型，底層的技術實現可以適應的了業務的變動，進而解決數據庫的靈活性。
在模型中可以很好的看出開發人員和業務人員之間的系統建設範圍的界定，及未來的規劃。
什麼是數據模型？
數據模型是數據關係的一種映射， 就是將業務之間的關係，用模型圖形化的描繪出來，而不再是腦海的一個模糊的關係。
在設計數據倉庫模型和架構時，我們需要懂具體的技術，也需要了解行業的知識和經驗來幫助我們對業務進行抽象、處理，進而生成各個階段的模型。
數據模型架構
在大體上，我們將數據模型分爲5大塊。
系統記錄域：數據倉庫業務數據存儲區，保證數據的一致性。
內部管理域：用於內部管理的元數據，統一的元數據管理。
彙總域：這裏的數據來自系統記錄域的彙總，保證分析域的主題分析性能，滿足部分報表查詢。
分析域：各個業務部分的具體主題業務分析，可以單獨存儲在相應的數據集市中。
反饋域：用於相應的前端的反饋數據，視業務的需要設置這個域。
維度和指標（度量）
維度和指標時數據分析領域常用的概念，亦是在設計數據倉庫過程中需要考慮的。
維度就是數據的觀察角度，即從哪個角度去分析問題，看待問題。
指標（度量）就是從維度的基礎上去衡算這個結果的值。
維度一般是一個離散的值，比如時間維度上每一個獨立的日期或地域，因此統計時，可以把維度相同記錄的聚合在一起，應用聚合函數做累加、均值、最大值、最小值等聚合計算。
指標（度量）就是被聚合的通計算，即聚合運算的結果，一般是一個連續的值。
比如我們可以從銀行的存款額和企業的貸款額之間的計算，推算出目前的市場狀況是如何，如果企業的貸款額高，銀行的存款額也高，說明人們不願意消費了，都把錢存起來，企業產品賣不出去，要發工資，那麼自然要貸款了，這只是一個例子，具體還需要結合很多數據做分析。
事實表和維度表
事實表和維度表是在設計數據倉庫過程中需要考慮的。
事實表（Fact Table）是指存儲有事實記錄的表，如系統的日誌、銷售記錄、用戶訪問日誌等信息，事實表的記錄是動態的增長的，所以體積是大於維度表。
用戶訪問日誌（事實表）：用戶名、url、時間…
維度表（Dimension Table）也稱爲查找表（Lookup Table）是與事實表相對應的表，這個表保存了維度的屬性值，可以跟事實表做關聯，相當於是將事實表中經常重複的數據抽取、規範出來用一張表管理，常見的有日期（日、周、月、季度等屬性）、地區表等，所以維度表的變化通常不會太大。
維度表的存在縮小了事實表的大小，便於維度的管理和CURD維度的屬性，不必對事實表的大量記錄進行改動，並且可以給多個事實表重用。
省份表（維度表）：北京市、廣東省、上海市…
數據模型建立過程
業務模型：業務分解和程序化，確定好業務的邊界及業務流程，如訂單、支付都是一個單獨的業務模塊
領域模型：業務概念的抽象、分組，整理分組之間的關聯，比如用戶購物的業務，抽成一個更大的模型，這個模型一般相對於行業。
邏輯建模：領域模型中的業務概念實體化，並考慮實體的具體屬性及實體與實體之間的關係，比如訂單（訂單號、付款人…）和支付（金額、支付時間…）的關係。
物理模型：解決實際應用的落地開發、上線等問題，及性能等一些具體的技術問題。
參考：