一、數據倉庫建模的意義
如果把數據看作圖書館里的書，我們希望看到它們在書架上分門別類地放置；如果把數據看作城市的建筑，我們希望城市規劃布局合理；如果把數據看作電腦文件和文件夾，我們希望按照自己的習慣有很好的文件夾組織方式，而不是糟糕混亂的桌面，經常為找一個文件而不知所措。數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。Linux的創始人Torvalds有一段關于“什么才是優秀程序員”的話：“爛程序員關心的是代碼，好程序員關心的是數據結構和它們之間的關系”，最能夠說明數據模型的重要性。

只有數據模型將數據有序的組織和存儲起來之后，大數據才能得到高性能、低成本、高效率、高質量的使用。

性能：幫助我們快速查詢所需要的數據，減少數據的I/O吞吐，提高使用數據的效率，如寬表。成本：極大地減少不必要的數據冗余，也能實現計算結果復用，極大地降低存儲和計算成本。效率：在業務或系統發生變化時，可以保持穩定或很容易擴展，提高數據穩定性和連續性。

質量：良好的數據模型能改善數據統計口徑的不一致性，減少數據計算錯誤的可能性。

數據模型能夠促進業務與技術進行有效溝通，形成對主要業務定義和術語的統一認識，具有跨部門、中性的特征，可以表達和涵蓋所有的業務。

大數據系統需要數據模型方法來幫助更好地組織和存儲數據，以便在性能、成本、效率和質量之間取得最佳平衡！

下圖是個示例，通過統一數據模型，屏蔽數據源變化對業務的影響，保證業務的穩定，表述了數據倉庫模型的一種價值：

二、數據倉庫分層的設計

以下是我們的一種分層設計方法，數據緩沖區（ODS）的數據結構與源系統完全一致?；A數據模型(DWD)和融合數據模型（DWI與DWA）是大數據平臺重點建設的數據模型。應用層模型由各應用按需自行建設，其中基礎數據模型一般采用ER模型，融合數據模型采用維度建模思路。

三、兩種經典的數據倉庫建模方法

前面的分層設計中你會發現有兩種設計方法，關系建模和維度建模，下面分別簡單介紹其特點和適用場景。

當今的數據處理方式大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果。二者的主要區別對比如下表所示

1、維度建模
（1）定義

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

在維度建模的基礎上又分為三種模型：星型模型、雪花模型、星座模型。

星座模型與前兩種情況的區別是事實表的數量，星座模型是基于多個事實表基本上是很多數據倉庫的常態，因為很多數據倉庫都是多個事實表的。所以星座不星座只反映是否有多個事實表，他們之間是否共享一些維度表。所以星座模型并不和前兩個模型沖突

星型模型由一個事實表和一組維表組成。每個維表都有一個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。強調的是對維度進行預處理，將多個維度集合到一個事實表，形成一個寬表。

首先就是星座不星座這個只跟數據和需求有關系，跟設計沒關系，不用選擇。星型還是雪花，取決于性能優先，還是靈活更優先目前實際企業開發中，不會絕對選擇一種，根據情況靈活組合，甚至并存 (一層維度和多層維度都保存) 。但是整體來看，更傾向于維度更少的星型模型。尤其是Hadoop體系，減少Join就是減少Shuffle，性能差距很大(關系型數據可以依靠強大的主鍵索引)

（2）建模方法

選擇業務過程→聲明粒度→確認維度→確認事實

（a）選擇業務過程

在業務系統中，挑選我們感興趣的業務線，比如下單業務，支付業務，退款業務，物流業務，一條業務線對應一張事實表。

如果是中小公司，盡量把所有業務過程都選擇。如果是大公司（1000多張表），選擇和需求相關的業務線。

（b）聲明粒度

數據粒度指數據倉庫的數據中保存數據的細化程度或綜合程度的級別。

聲明粒度意味著精確定義事實表中的一行數據表示什么，應該盡可能選擇最小粒度，以此來應各種各樣的需求。

典型的粒度聲明如下： 訂單當中的每個商品項作為下單事實表中的一行，粒度為每次。 每周的訂單次數作為一行，粒度為每周。 每月的訂單次數作為一行，粒度為每月。

