本文來源：數智化轉型俱樂部

摘要
本文從幾個常見概念入手，介紹模型設計與它們的關係，在列舉當前企業模型設計的建設方法，並重點介紹“維度建模”。

1

與幾個概念的關係操作型業務系統

對於這個概念大家都不陌生。企業業務賴以運轉的交易系統就屬於操作型業務系統。因此它是為了保障業務正常運轉，能夠更快的處理事務。

但是因為它是針對某一特定的意圖（例如滿足交易業務），它不需要承諾與其他業務系統共享公共資料。因此就出現了適合於企業中交叉應用的ERP、主資料系統。當然對於有建設業務中臺的企業來說，基於微服務架構的各個服務中心，能更好的提供可複用統一的公共資料。

不管是面向業務的業務系統、經過資料統一後的主資料系統或者基於微服務架構的服務中心的資料，都是作為資料中臺的資料輸入源頭。我們通過批量同步、歸檔日誌採集等方式，能將資料採集進資料中臺，作為ODS層原始資料的一部分。

ETL

英文Extract-Transform-Load的縮寫，用來描述將資料從來源端經過抽取（extract）、轉換（transform）、載入（load）至目的端的過程。在ODS層的原始資料，需要通過加工處理後，才能進入到構建好的資料模型中。

在模型設計時，需要考慮ETL加工流程，根據邏輯判斷，做模型的合理設計。同樣對於下游使用資料模型的ETL後設資料，也是作為模型設計的輸入，可基於下游應用方式做模型的橫向和縱向的拆分設計，這就是“後設資料驅動模型設計”的理論來源。

因此，無法理解資料開發的模型設計師是不合格的。

資料應用

資料中臺提供多種資料應用的形式，包括資料包表、智慧資料產品等。將統一彙總加工後的資料或者明細原子資料提供給資料應用，為業務提供資料支撐。

更加合理的資料模型設計，能夠給更寬泛的應用提供資料支撐，也能夠讓業務方更準確無疑義的使用好資料。

2

幾種企業常見的建設現狀煙囪式

也許大家都不願意承認，但是絕大部分的企業當前是沒有統一、標準、公共、全域性的模型設計的，而僅僅是把資料同步上來，然後基於業務需求做煙囪式的資料開發。這種方式也許從短期來看是效率最高的，但是從長期看，不僅僅造成計算儲存資源的極大浪費、沒有統一可用的資料、大量的重複性的工作。企業的資料就像一團亂麻，根本無法管理。

三正規化+資料集市

一些傳統大型企業，由於歷史原因，原子數倉中以三正規化的模型設計方式構建，在各個應用的資料集市中以維度建模方式構建。通過這種方式，在原子資料設計過程中，需要投入較大的資源。

對於業務來說，三正規化模型太複雜，使用者難以理解和檢索。並且對於業務頻繁變化的企業，模型的維護成本極高。

企業級維度模型

基於企業全域性的角度去構建業務匯流排矩陣，在此基礎上完成維度模型的設計，是當前眾多企業選擇的方向。從眾多網際網路企業的資料中臺實踐經驗來看，這也是一個絕佳的各因素平衡後的選擇。

後面，我們將從各個角度來思考如何基於維度模型構建企業級資料中臺。

3

維度建模初探優勢

在資料中臺建設經驗中，企業級維度模型設計從理解性、擴充套件性、高效能上都是更適應當前的技術和業務環境的。

首先由於計算和儲存成本逐步下降，模型更重要的變成了易於理解，當易用性放在模型設計的重要位置時，維度模型可理解的優勢就顯現出來了，維度建模一直就是以業務的視角來描述資料。

另外，當新的業務出現時，新的模型不會對已有模型形成衝擊，可以無影響的產出新的模型資料。

維度建模會設計部分資料的冗餘，通過冗餘換來資料檢索的高效能。對於資料量極具膨脹的今天，高效能給使用者帶來了高價值。

事實表

所謂的事實表，就是企業的業務過程事件的度量資訊。例如對於支付這個業務過程來說，需要度量支付的商品數、金額等度量。因此，企業的業務過程資料以事實表的形式在模型中呈現出來。

事實表每行都對應了一個度量事件，每行資料是一個特定級別的細節資料。事實表中每個度量都必須是相同的粒度級別。

事實表中的度量的可加性也至關重要，因為業務方往往需要將事實表的資料基於某些維度進行彙總，在度量上需要能夠做彙總累加。

事實表還是稀疏的，它僅僅會將發生的業務過程資料放入其中。

維度表

維度表是事實表不可或缺的組成成分，它描述了事實表業務過程度量的環境。用於描述“誰、什麼、哪裡、何時、如何、為什麼”有關的事件。

維度屬性是作為查詢約束、分組、標識的主要來源，因此它的好壞直接決定了資料的可分析性的差異。維度屬性需要是可理解的，因此需要儘量避免“0,1”之類的程式碼，將程式碼翻譯成更易理解的字元避免業務的誤解。

同樣，會有一些數值型的可作為維度屬性。例如：也許有人會問商品標價適合在事實表還是維度表中？

當用於計算度量時，它應該存在於事實表中；但是當它用於做約束、分組、標識分析時，則需要存在於維度表中。在維度表中，我們往往會把連續的資料換成離散的數值儲存，例如：將標價變為價格區間段。這是要根據對業務的理解做進一步設計的。

雪花模型與星型模型

所謂的雪花模型，是當有一個或多個維表沒有直接連線到事實表上，而是通過其他維表連線到事實表上時，其圖解就像多個雪花連線在一起，故稱雪花模型。

而星型模型則是所有維表都直接連線到事實表上，整個圖解就像星星一樣，故將該模型稱為星型模型。

雪花模型是對星型模型的擴充套件。

星型模型是一種非正規化的結構，多維資料集的每一個維度都直接與事實表相連，不存在漸變維度，所以資料有一定冗餘。因為有冗餘，所以很多統計不需要做外部的關聯查詢，因此一般情況下效率比雪花模型高。

但是從可理解性上看，雪花模型是更容易讓業務理解的。因為業務可以從模型上看出維度與維度之間的關係。

因此如何平衡查詢效率和業務理解？我們在後面的文章中再細細道來。

匯流排矩陣

匯流排矩陣，維護的是企業的各個業務過程與一致性維度的關係。是以企業的高度實現的頂層設計。它的存在對於資料中臺專案至關重要。

如果資料中臺的模型設計就是一本書，那麼匯流排矩陣就是這本書的目錄，能從整體上對每個模型有統一的定義。

從專案協調上看，匯流排矩陣在大型專案中起到舉足輕重的地位，整個專案組都能基於這個目錄清晰的明白自己在做什麼，別人已經做了什麼，極大程度上的避免了資訊溝通不暢導致的重複定義。

從專案管理上看，也可以基於匯流排矩陣對模型設計和開發進行有效的優先順序排期。

最後，匯流排矩陣是共同業務人員和技術人員的橋樑，通過匯流排矩陣在專案溝通中達成一致的語言。

D

結語
通過這篇文章，初淺的對資料中臺模型設計發表了一些觀點。

在後面的章節中，我們將繼續圍繞模型設計的技術細節、結合行業的模型設計案例，和資料同仁們做進一步的分享和交流 。

如您想加入199IT商業智慧群，請加微信wendy199it