大數據時代，維度建模已成為各大廠的主流方式。維度建模從分析決策的需求出發構建模型，為分析需求服務。重點關注用戶如何快速的完成數據分析，可以直觀的反應業務模型中的業務問題，需要大量的數據預處理、數據冗余，有較好的大規模復雜查詢的響應性能。

要討論數據建模，我們首先要搞清楚“數據建模”是什么，以及數據建模的目標是什么。在大數據時代，數據不僅僅包括數據表，因此，我們用一個內涵更加廣泛的詞“數據集合”來替代“一系列的表”這個說法。那么數據建模是如何去滿足要求的呢？是通過抽象出良好的結構，來實現的。

數據建模是一個用于定義和分析在組織的信息系統范圍內支持商業流程所需的數據要求的過程。簡單來說，數據建模是基于對業務數據的理解和數據分析的需要，將各類數據進行整合和關聯，使得數據可以最終以可視化的方式呈現，讓使用者能夠快速地、高效地獲取到數據中有價值的信息，從而做出準確有效的決策。

之所以數據建模會變得復雜且難度大，是因為在建模過程中會引入數學公式或模型，用于確定數據實體之間的關聯關系。不同的業務邏輯和商業需求需要選擇不同的數學公式或模型，而且，一個好的數據模型需要通過多次的測試和優化迭代來完成，這就使得數據建模的難度變得很高。但是，數據分析中的建模并沒有想象中的那么高深莫測，人人都可以做出適合自己的模型。

數據建模是一個“通過良好的結構設計，建設滿足要求的數據集合”的過程。在建模過程中，需分析數據和數據之間的關系，對所要模型化的內容具有清晰的認 識。數據建模者要和各方涉眾進行交流、溝通，以便構建的數 據模型具有較高的精確性，在所有用戶中達成共識。

1.保障數據質量：質量是數據的生命線，數據的質量決定了數據的價值。具體而言數據質量，可以概括為4類，正確性、完整性、時效性，以及一致性。

2.提升交付效率：穩定性、適應性、簡潔性和易用性，是影響數據研發效率的4個主要因素。

3. 降低整體成本：在確定的品質效率下，要盡可能的降低成本，把握好存儲成本與計算成本之間的平衡。

簡而言之，數據建模的目標是建立對于業務經營而言“好用、高效、且經濟”的數據資產。當然，與此同時，我們還要守好底線，保證數據合規、防止數據泄露。

一、數據建模類型和流程

1.1 數據建模常見類型

概念模型的主要目標是建立實體及其屬性和實體之間的關系，不會涉及數據庫結構的。例如，客戶和產品是兩個實體，客戶的編號和名稱是它的屬性，產品的名稱和價格是產品的屬性，銷售是客戶和產品之間的關系。

邏輯模型將更多的信息添加到概念模型中，定義了元素的結構并設置了元素之間的關系。邏輯數據模型具有如下特征：描述單個項目的數據需求，但可以根據項目范圍與其他邏輯數據模型集成；獨立于數據庫的設計和開發；數據屬性將具有精確精度和長度的數據類型；通常將模型的標準化過程應用到第三范式。

物理數據模型描述數據模型的數據庫實現，提供了數據庫的抽象，包含了豐富的信息。這種類型的數據模型還有助于可視化數據庫結構。它有助于為數據庫列建模鍵，約束，索引，觸發器和其他RDBMS功能。

1.2 數倉模型設計原則

數據倉庫要分層建設，這個幾乎是毫無爭議的。但具體分為哪幾層，每一層的稱呼是什么，各家的見解略有差異。不過沒關系，最重要的是抓住本質：高內聚、低耦合、高復用、控依賴，以下詳細闡述。

1. 高內聚低耦合：邏輯和物理模型的記錄和字段組成方式，應該遵循最基本的軟件設計方法論中的高內聚低耦合的原則。

• 從業務特征而言：將業務近似或相關的數據，或是粒度相同的數據設計為一個邏輯或物理模型。
• 從訪問特征而言：將高概率同時訪問的數據放一起，將低概率同時訪問的數據分開存儲。

2. MECE原則：數據域劃分統一標準，盡可能遵照MECE原則，不重不漏。數據域之間的邊界劃分的越清晰，越能夠延緩數據模型的腐化。

3. 公共處理邏輯，下沉且保持單一：所謂下沉是指，越是底層公用的處理邏輯，越應該在數據調度任務依賴的上游進行封裝和實現，不可讓公共的處理邏輯暴露給應用層實現。所謂保持單一是指，不可用讓公共邏輯

在多處存在，因為多處存在的邏輯，隨著時間的推演，很難保持一致性。

4. 核心模型與擴展模型分離：建立核心模型與擴展模型體系，核心模型包括的字段支持常用核心的業務，擴展模型包括的字段支持個性化，或是少量應用的需要。不可讓擴展字段過度侵入核心模型，以至于破壞核心模型的架構簡潔性和可維護性。

