注：這是一篇講述維度數(shù)據(jù)模型設(shè)計的文章，偏向于數(shù)據(jù)平臺而非數(shù)據(jù)分析，請讀者根據(jù)自己的興趣愛好閱讀，內(nèi)容有不妥的地方請聯(lián)系我(松子)。

了解過數(shù)據(jù)倉庫歷史的人都知道Bill Inmon、 Ralph Kimball。 Bill Inmon 代表作《Building the Data WareHouse》 ， Ralph Kimball代表作為 《The Data Warehouse Toolkit》、《The data Warehouse lifecycle》。兩位大師對數(shù)據(jù)模型都分別作了深入闡述，個人理解的數(shù)據(jù)模型是數(shù)據(jù)平臺的靈魂。數(shù)據(jù)模型設(shè)計好了對數(shù)據(jù)應(yīng)用、數(shù)據(jù)分析支持是非常有幫助的。尤其 kimball 提出的維度模型 ，圍繞業(yè)務(wù)模型能夠直觀的表達業(yè)務(wù)數(shù)據(jù)關(guān)系。

　　關(guān)于數(shù)據(jù)模型概念不多講，本文與大家分享多維數(shù)據(jù)模型設(shè)計的十個技巧。

技巧一：維度表中應(yīng)該包含最細的顆粒度。

通常在數(shù)據(jù)平臺做開發(fā)的同學(xué)，“特麼”經(jīng)常抱怨 “ 需求怎么又變了，這個需求能不能不要來回的改“，數(shù)據(jù)建設(shè)中會遇到非常不確定性需求，不可預(yù)測篩選與匯總。

尤其是在互聯(lián)網(wǎng)做數(shù)據(jù)化運營，絕大部分需求幾個匯總類指標是無法滿足需求，很多時候會沉浸到比較明細、更深層次的細節(jié)信息。當然匯總指標是能夠概括一些概述數(shù)據(jù)細節(jié)，但只有細節(jié)數(shù)據(jù)才能回答各種不停的業(yè)務(wù)上數(shù)據(jù)追問。

技巧二： 圍繞業(yè)務(wù)流程來構(gòu)建維度。

數(shù)據(jù)是真實的反應(yīng)業(yè)務(wù)活動與成果的，業(yè)務(wù)流程在不同的階段所產(chǎn)生數(shù)據(jù)項也是不一樣的。比如說一個用戶從尋找App、下載、安裝、啟動、再啟動這個流程，用戶在淘寶購物、尋找瀏覽物品、放入購物車、跳轉(zhuǎn)收銀臺、支付、完成。

這兩個流程背后代表某個業(yè)務(wù)事件活動，在不同的環(huán)節(jié)產(chǎn)生的數(shù)據(jù)項是不同的，如果將流程不同階段的指標沉淀下來變?yōu)榭啥攘康年P(guān)鍵指標，如果將這些關(guān)鍵指標根據(jù)關(guān)系合并與設(shè)計到事實表中，就變?yōu)橹螛I(yè)務(wù)人員分析、探索業(yè)務(wù)的細節(jié)數(shù)據(jù)。

為了能夠從業(yè)務(wù)流程上的多維度來探索數(shù)據(jù)，所涉及到的很多維度最好是業(yè)務(wù)流程來做設(shè)計，比如上圖交易現(xiàn)相關(guān)，從訂單的來源，所屬產(chǎn)品、到支付階段的資金來源，從業(yè)務(wù)流程上來看，還可以擴展出更多的維度、與度量值。

在不同的業(yè)務(wù)環(huán)節(jié)，業(yè)務(wù)人員都會“很任性”的需求不同指標，但是在需求中往往是與業(yè)務(wù)流程有很大關(guān)系的。

技巧三：盡量保證每張事實表與時間維度有關(guān)聯(lián)

在原則二中描述那兩個案例業(yè)務(wù)永遠是與日期有關(guān)系的，不管是月、日、年、還是分、秒，財務(wù)年、自定義時間事件段等。

每個事實表至少有一個外鍵能夠與日期維度表相連，時間維度能才能反映出存量與流量，才能分析某一時刻、某一時間段的業(yè)務(wù)流程變化情況。

技巧四：同一張事實表的指標對應(yīng)維度層級必須一致

一般的事實表有四種類型，粒度事實、周期性快照事實、聚合快照事實、非事實事實表，不管它們的粒度類型，事實表中的每個度量值在顆粒度上必須保持與維度的顆粒度是一致的，否則就等著崩潰吧。

