淺談數據倉庫維度建模流程

談到Big Data就離不開數據倉庫、數據集市等概念，而談到數據倉庫、數據集市，就又離不開數據倉庫設計的方法，維度建模則是其中的典型。與維度建模相對立的則是范式建模，范式建模常用于傳統的DB關系型數據庫中。范式建模講究三范式，講究原子性，一致性，隔離性，持久性。講究最小原子列不可再分，講究消除部分依賴，y=f(x)，y依賴于x，且x的任一真子集x’不滿足對應唯一y。講究消除傳遞依賴，當x---->y(y！------>x)，z------>x(x！------>z)時則不滿足3FN。而維度建模則是與之相對，維度建模不講究范式，不講究關系型，不講究事務，講究主題域，講究總線矩陣，講究維度和事實，講究…

附上之前所畫一張流程圖

之前畫此圖時是在前輩的幫助下畫出，但也是一知半解，其中很多東西不能完全理解，直至現在也是大概明白其中流程，但更多細節值得深入學習。今日不談后面的ETL過程、數據治理等，就談談前期的維度建模。近日又購得Kimball的維度建模，和阿里大數據之路二書，希望能夠沉下心深入學習，數據產品要想打造的好，令人滿意，則數據內容一定要質量過關。數據內容過關了，面對怎樣的數據產出都會有自信，自己的數據沒有問題。

維度建模以用戶的可理解性和查詢性能為目標，建立始終如一服務于組織的分析需求設計。維度建模是DW/BI系統項目成功的關鍵。是一種趨向于最終用戶對數據倉庫進行查詢的設計技術，是圍繞性能和易理解性構建的。

談到維度建模則一定要說到兩個較為核心的概念則是維度和事實。維度表和事實表經常聽說，那能否對維度和事實有個更好的定義呢。
事實：既成事實，表示對業務數據的度量，事實很多時候是數字類型的，可以進行計算和聚合。維度：觀察數據事物的角度，維度通常是一組層次關系或者描述信息，用來定義事實。

維度建模最開始要定好主題域，而建立主題域更多時候按業務流程來建立。不同的主題域可能共享一些維度，則這些維度也稱為一致性維度。術語“一致性維度”源自Kimball，指的是具有相同屬性和內容的維度，擁有這些一致性維度，可以提高數據操作的性能和數據一致性，如幾個主題域之間共享維度的復制。維度建模將客觀世界劃分為度量和上下文，維度建模按照業務流程即主題域建立。

維度數據模型建模過程
1.選擇業務流程
確認哪些業務處理流程是數據倉庫應該涵蓋到的，也是第一步的基礎。比如要設計一家公司的銷售情況，則與該公司的銷售相關的業務流程都應該關注到，然后描述業務流程（如何描述也是一個問題BPMN？UML？），這個時候產出可以有業務流程圖。

2.聲明粒度
再確認哪些業務流程應該是涵蓋到的之后，則應該聲明粒度，聲明粒度應該在確認維度和事實之前，因為只有先定義好粒度后面的維度和事實才能與定義的粒度保持一致，（他們說）一個事實所對應的所有維度設計中強制實行粒度一致性是保證數據倉庫應用性能和易用性的關鍵。這里的粒度用于確認事實中表示的是什么，要定義好粒度大小。在給定業務獲取數據時，原始粒度是最低級別的粒度，（他們說）建議從原始粒度數據開始設計，因為原始記錄能夠滿足無法預期的用戶查詢。輕匯總和重度匯總后的數據粒度對優化查詢性能很重要，但這樣的粒度設計往往不能滿足對細節數據的查詢需求。不同的事實可以有不同的粒度，但同一事實中也不要混用多種不同的粒度。

3.確認維度
確認模型的維度是第三步，維度的粒度需要和第二步聲明的粒度保持一致。維度表是事實表設計的基礎。典型的維度都是名稱（標簽），如日期、商店、用戶等。維度表存儲了某一維度所有相關的數據。例如日期維度應該包含年、季、月、周等。城市維度表包含所有城市等。