5. 合理的層次依賴：各層數據空間之間，避免“反向引用”；例如DWD層應嚴格遵守層次依賴，理論上只可以引用ODS、DIM和部分的DWD層數據，不可引用處于下游層次的ADS層數據。ADS應用層各數據集市之間，也應該盡量避免頻繁引用，如有高頻共用的邏輯，應該向CMD中間層（含DWD、DWS、DIM）沉淀。

6. 清晰可理解的數據表命名，遵照一致性的字段命名：表命名需要遵照OneModel數據表命名規范，表名需要對于主要消費者而言，是清晰、易于理解和易于使用的。對于核心的指標（事實）、維度（對象），相同含義的字段，在不同表中的字段名必須保持一致，且須使用《模型命名規范》中的名稱。

1.3 數據倉庫核心架構

數據倉庫是一個為數據分析而設計的企業級數據管理系統。數據倉庫可集中、整合多個信息源的大量數據，借助數據倉庫的分析能力，企業可從數據中獲得寶貴的信息進而改進決策。同時，隨著時間的推移，數據倉庫中積累的大量歷史數據對于數據科學家和業務分析師也是十分寶貴的。

1.4 數據倉庫建模的意義

如果把數據看作圖書館里的書，我們希望看到它們在書架上分門別類地放置；如果把數據看作城市的建筑，我們希望城市規劃布局合理；如果把數據看作電腦文件和文件夾，我們希望按照自己的習慣有很好的文件夾組織方式，而不是糟糕混亂的桌面，經常為找一個文件而不知所措。

數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。只有將數據有序的組織和存儲起來之后，數據才能得到高性能、低成本、高效率、高質量的使用。

高性能：良好的數據模型能夠幫助我們快速查詢所需要的數據

低成本：良好的數據模型能減少重復計算，實現計算結果的復用，減低計算成本

高效率：良好的數據模型能極大的改善用戶使用數據的體驗，提高使用數據的效率

高質量：良好的數據模型能改善數據統計口徑的混亂，減少計算錯誤的可能性

二、四種常見模型

2.1 維度模型

維度建模按數據組織類型劃分可分為星型模型、雪花模型、星座模型。

維度建模四個步驟：

選擇業務處理過程 > 定義粒度 > 選擇維度 > 確定事實

2.1.1 星型模型

星型模型主要是維表和事實表，以事實表為中心，所有維度直接關聯在事實表上，呈星型分布。

2.1.2 雪花模型

雪花模型，在星型模型的基礎上，維度表上又關聯了其他維度表。這種模型維護成本高，性能方面也較差，所以一般不建議使用。尤其是基于hadoop體系構建數倉，減少join就是減少shuffle，性能差距會很大。

星型模型可以理解為，一個事實表關聯多個維度表，雪花模型可以理解為一個事實表關聯多個維度表，維度表再關聯維度表。

2.1.3 星座模型

星座模型，是對星型模型的擴展延伸，多張事實表共享維度表。

星座模型是很多數據倉庫的常態，因為很多數據倉庫都是多個事實表的。所以星座模型只反映是否有多個事實表，他們之間是否共享一些維度表。

2.2 范式模型

即實體關系（ER）模型，數據倉庫之父Immon提出的，從全企業的高度設計一個3NF模型，用實體加關系描述的數據模型描述企業業務架構，在范式理論上符合3NF。此建模方法，對建模人員的能力要求非常高。

特點：設計思路自上而下，適合上游基礎數據存儲，同一份數據只存儲一份，沒有數據冗余，方便解耦，易維護，缺點是開發周期一般比較長，維護成本高。

2.3 Data Vault模型

DataVault由Hub（關鍵核心業務實體）、Link（關系）、Satellite（實體屬性） 三部分組成 ，是Dan Linstedt發起創建的一種模型方法論，它是在ER關系模型上的衍生，同時設計的出發點也是為了實現數據的整合，并非為數據決策分析直接使用。

2.4 Anchor模型

高度可擴展的模型，所有的擴展只是添加而不是修改，因此它將模型規范到6NF，基本變成了K-V結構模型。企業很少使用。

三、數據模型的流程

3.1 確定實體關系

在數據庫中，管理信息系統為其中的基本框架，設計數據庫概念模型是構建數據庫的關鍵所在。其中構建實體關系是非常關鍵的一個環節。在真實的世界當中，實體是能夠互相區分的，能夠被人類所了解與掌握的概念、事與物等。集合概念是實體的基本特征，用實體實例來闡述它的各個個體。有若干個特征存在于實體當中，因此，可以稱它們為屬性。對于實體的屬性組合屬性 都能夠唯一標識出來，也就是 PK Primary Key（主鍵），同時也有外鍵存在于實體當中，在現階段的實體中，它也是屬性的一種，在其他的實體中則為主鍵。