例如原則二給出的案例，要分析一個用戶訂單支付業(yè)務(wù)。如果對這個業(yè)務(wù)進行設(shè)計分析模型時，把產(chǎn)品維度粒度定義為產(chǎn)品，但是在度量值金額卻是按照不同產(chǎn)品分類做聚合的，那就有意思了。我暫時也沒回憶起類似的場景會在什么情況犯錯。

技巧五：處理好事實表和維度表之間的多對多關(guān)系

在多個維度表的值可以賦給單個事實事務(wù)時，事實表和維度表之間通常是多對多關(guān)系，比如為了計算寫書的作者分成，一本書可能有多個作者， 一個作者可能出版了多本書，這個案例下就是多對多的關(guān)系。要考慮到可以計算出每個作者的的分成，中間可以增加一個橋接表。

　　綜上所述，

在這種情況下多個值的維度與事實表直連可以采用橋接表來處理。

技巧六：經(jīng)常發(fā)生變化的維度處理

在設(shè)計維度上很多時候都是扁平化處理，業(yè)務(wù)中普遍的維度關(guān)系是一對一的關(guān)系，比如例如客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中的有效截止日期改為現(xiàn)在，并重新添加一條有效截止日期為現(xiàn)在的和一個新的版本號且Address為Addr2的記錄。

但是也經(jīng)常存在一對多的關(guān)系，比如大家的購物郵寄地址、個人電話號碼等在現(xiàn)實生活中有變化的處理。這種情況可能存在一對多的關(guān)系，假如一張維表存在上百萬的維度且匯總信息經(jīng)常在變化，那得注意做緩慢變化、或快速變化處理了。

技巧七：讓維度表使用代理鍵

英文叫SurrogateKey，翻譯過來又叫代理鍵，在建模中通過一些毫無意義鍵值來代替一些業(yè)務(wù)鍵值，有利于維度統(tǒng)一整合。

技巧八：進行一致性維度的處理

一致性維度，又叫統(tǒng)一維度。對于構(gòu)建企業(yè)級數(shù)據(jù)平臺數(shù)據(jù)模型具有關(guān)鍵的意義，通過在數(shù)據(jù)轉(zhuǎn)換處理環(huán)節(jié)一次性處理后，在構(gòu)建不同數(shù)據(jù)集市、不同數(shù)據(jù)層時可以反復(fù)被使用。

統(tǒng)一維度在構(gòu)建多維模型時，可以很便捷能把多種不同類型業(yè)務(wù)指標進行關(guān)聯(lián)，讓使用用戶在不同業(yè)務(wù)間切換分析、還能減少維護工作。

比如數(shù)據(jù)描述經(jīng)常不一致性如，同名異義、同物異名，還有口徑多樣化、編碼不統(tǒng)一、命名不統(tǒng)一等。還能處理一些未知、不知道名字、日期待定等一些含

糊的分類。

而然，在實施統(tǒng)一維度時最大的障礙是需要不同的業(yè)務(wù)部門、IT部門對每個維度屬性上達成一致，那就涉及到數(shù)據(jù)管理、數(shù)據(jù)治理的范疇了。比如含義相同但名稱不同業(yè)務(wù)術(shù)語等。

技巧九：分析功能標簽化標簽以及過濾器等信息可以當做維度來保存。

其實這也不是什么原則，個人更傾向于歸類到技巧中。比如在構(gòu)建分析型數(shù)據(jù)產(chǎn)品時，有些功能性的標簽、查詢類的代碼或分類完全可以維度化。

例如某些下拉菜單中篩選標簽以及過濾器閾值等、用戶的特定群體探索、產(chǎn)品的相關(guān)聯(lián)分析等，都可以維度化并做預(yù)處理。

這樣做的好處是速度快，把部分分析結(jié)果數(shù)據(jù)做預(yù)處理，查詢中需要聚合部分變?yōu)檫^濾查詢，這樣會提高分析查詢效率的。

技巧十：大維度的退化處理

所謂的大維度，是指維度數(shù)據(jù)量特別大，比如現(xiàn)在互聯(lián)網(wǎng)的URL維度可能幾十萬上百萬，還有客戶，產(chǎn)品等等。一個大的企業(yè)客戶維度往往有上百萬記錄，每條記錄又有上百個字段。而大的個人客戶維度則會超過千萬條記錄，這些個人客戶維度有時也會有十多個字段，但大多數(shù)時候比較少見的維度也只有不多的幾個屬性。

這些維度的處理往往采用把大屬性轉(zhuǎn)為小屬性、退化處理，增加更多的不同分類字段等特殊處理。