4.確認事實
最后一步則是確認事實，這一步識別數字化的度量，構成事實表的記錄。用戶可直接通過事實表的訪問獲取數據倉庫存儲的數據。大部分事實表的度量都是數字類型的，可進行計算。

星型模型和雪花模型
談到維度建模也不能不談到星型模型和雪花模型了。之前一直以為兩者差不多，雪花模型不過是星型模型的拓展而已。最近才發現二者思想挺不一樣的。星型模型（容易想到一星四射）事實表關聯維度表，維度表與維度表之間沒有關聯，這樣的設計，冗余大（秉持著能用錢解決的問題都不是問題的原則，這一點反而被鼓勵），查詢快，擴展性差，是反規范化數據。而雪花模型是把星型模型中的維度表進行規范化處理，進一步分解到附加表中。把維度表規范化的具體做法：把低基數的屬性從從維度表中移除并形成單獨的表。（性別屬于低基數，主鍵具有唯一值是高基數）在雪花模式中，一個維度被規范化成多個關聯的維度表，而在星型模式中，每一個維度由一個單一的維度表所表示。一個規范化的維度對應一組具有層次關系的維度表，而事實表作為雪花模式的子表，存在具有層次關系的多個父表。

星型模型和雪花模型的對比
1.數據優化
星形模型：實用的是反規范化數據。在星形模型中，維度直接指的是事實表，業務層級不會通過維度之間的參照完整性來部署。不能保證數據完整性，一次性地插入或更新操作可能會造成數據異常。對于分析需求不夠靈活。它更偏重于為特定目的建造數據視圖。
雪花模型：使用的是規范化數據，也就是說數據在數據庫內部是組織好的，以便消除冗余，因此它能夠有效地減少數據量。通過引用完整性，其業務層級和維度都將存儲在數據模型之中。規范化后的多層次維度表，可以很方便支持業務實體多對多關系，很容易進行全面的數據分析。
2.業務模型
星型模型：主鍵是一個單獨的唯一鍵(數據屬性)，為特殊數據所選擇。外鍵(參考屬性)僅僅是一個表中的字段，用來匹配其他維度表中的主鍵。
雪花模型：數據模型的業務層級是由一個不同維度表主鍵-外鍵的關系來代表的。而在星形模型中，所有必要的維度表在事實表中都只擁有外鍵。
3.性能
星型模型：星形模型在維度表、事實表之間的連接較少，所以簡化了查詢，相應的簡化了業務報表的邏輯。獲得查詢性能、能更快速的進行聚合。
雪花模型：雪花模型在維度表、事實表之間的連接很多，因此性能方面會比較低。舉個例子，如果你想要知道Advertiser 的詳細信息，雪花模型就會請求許多信息，比如Advertiser Name、ID以及那些廣告主和客戶表的地址需要連接起來，然后再與事實表連接。（但是，規范化的維度屬性可以節省存儲空間。）
4.ETL
星型模型：星形模型加載維度表，不需要再維度之間添加附屬模型，因此ETL就相對簡單，而且可以實現高度的并行化。
雪花模型：雪花模型加載數據集市，因此ETL操作在設計上更加復雜，而且由于附屬模型的限制，不能并行化。
5.總結
星型模型：星形模型用來做指標分析更適合，比如“給定的一個客戶他們的收入是多少?
雪花模型：雪花模型使得維度分析更加容易，比如“針對特定的廣告主，有哪些客戶或者公司是在線的?”

部分名詞：
總線矩陣的必要性
企業數據倉庫總線矩陣是DW/BI系統的一個總體數據架構，如果我們在建立數據倉庫的時候，只考慮單獨的某個業務系統的數據建設，則無法滿足一致性的目標，例如：相互有聯系的系統數據的維度不同導致關聯復雜或者關聯不上，數據之間互相成為了孤島，對于后期的擴展或者整個數倉的建設都是巨大的阻礙。
總線矩陣舉例：
那么總線矩陣就給我們提供了這么一個工具，每一行是一個業務過程，每一列是這個業務過程可能涉及到的一些維度，比如說上圖中的零售業務過程，這塊涉及到的公用維度包括：日期維度，產品維度，商店維度，促銷維度，客戶維度，雇員（銷售員）維度。
再看倉庫庫存業務過程，包含了日期維度，產品維度，倉庫維度。
通過日期維度或者產品維度或者倉庫維度，我們可以將每天的某種商品的庫存數據和銷售數據關聯起來進行分析，這就是一致性維度的好處，假設這兩部分數據沒有經過提前規劃，各部分數據都有不同的維表，那這兩部分數據想要聯系起來太難了。

