數倉建設中最經常使用模型--Kimball維度建模詳解

數倉建模首推書籍《數據倉庫工具箱：維度建模權威指南》，本篇文章參考此書而做。
文章首發公衆號：五分鐘學大數據，公衆號中發送「維度建模」便可獲取此書籍第三版電子書

先來介紹下此書，此書是基於做者 60 多年的實際業務環境而總結的經驗及教訓，爲讀者提供正式的維度設計和開發技術。面向數倉和BI設計人員，書中涉及到的內容很是普遍，圍繞一系列的商業場景或案例研究進行組織。強烈建議買一本實體書研究，反覆通讀全書至少三遍以上，你的技術將會有質的飛躍。

由於本文是純理論知識，密密麻麻的字，不少人可能看不下去，因此我儘可能用最少的字來表達，儘可能將晦澀難懂的詞語轉化爲通俗易於理解的詞，將文中的重點加粗展現，內容儘可能精簡，以保證在不表達錯誤的狀況下更利於讀者學習！但願和你們能一塊兒學習，一塊兒進步，努力到達咱們本身的金字塔頂部

維度建模是什麼

維度模型是數據倉庫領域大師Ralph Kimball 所倡導，以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，所以它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。

維度建模是 數據倉庫/商業智能 項目成功的關鍵，爲何這麼說，由於無論咱們的數據量從GB到TG仍是到PB，雖然數據量愈來愈大，可是數據展示要得到成功，就必須創建在簡單性的基礎之上，而維度建模就是時刻考慮如何可以提供簡單性，以業務爲驅動，以用戶理解性和查詢性能爲目標。

維度建模：維度建模是專門應用於分析型數據庫、數據倉庫、數據市集建模的方法。數據市集能夠理解爲一種「小型的數據倉庫」
維度建模指導咱們在數據倉庫中如何建表

維度建模分爲兩種表：事實表和維度表

1. 事實表：必然存在的一些數據，像採集的日誌文件，訂單表，均可以做爲事實表
   特徵：是一堆主鍵的集合，每一個主鍵對應維度表中的一條記錄，客觀存在的，根據主題肯定出須要使用的數據
2. 維度表：維度就是所分析的數據的一個量，維度表就是以合適的角度來建立的表，分析問題的一個角度：時間、地域、終端、用戶等角度

維度建模的三種模式

1. 星形模式：以事實表爲中心，全部的維度表直接連在事實表上，最簡單最經常使用的一種

2. 雪花模式：雪花模式的維度表能夠擁有其餘的維度表，這種表不易維護，通常不推薦使用

3. 星座模型：基於多張事實表，並且共享維度信息，即事實表之間能夠共享某些維度表

維度建模怎麼建

咱們知道事實表，維度表，星形模型，星座模型這些概念了，可是實際業務中，給了咱們一堆數據，咱們怎麼拿這些數據進行數倉建設呢，數倉工具箱做者根據自身60多年的實際業務經驗，給咱們總結了以下四步，請務必記住！

數倉工具箱中的維度建模四步走：

請牢記以上四步，無論什麼業務，就按照這個步驟來，順序不要搞亂，由於這四步是環環相扣，步步相連。下面詳細拆解下每一個步驟怎麼作

一、選擇業務過程
維度建模是緊貼業務的，因此必須以業務爲根基進行建模，那麼選擇業務過程，顧名思義就是在整個業務流程中選取咱們須要建模的業務，根據運營提供的需求及往後的易擴展性等進行選擇業務。好比商城，整個商城流程分爲商家端，用戶端，平臺端，運營需求是總訂單量，訂單人數，及用戶的購買狀況等，咱們選擇業務過程就選擇用戶端的數據，商家及平臺端暫不考慮。業務選擇很是重要，由於後面全部的步驟都是基於此業務數據展開的。

二、聲明粒度
先舉個例子：對於用戶來講，一個用戶有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那麼與用戶粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比用戶粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關係就是相同粒度。爲何要提相同粒度呢，由於維度建模中要求咱們，在同一事實表中，必須具備相同的粒度，同一事實表中不要混用多種不一樣的粒度，不一樣的粒度數據創建不一樣的事實表。而且從給定的業務過程獲取數據時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，由於原子粒度可以承受沒法預期的用戶查詢。可是上卷彙總粒度對查詢性能的提高很重要的，因此對於有明確需求的數據，咱們創建針對需求的上卷彙總粒度，對需求不明朗的數據咱們創建原子粒度。

三、確認維度
維度表是做爲業務分析的入口和描述性標識，因此也被稱爲數據倉庫的「靈魂」。在一堆的數據中怎麼確認哪些是維度屬性呢，若是該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性每每是維度屬性，數倉工具箱中告訴咱們緊緊掌握事實表的粒度，就能將全部可能存在的維度區分開，而且要確保維度表中不能出現重複數據，應使維度主鍵惟一

