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