可以通過三種方式構建實體之間的關系：構建一對多的關系：指的是將實體B的n個實例通過實體A的一個實例構建出來。構建多對多的關系：對于實體B的n個實例，能夠利用實體A的一個實例構建起來。構建一對一的關系：實體B的一個實例能夠通過實體A的一個實例構建起來。

3.2 將信息用統主題構建起來

這為相關行業進行信息系統數據建模的一個關鍵流程，利用分析信息系統數據建模的相關需求，將行業內的工作主題確定出來。在相關決策的前提下，將工作人員所要傾向的主體構建起來。此外，還應該同行業內的聯機系統進行連接，然后粗略的分析這些操作型數據，進而將良好的數據基礎為構 建綜合性的數據分析系統和信息系統構建起來。

3.3 邏輯數據建模

分析系統的數據邏輯模型和數據綜合信息系統是通過數據庫將數據模型構建起來的，因此，怎樣可以令數據倉庫更加有效的對用戶的相關需求給予滿足，是構建數據邏輯模型的關鍵所在。用一定數量的維數據將星型模式設計出來，這樣能 將良好的查詢功能為數據倉庫提供出來。通過數據模式的外觀得出了星型模式這個概念，從屬的 表格通過星狀包圍起了這個居于中間的大表格。而且，指標實體的度量屬性和指標實體一同構成了這個居于中央的大表格。

這與概念模型過程中所產生的度量屬性和事實實體是相 對應的。維度實體被包含于從屬的表格中，而且，它有效的對 應著指標實體當中的較多個度量屬性。同時，還有另一類實體也存在于從屬表格中，進而來有效的限制用戶的數據查詢結果，將較少的行為查詢過程中的指標實體返回來，將產訊范圍進而縮小。而將實體的詳細的類別出來，是為了對用戶查詢過 程詳細信息的需求給予充分的滿足，維度實體和指標實體的 聯系一般都是通過各個維度實體當中最低一層的精細類別展現出來的，也就是說，居中表格的主鍵是從屬表格外鍵的主要來源。

3.4 選擇有效的建模工具

例如選擇ROSE，可以切實的完成相關的數據建模：

①利用分析相關的需求，將項目里面所關聯的數據實體尋找出來，將 E-R 圖在關系數據庫中構建起來；

② 將關系與實體在相關的圖形中完成映射處理，進而將類圖在對象模型中構建起來，并且用類的方法取締數據上的操作。可是，將實體的對象模型如果能夠在需求分析中直接構建起來，這樣上一步就能夠被有效的省略掉；

③用 rose 轉化功能對構 成的對象模型進行轉化，能夠用數據模型取代象模型；

④將關系數據庫用數據模型自動轉化出來，并且，按照有關的轉換原實現生成過程；

⑤導出對象數據，將代碼的框架構造成型，然后進一步的強化和完善代碼框中的相關內容；

⑥將相關的測試用例編寫出來，與數據庫中的一些對象及對應類結合起來統一的進行測試；

⑦隨著不斷深入的項目建設，也會相應的完善和增加一些數據對象，因此，循環的迭代過程就需要被開展 =起來，進行相應的完善和細化。經過以上流程，能夠找出對象層里面所涵蓋的對象，并且迅速的進行編碼測試和建模。

此工作環節的目的是將相應封裝之后的實體類獲取出來。接下來的工作是在業務需求的基礎上，合理的組裝實體類，進而確保能夠有效的調用界面層。

四、數據模型的評價標準

數據模型建設的怎么樣，極度依賴規范設計，如果代碼風格是“千人千面”，那么恐怕半年下來，業務系統就沒法看了。沒有什么比“數據系統”更看重“法制”了，規范體系不僅能保障數據建設的一致性，也能夠應對業務交接的情況，更能夠為自動化奠定基礎。

業務過程清晰：ODS就是原始信息，不修改；DWD面向基礎業務過程；DIM描述維度信息；DWS針對最小場景做指標計算；ADS也要分層，面向跨域的建設，和面向應用的建設；

指標可理解：按照一定業務事務過程進行業務劃分，明細層粒度明確、歷史數據可獲取，匯總層維度和指標同名同義，能客觀反映業務不同角度下的量化程度；

核心模型相對穩定：如果業務過程運行的比較久，過程相對固定，就要盡快下沉到公共層，形成可復用的核心模型；

高內聚低耦合：各主題內數據模型要業務高內聚，避免在一個模型耦合其他業務的指標，造成該模型主題不清晰和性價比低。

總結

在傳統企業數倉中，業務相對穩定，以范式建模為主。如電信、金融行業等。在互聯網公司，業務變化快，需求來來回回的改，計算和存儲也不是問題，我們更關心快速便捷的響應業務需求，所以以維度建模為主流。