四、確認事實
事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱爲粒度。維度建模的核心原則之一是同一事實表中的全部度量必須具備相同的粒度。這樣能確保不會出現重複計算度量的問題。有時候每每不能肯定該列數據是事實屬性仍是維度屬性。記住最實用的事實就是數值類型和可加類事實。因此能夠經過分析該列是不是一種包含多個值並做爲計算的參與者的度量，這種狀況下該列每每是事實。

事實表種類

事實表分爲如下6類：

1. 事務事實表
2. 週期快照事實表
3. 累積快照事實表
4. 無事實的事實表
5. 彙集事實表
6. 合併事實表

簡單解釋下每種表的概念：

• 事務事實表

表中的一行對應空間或時間上某點的度量事件。就是一行數據中必須有度量字段，什麼是度量，就是指標，好比說銷售金額，銷售數量等這些可加的或者半可加就是度量值。另外一點就是事務事實表都包含一個與維度表關聯的外鍵。而且度量值必須和事務粒度保持一致。

• 週期快照事實表

顧名思義，週期事實表就是每行都帶有時間值字段，表明週期，一般時間值都是標準週期，如某一天，某周，某月等。粒度是週期，而不是個體的事務，也就是說一個週期快照事實表中數據能夠是多個事實，可是它們都屬於某個週期內。

• 累計快照事實表

週期快照事實表是單個週期內數據，而累計快照事實表是由多個週期數據組成，每行彙總了過程開始到結束之間的度量。每行數據至關於管道或工做流，有事件的起點，過程，終點，而且每一個關鍵步驟都包含日期字段。如訂單數據，累計快照事實表的一行就是一個訂單，當訂單產生時插入一行，當訂單發生變化時，這行就被修改。

• 無事實的事實表

咱們以上討論的事實表度量都是數字化的，固然實際應用中絕大多數都是數字化的度量，可是也可能會有少許的沒有數字化的值可是還頗有價值的字段，無事實的事實表就是爲這種數據準備的，利用這種事實表能夠分析發生了什麼。

• 彙集事實表

彙集，就是對原子粒度的數據進行簡單的聚合操做，目的就是爲了提升查詢性能。如咱們需求是查詢全國全部門店的總銷售額，咱們原子粒度的事實表中每行是每一個分店每一個商品的銷售額，彙集事實表就能夠先聚合每一個分店的總銷售額，這樣彙總全部門店的銷售額時計算的數據量就會小不少。

• 合併事實表

這種事實表遵循一個原則，就是相同粒度，數據能夠來自多個過程，可是隻要它們屬於相同粒度，就能夠合併爲一個事實表，這類事實表特別適合常常須要共同分析的多過程度量。

維度表技術

1. 維度表結構

維度表謹記一條原則，包含單一主鍵列，但有時因業務複雜，也可能出現聯合主鍵，請儘可能避免，若是沒法避免，也要確保必須是單一的，這很重要，若是維表主鍵不是單一，和事實表關聯時會出現數據發散，致使最後結果可能出現錯誤。

維度表一般比較寬，包含大量的低粒度的文本屬性。

2. 跨表鑽取

跨表鑽取意思是當每一個查詢的行頭都包含相同的一致性屬性時，使不一樣的查詢可以針對兩個或更多的事實表進行查詢

鑽取能夠改變維的層次，變換分析的粒度。它包括上鑽/下鑽：

上鑽（roll-up）：上卷是沿着維的層次向上彙集彙總數據。例如，對產品銷售數據，沿着時間維上卷，能夠求出全部產品在全部地區每個月（或季度或年或所有）的銷售額。

下鑽（drill-down）：下鑽是上鑽的逆操做，它是沿着維的層次向下，查看更詳細的數據。

3. 退化維度

退化維度就是將維度退回到事實表中。由於有時維度除了主鍵沒有其餘內容，雖然也是合法維度鍵，可是通常都會退回到事實表中，減小關聯次數，提升查詢性能

4. 多層次維度

多數維度包含不止一個天然層次，如日期維度能夠從天的層次到周到月到年的層次。因此在有些狀況下，在同一維度中存在不一樣的層次。

5. 維度表空值屬性

當給定維度行沒有被所有填充時，或者當存在屬性沒有被應用到全部維度行時，將產生空值維度屬性。上述兩種狀況，推薦採用描述性字符串代替空值，如使用 unknown 或 not applicable 替換空值。

6. 日曆日期維度

在日期維度表中，主鍵的設置不要使用順序生成的id來表示，可使用更有意義的數據表示，好比將年月日合併起來表示，即YYYYMMDD，或者更加詳細的精度。