如果在DWD層粒度就是每周或者每月，那么后續就沒有辦法統計細粒度的指標了。所以建議采用最小粒度。

（c）確定維度

維度的主要作用是描述業務是事實，主要表示的是“誰，何處，何時”等信息。

確定維度的原則是：后續需求中是否要分析相關維度的指標。例如，需要統計，什么時間下的訂單多，哪個地區下的訂單多，哪個用戶下的訂單多。需要確定的維度就包括：時間維度、地區維度、用戶維度。

維度表：需要根據維度建模中的星型模型原則進行維度退化。

（d）確定事實

此處的“事實”一詞，指的是業務中的度量值（次數、個數、件數、金額，可以進行累加），例如訂單金額、下單次數等。

在DWD層，以業務過程為建模驅動，基于每個具體業務過程的特點，構建最細粒度的明細層事實表。事實表可做適當的寬表化處理。

以下是阿里的OneData的建模工作流

（3）優缺點優點：技術要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，較好的大規模復雜查詢的響應性能缺點：維度表的冗余會較多，視野狹窄
2、關系建模
（1）定義

關系模型如圖所示，嚴格遵循第三范式（3NF），從圖中可以看出，較為松散、零碎，物理表數量多，而數據冗余程度低。由于數據分布于眾多的表中，這些數據可以更為靈活地被應用，功能性較強。關系模型主要應用與OLTP系統中，為了保證數據的一致性以及避免冗余，所以大部分業務系統的表都是遵循第三范式的。

它更多是面向數據的整合和一致性治理，正如Inmon所希望達到的“single version of the truth”。

關系模型雖然冗余少，但是在大規模數據，跨表分析統計查詢過程中，會造成多表關聯，這會大大降低執行效率。所以在數據倉庫系統里面我們通常采用維度模型建模，把相關各種表整理成兩種：事實表和維度表兩種。

（2）建模方法

關系建模要從整體進行考慮，也就是說要對業務有全面的了解和把控，要對上游業務系統的進行信息調研，以做到對其業務和數據的基本了解，要做到主題劃分，讓模型有清晰合理的實體關系體系，以下是方法的示意：

以下是中國移動的概念模型的一種示例，如果沒有自頂向下的視野，基本是總結不出來的：

（3）優缺點優點：規范性較好，冗余小，數據集成和數據一致性方面得到重視，比如運營商可以參考國際電信運營業務流程規范（ETOM），有所謂的最佳實踐。缺點：需要全面了解企業業務、數據和關系；實施周期非常長，成本昂貴；對建模人員的能力要求也非常高，容易爛尾?，F在一般企業中大部分都是使用維度建模來進行數倉模型的設計。
3、建模方法比較

一般來講，維度模型簡單直觀，適合業務模式快速變化的行業，關系模型實現復雜，適合業務模式比較成熟的行業，在現在業務快速的發展變化，關系建模來不及快速的響應和改變。

運營商以前都是關系建模，現在其實邊界越來越模糊，很多大數據業務變化很快，采用維度建模也比較方便，不需要頂層設計。

四、企業建模的三點經驗

維度建模就不說了，只要能理解業務過程和其中涉及的相關數據、維度就可以，但自頂向下的關系建模難度很大，以下是關系建模的三個建設要點。

1、業務的理解：找到企業內最理解業務和源系統的人，梳理出現狀，比如運營商就要深刻理解三域（O/B/M），概念建模的挑戰就很大，現在做到B域的概念建模已經很不容易。

2、數據及關系的理解：各個域的系統建設的時候沒有統一文檔和規范，要梳理出邏輯模型不容易，比如運營商的事件主題下的邏輯模型就非常復雜。
3、標準化的推進：數據倉庫建模的任何實體都需要標準化命名，否則未來的管理成本巨大，也是后續數據有效治理的基礎，以下是我們的一個命名規范示例：
總而言之，你可以把這篇文章當成一個指引，具體還是要結合企業的實際去推進，始終要明白的一個原則就是：即數據如何擺布才能提高支撐應用的效率，手段上不用區分什么先進不先進，好用就成。