退化維度
退化維度的維度表可以被剔除，從而簡化維度數據倉庫的模式。因為簡單的模式比復雜的更容易理解，也有更好的查詢性能。
當一個維度沒有數據倉庫需要的任何數據時就可以退化此維度。需要把退化維度的相關數據遷移到事實表中，然后刪除退化的維度。
維度屬性也可以存儲到事實表中，這種存儲到事實表中的維度列被稱為“退化維度”。與其他存儲在維表中的維度一樣 ，退化維度也可以用來進行事實表的過濾查詢、實現聚合操作等。那么究竟怎么定義退化維度呢？比如說訂單id，這種量級很大的維度，沒必要用一張維度表來進行存儲，而我們進行數據查詢或者數據過濾的時候又非常需要，所以這種就冗余在事實表里面，這種就叫退化維度，citycode這種我們也會冗余在事實表里面，但是它有對應的維度表，所以它不是退化維度。
kimball書中描述退化維度如下：操作型事務控制號碼，例如：訂單號碼、發票號碼、提貨單號碼通常產生空的維度并且寶石為事務事實表中的退化維度。退化維度是沒有對應維度表的維度鍵。
維度退化在事實表中有利于使用，一般一個維度鍵都有對應的維表，如果退化在事實表中，可以減少關聯次數，并且退化維可以用于group by操作，進行分組統計。
還可以這么理解：就是這個東西沒有對應的維表，沒有修飾它的屬性，但是呢，通過它你可以獲取一些內容，一些事實，比如說訂單編號，你可以獲得這個訂單里面包含哪些商品，對應的付款人是誰之類的。

緩慢變化維：維度建模的數據倉庫中，有一個概念叫Slowly Changing Dimensions，中文一般翻譯成“緩慢變化維”，經常被簡寫為SCD。緩慢變化維的提出是因為在現實世界中，維度的屬性并不是靜態的，它會隨著時間的流失發生緩慢的變化。這種隨時間發生變化的維度我們一般稱之為緩慢變化維，并且把處理維度表的歷史變化信息的問題稱為處理緩慢變化維的問題，有時也簡稱為處理SCD的問題。
處理緩慢變化維的方法通常分為三種方式：
第一種方式是直接覆蓋原值。這樣處理，最容易實現，但是沒有保留歷史數據，無法分析歷史變化信息。第一種方式通常簡稱為“TYPE 1”。
第二種方式是添加維度行。這樣處理，需要代理鍵的支持。實現方式是當有維度屬性發生變化時，生成一條新的維度記錄，主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關聯。第二種方式通常簡稱為“TYPE 2”。
第三種方式是添加屬性列。這種處理的實現方式是對于需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本屬性字段使用TYPE 1來直接覆蓋。這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是只保留了最后一次變化信息。第三種方式通常簡稱為“TYPE 3”。
在實際建模中，我們可以聯合使用三種方式，也可以對一個維度表中的不同屬性使用不同的方式，這些，都需要根據實際情況來決定，但目的都是一樣的，就是能夠支持方便的分析歷史變化情況。

維度建模對數據內容的建設，思想大于技術，思想引導技術。目前大部分理解來源書本、文章、講解。來自項目實戰、自己經驗的部分少之又少、很多時候只是一個別人思想、別人文章、別人技術、別人講解的搬運工、尚不能理解搬運的財富。望后面能有自己的理解。

總結

以上是生活随笔為你收集整理的浅谈数据仓库维度建模的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。