傅一平評語：

本文分兩部分，第一部分通俗易懂的講清楚了建模的理論，回答了很多關鍵問題，包括：

1、什么是模型？

2、什么是數據模型? 3、通用的數據建模流程

4、主要的數據建模方法

第二部分講了建模的實踐，干貨很多，很有借鑒意義，包括：

1、理論聯系實踐的數倉建模方法探索

2、作者采用的數據建模方法和流程

推薦大家讀一讀。

? ? ? 第一部分

? ? ? 1 前言

? ? ? 大家好，本篇文章是數倉詳細介紹系列的第四篇。

? ? ? 第一篇是簡單介紹，后三篇屬于數倉設計部分：

? ? ? 數倉概述，這一篇我給大家簡單介紹了數據倉庫的基本概念和大致構建過程，沒有過多深入主要是給大家有個基本的了解。

? ? ? 數倉架構，這部分確定了數據倉庫的結構和邊界，我們從四個不同視角給大家帶來了相對全面的宏觀認識，當然還差一個部署架構。

? ? ? 數倉規范，則是對數據管理的全流程進行約束，以保證數據管理工作的有序、高效、高質量的開展。上篇是心法，我們簡單闡述了規范的重大意義以及設計和落地方法論。下篇是招式，我們從四個不同方向給大家呈現了一幅完整規范范本，給大家參考。

? ? ? 數據模型，可以說是數據倉庫的基石，承載著數據存儲的重要職能。上篇我們主要介紹數據建模理論，我們先不對數倉建模做太多介紹，而是從更大的視角去闡述。下篇我們主要介紹真實數倉建設場景下的數據建模實踐。

由于數倉建模的重要性，數據倉庫的文章都會用絕大多數篇幅來講解，當然主要還是維度建模，我一開始也認為自己會在這一章講講三范式，講講維度建模然后就完了，由于大家都已經講的很好了，甚至我都打算直接轉載了。

后來由于一些其它原因，我在七月份做了一次公開課《數據倉庫的前世今生》，八月份又翻閱了一些 DAMA2.0 的內容。突然意識到數據建模并不等于數倉建模，事實上數倉建模僅僅是數據建模的其中一個分支，在范式建模和維度建模之外也還有幾個別的建模方法，只是數倉建模很少用到罷了。

既然這篇是數據建模的理論篇，那么我們何不跳出數倉建模，從更大的視角展開來闡述呢？

? ? ? 2 什么是模型？

? ? ? 說到模型，還有另外一個比較容易搞混的概念：什么是模式?

? ? ? 從字面的意思理解，“模”一種標準，或者一種套路，“式”方式，方法，形式 。兩個字連接在一起就可以解釋為，一種可以重復使用，具有參考性的方法、知識體系。

? ? ? 在互動百科中定義為：

? ? ? 模式是指從生產經驗和生活經驗中經過抽象和升華提煉出來的核心知識體系。模式（Pattern）其實就是解決某一類問題的方法論。把解決某類問題的方法總結歸納到理論高度，那就是模式。模式是一種指導，在一個良好的指導下，有助于你完成任務，有助于你作出一個優良的設計方案，達到事半功倍的效果。而且會得到解決問題的最佳辦法。

? ? ? 實際中有些人會把模式誤認為模型，大家可以參考以上定義去做識別。

? ? ? 好了， 我們接下來回歸正題，既然我們聊建模，那么什么是模型？

? ? ? 現實中我們經常聽到各種各樣的模型，比如數學模型、算法模型、數據模型、概念模型、內存模型、領域模型、編程模型、行業研究模型。。。哈哈，是不是很亂！反正我是有點暈了，不過能跟模型聯系上的總能給人一種高大上的感覺。

? ? ? 模型（model）是對現實客觀事物的一種表示和抽象，它可以是文字、圖表、公式，也可以是計算機程序或其他實體模型。可以說，模型是把對象實體通過適當的過濾，用適當的表現規則描繪出的簡潔的模仿品，通過這個模仿品，人們可以了解到所研究實體的本質，而且在形式上便于人們對實體進行分析和處理。

? ? ? 模型不只可以描述實物，還可以描述虛擬物件。描述實物就很好理解了，比如建筑模型、汽車模型、飛機模型。

? ? ? 上邊的解釋，是不是不太好理解，好吧，看我下邊的解釋：

? ? ? 按照wiki的定義，模型是指對于某個實際問題或客觀事物、規律進行抽象后的一種形式化表達方式

? ? ? 這里要劃的重點是：抽象！模型是可以簡化人們的認知成本，有助于人們撥開龐雜細節和迷霧，理解客觀事物的。比如古代打仗商討戰術使用的軍事沙盤，所有形勢地理濃縮呈現到臺面上，給大家一種直觀全面的認識。

? ? ? 3 什么是數據模型?

• 百度百科的定義：

• wiki MBA智庫的定義：

• 通俗版的解釋：

? ? ? 數據模型是現實世界或業務邏輯在數據層面的投影，是將數據元素以標準化的模式組織起來，用來模擬現實世界的信息框架和藍圖。

? ? ? 目的和作用：

? ? ? 方便人與人之間信息的傳遞和溝通。

? ? ? 方便人們通過數據模型去理解現實世界。

? ? ? 計算機通過算法模型、規則模型，可以預測客觀虛擬事物的發展或軌跡。

? ? ? 現實世界的虛擬事物，抽象到信息世界邏輯模型，再轉換成計算機世界的數據模型，而計算機能夠存儲和識別的是物理模型。

? ? ? 綜上所述，數據模型有如下幾個用途：

• ?以一種結構化、方便理解特定事實的組織方式呈現給人，比如BI模型、分析模型。
• 幫助更好的理解業務，比如業務模型、概念模型、領域模型、邏輯模型。
• 根據對樣本數據或人的經驗猜想，構建模型，去預測其它同類事物或場景，比如算法模型。
• 將現實世界的信息轉化成數據模型，呈現給計算機，可以用于存儲或計算，比如物理數據存儲模型

? ? ?根據數據模型用途的不同，建模方法也大相徑庭。所以我們在做數據建模前，一定要先想清楚所建模型的具體用途和場景。

? ? ? 我們所說的數倉建模，實際上就是構建一種數據存儲模型，用于結構化存儲我們日常業務行為或信息化系統存儲下來有價值的數據。

? ? ? 數倉建模的目的，是使用數據建模方法來幫助更好地組織和存儲數據，以便在性能、成本、效率和質量之間取得最佳平衡。

• 性能，良好的數據模型能幫助我們快速查詢所需要的數據，減少數據的 110 吞吐。
• 成本，良好的數據模型能極大地減少不必要的數據冗余，也能實現計算結果復用，極大地降低大數據系統中的存儲和計算成本。
• 效率，良好的數據模型能極大地改善用戶使用數據的體驗，提高使用數據的效率。
• 質量，良好的數據模型能改善數據統計口徑的不一致性，減少數據計算錯誤的可能性。

? ? ? 高質量數據建模的重大意義：

• 更低的存儲成本
• 更高的查詢效率
• 清晰明了的數據結構方便理解和使用
• 簡化的ETL處理邏輯
• 更好的數據質量保障（一致性、準確性、完整性、時效性）
• 更靈活的應對變化
• 更好的滿足客戶需求

? ? ? 4 通用的數據建模流程

? ? ? 調研階段?--》》概念模型 --》》 邏輯模型 --》》物理模型 --》》生產應用迭代

? ? ? 調研階段，我們需要做好業務調研、需求調研、數據探查。

? ? ? 業務調研幫助我們了解業務，結合業務去理解需求我們一開始就應該帶著需求去做模型設計。

? ? ? 最后我們還要結合業務和需求去做數據探查以確保原始數據的現狀能夠滿足現有的和未來的業務需求。

? ? ? 應用場景主要分為數倉建模、BI建模、算法建模等等，應用場景不同建模的方法也會差異很大。

? ? ? 只有對業務、需求、數據、應用場景有足夠的了解，才有可能設計出高質量的數據模型。

? ? ? ?概念模型階段，我們必須做好以下幾方面工作：

• 注重全局理解和對整體架構的思考，確定系統的核心以及劃清系統范圍和邊界。類似于領域模型，這一階段我們對于建模的范圍、工作量、重點等會有一個整體直觀的認識，同時確保跟客戶達成共識。
• 需要確定好領域內的基礎和關鍵的業務實體，同時也要給出實體間關系的描述。
• 我們要統一各種業務術語和命名規范。
• 我們應該明確后續使用的數據存儲類型（通常會是某類數據庫，這個我們下文會介紹），因為不同的數據存儲對應的邏輯模型設計可能會有很大差異。

? ? ? 上圖來源自 DAMA2.0 。左邊的是關系型概念數據模型，右邊的是維度型概念數據模型。

? ? ? 邏輯模型階段，需要根據概念模型確定好的邊界做進一步的細化。

? ? ? 邏輯模型文檔比較詳細，所有實體屬性均需添加，實體間關系要清晰描述，需要使用術語，遵循命名規范，采用 Case 工具創建項目文件，對各個實體以及關鍵屬性必須要有清晰的描述。

? ? ? 邏輯模型不受底層實際存儲數據庫的約束，但我們需要定義好實體屬性以及實體間的關系（這里主要是主外鍵關系、一對一或一對多或者多對多關系）、實體和屬性的備注說明、屬性的數據類型以及約束（空值、非空、主外鍵鍵約束）。

? ? ? 我們應該遵循先規范化再逆規范化的設計順序，規范化的設計能夠消除冗余方便理解，逆規范化的設計主要是為了方便使用，但我們切不可把偷懶和不專業當成逆規范化。

? ? ? 上圖來源自 DAMA2.0 僅供大家參考理解。在邏輯模型設計上關系模型設計思路和維度模型差異還是很明顯的。關系模型設計重在捕獲業務流程的規則。維度模型設計重在捕獲業務問題以確定業務流程的運行狀況和性能，是維度型概念數據模型的完全屬性透視圖。

? ? ? 物理模型階段，我們主要是針對不同的數據存儲類型，根據邏輯模型，使用模型設計工具自動生成的。

? ? ? 常用模型設計工具是：PowerDesigner 。

? ? ? 對于主外鍵約束，在 OLTP 系統我們有可能會生成，但在 OLAP 環境下通常不會用。

? ? ? 建模工具可以根據物理模型直接生成模型設計交付文檔、數據庫建表語句等。

? ? ? 需要考慮查詢性能要求和未來一段時間內的存儲空間占用情況。

? ? ? 需要確定使用哪些約束、索引、以及表字段備注的準確完整性等，當然我們之前很多時候基于商業競爭考慮這里是不寫備注的。

? ? ? 生產應用及迭代，物理模型部署以后，會逐步投入生產使用。隨著業務的深入或者變動，模型也需要跟著優化完善。優質的模型可以更好的適應未來需求的變化，但是一勞永逸的模型幾乎是不存在的。

? ? ? 5 數據存儲技術發展的三個階段

? ? ? 在上文我們提到，在概念模型設計階段我們就應該確定好使用何種存儲類型的數據庫。

? ? ? 經過五十多年的發展，數據存儲主要經歷三個大的階段。

• 第一階段：數據庫技術誕生以及三大模型之爭

? ? ? 時間邁入了 1960 年代，野心勃勃的美國人提出了登月計劃，這在當時可以件大事情。可是要飛到月球去，得有個交通工具，美國人起了個希臘神話中太陽神來命名了這個飛船。要制作這個飛船，可以動用了美國龐大的社會資源，可是這個超復雜的東東有著數不清的零件，如何管理它們成了大難題？于是計算機業內的百年老店— IBM 出場了，研發了一款叫做 ICS 的軟件，專門用來管理這些零件信息。后來以此為基礎誕生了大名鼎鼎的 IMS（Information Management System）數據庫。這可是現代數據庫的祖先。直到今天，這一老當益壯的數據庫還在某些銀行重要的核心崗位發揮著余熱。

? ? ? IMS 數據庫是基于層次結構構建的，很容易實現從上往下找，但對于左右橫向查詢就不太好用。另一個老牌公司 GE 看到了，開發出了新的基于網狀的數據庫 IDS。這個貌似蜘蛛網結構的數據庫很快取得的不錯的市場成績。作為行業的老大，IBM 自然不會坐以待斃，在一個超級英雄 EF.Codd（下圖中，曾獲得圖靈獎）的帶領下，提出了關系模型。一時間，層次、網狀、關系三大關系模型殺的渾天黑地。直到一個重要的語言-SQL的出現，改變了整個戰局。這是一個如此簡單易懂的語言，可以很容易描述數據訪問需求，戰局的天平傾斜關系模型。后來，聰明人扎堆的加州大學伯克利分校開發了 INGRES（就是現在的 PostgreSQL ）數據庫，證明關系模型是靠譜的，才為這場戰爭畫上了句號。

? ? ? 注：以上兩段文字摘抄自 CSDN 文章：

? ? ? https://blog.csdn.net/hzbooks/article/details/108480871

• 第二階段：SQL 語言促使關系型數據庫一家獨大。

? ? ? 由于 SQL 超低學習成本，以及關系型數據庫對 SQL 的天然支持，使得關系型數據庫迅速普及并幾乎完全占領市場，像我們耳熟能詳的數據庫，基本上都是關系型數據庫。

• 第三階段：新型數據庫的百花齊放。

? ? ? 后來隨著互聯網用戶規模、數據量越來越大，并且要求 7X24 小時在線，傳統的關系型數據庫由于性能隨著數據量的變大而極速下降、升級擴展困難、擴容成本與數據規模呈指數級增長，這都促使開發者們不得不去探索新的數據存儲。

? ? ? NoSQL (Not Only SQL)，泛指非關系型的數據庫，我們通常會根據不同的使用場景去選擇不同的 NoSQL 數據庫，但由于不支持 SQL 就極大的增加了數據從業者的使用難度，好在后來有人想到在此之上封裝一層 SQL 解析程序，這才加速了 NoSQL 數據存儲的快速普及，比如 Hive、SparkSQL 等等。而其它沒有提供 SQL 查詢或者 SQL 支持不到位的幾乎很難擴大影響力和普及率，有些甚至也已經慢慢被淘汰了。

? ? ? 雖然開放對 SQL 的支持使得 NoSQL 數據存儲得到普及，但其依然存在一些問題使其無法取代傳統關系型數據庫，近些年伴隨著分布式協議的成熟，人們找到了一種新的方式來解決這些痛點。

? ? ? NoSQL (Not Only SQL)，泛指非關系型的數據庫，我們通常會根據不同的使用場景去選擇不同的 NoSQL 數據庫，但由于對 SQL 的支持能力弱，使用群體往往被限制在技術圈層內，通常能夠提供相對完備 SQL 支持能力，或者再次之上再包一層SQL轉化解析的才更容易被普及到更廣大的數據從業者中去，比如Hive、SparkSQL等等。

? ? ? NewSQL ，是對各種新的可擴展/高性能數據庫的簡稱，這類數據庫不僅具有NoSQL對海量數據的存儲管理能力，還保持了傳統數據庫支持ACID和SQL等特性。

? ? ? NewSQL 系統的提出，正是為了滿足整合 NoSQL 和 RDBMS 特性的需求。其中，NoSQL 提供了可擴展性和高可用性，傳統 RDBMS 提供了關系模型、ACID 事務支持和 SQL。用戶已不再考慮一招能解決所有問題（one-size-fits-all）的方案，逐漸轉向針對 OLTP 等不同工作負載給出特定數據庫。大多數 NewSQL 數據庫做了全新的設計，或是主要聚焦于 OLTP，或是采用了 OLTP/OLAP 的混合架構的全新設計。

? ? ? 什么樣的數據庫才能稱之為 NewSQL，應該有以下幾點必備的特性：

• SQL
• ACID Transaction, 支持跨行事務
• Auto-scale 可擴展性
• Auto-failover

? ? ? 最后來一張圖，有點搞笑，不過說真的，對于一個數據管理系統而言，得 SQL 者得天下，因為不支持 SQL 的話很難去普及推廣。SQL 是最偉大的語言，數據從業者的最愛，不接受反駁，哈哈。。。

? ? ? 6 數據建模方法有哪些？

? ? ? 上邊表格，是 DAMA 2.0 給出的建模方法和數據庫交叉應用模式。

? ? ? 數據建模階段，我們需要根據不同應用場景選擇合適的建模方法和數據存儲。同時也需要根據數據存儲類型的不同去調整建模方法，比如關系數據庫里實現的范式模型就是星型模式，在多維數據庫環境中實現的維度模型通常稱為聯機分析處理數據庫。

? ? ? 1.關系建模

? ? ? 關系模型是 1970 年 IBM 研究院， EF.Codd 提出來的，隨后在 1971 年又提出了范式理論。

? ? ? 關系模型也被稱作范式建模，因為其原理的核心是“規范化”理念，規范化是在保證數據存儲完整性的同時，最小化冗余數據的結構化過程。

? ? ? 范式是符合某一種級別的關系模式的集合，目前關系型數據庫有六種范式：第一范式（1NF），第二范式(2NF)，第三范式（3NF），Boyce-Codd范式（BCNF），第四范式（4NF），第五范式（5NF）。

? ? ? 規范化本質上是對數據存儲結構進行拆分，范式等級越高拆的越細，同時規范化程度越高冗余度越低，但會給具體的查詢帶來負擔，所以實際中我們通常到第三范式即可。

? ? ? 除了規范化，我們在進行關系建模時也會用到 ER 模型，即實體關系模型（Entity-relationship model），美籍華裔計算機科學家陳品山提出，是概念數據模型的高層描述所使用的數據模型或模式圖。

? ? ? ER 模型將現實世界抽象成不同的實體，每個實體附帶不同的屬性，實體與實體間的聯系稱為關系，關系又分為（1:1、1:n、m:3）三種。

? ? ? ER 模型和規范化理論共同構成了關系建模理論，OLTP 系統基本上都是使用的關系建模。

? ? ? 樣例一：ER 模型

? ? ? 下邊是網上摘抄的學生-課程-教師實體關系圖，給大家參考一下。

? ? ? 假設每個學生選修若干門課程，且每個學生每選一門課只有一個成績，每個教師只擔任一門課的教學,一門課由若干教師任教。“學生”有屬性：學號、姓名、地址、年齡、性別。“教師”有屬性：職工號、教師姓名、職稱，“課程”有屬性：課程號、課程名。

? ? ? 樣例二：規范化

? ? ? 上文所說的規范化主要實現方案就是拆分，下邊是臨時寫的一個集團公司合作伙伴的實體-關系-屬性樣例，寫的很簡單大家看懂問題就行。

? ? ? 由于供應商和客戶既有共同的屬性又有特有屬性，集團客戶又分為內部客戶和外部客戶。為了降低冗余所以我們需要設計出父子兩類實體，將共有屬性抽象出來做為父實體。

? ? ? 另外，公司與供應商間還會有采購合同，采購合同就應該從供應商實體中分離出來。

? ? ? 2.維度建模

? ? ? 聯機分析處理的概念最早由關系數據庫之父 E．F．Codd 于 1993 年提出。Codd 提出了多維數據庫和多維分析的概念，把業務系統面向業務邏輯、面向事務增刪改查而設計的存儲結構，轉換成面向分析、側重查詢的多維分析型存儲結構。將所有對象都抽象為維度、度量、屬性三類：

• 維度，可以理解為不同分析視角。
• 屬性，用來定義和描述維度。
• 度量，是在一個或多個維度限定下的取值。

? ? ? 存儲格式分為兩種：

• 關系 OLAP（ROLAP）：基于關系數據庫的 OLAP 實現，細節數據以及為聚合后的的粗粒度數據，通常會存儲到關系型數據庫中。
• 多維 OLAP（MOLAP）：有時候會構件 Cube，優點是使用方便，缺點是需要占用大量的存儲空間。

? ? ? 上邊兩段是我在數據倉庫系列開篇里邊摘錄兩段內容。

? ? ? 我發現一個有意思的事情，關系建模和維度建模理論應該是同一個人（關系數據庫之父 E．F．Codd）提出的，維度建模方法比關系建模方法晚出來了 20 年，這 20 年剛好是信息化從開端到普及的階段，OLTP 系統存儲下來的數據開始有了分析應用的需求和場景，而 OLTP 數據庫在進行海量數據的分析處理上又有很多不足，比如大量的資源消耗和性能問題。

? ? ? 而維度模型和多維分析數據庫就是在這樣的背景下，由關系模型的奠基人提出來的，它將客觀世界抽象成維度-屬性-度量這三個概念，從而構成了維度模型。

? ? ? 當維度模型在關系型數據庫里實現就是我們大家常說的雪花模型或星座模型，反三范式或者逆規范化后就變成了星型模型

? ? ? 當維度模型在多維分析數據庫里實現會稱為聯機分析處理數據庫。在 OLAP 多維數據庫時，對這些數據的存儲的索引，采用了維度數據涉及的格式和技術。性能聚集或預計算匯總表通常由多維數據庫引擎建立并管理。由于采用預計算、索引策略和其他優化方法，多維數據庫可實現高性能查詢。

? ? ? 當維度模型在 NoSQL 數據存儲類型里實現，由于索引的缺失和對 Join 實現性能低下，維度模型會退化到星型模型甚至不建模了，就是直接粗暴的拉大寬表。

? ? ? 當維度模型在 NewSQL 數據存儲類型里實現，慢慢的開始回歸到了最早關系型數據庫的星型模型、雪花模型或星座模型中來了，比如最近比較火的 Doris。

? ? ? 3.其它建模方法

? ? ? DAMA 2.0 給出的數據建模方法，還有其它四類：面向對象、基于事實、基于時間、非關系型。

? ? ? 但由于這些建模方法都各有其局限性適用場景有限或者學習和理解難度較大，生產實踐中用的不多，這里就不做介紹了，大家感興趣的可以翻一下 DAMA 2.0 或者參考百度。

? ? ? 第二部分

? ? ? 上篇，我們主要講解了數據建模的理論知識，同時跟大家介紹了數據建模的流程，以及常見的建模方法。

? ? ? 本篇，我們會基于上篇的建模理論，結合真實數倉場景，給大家介紹下完整的數倉建模過程。

? ? ? 1 數倉建模在數倉建設過程中的位置

? ? ? 這張截圖源自之前從 0 到 1 建設數據倉庫的經驗總結，采用的是瀑布模式的展現方式，但實際操作中經常會使用螺旋迭代模式，因為很難有人能夠一步到位的考慮清楚所有細節。

? ? ? 通過業務調研我們熟悉了相關業務過程，需求調研我們明確了本階段數據建設的需求、內容和邊界，數據調研也就是數據探查我們對需要的數據源做了整體摸排，不清楚的就趕緊搞清楚、不對的就趕緊搞對、缺失的就想辦法找補回來或者想辦法補救，真要缺的太多是不是就要中止項目了至少也得重新規劃。我們只是數據的搬運工，并不能憑空編造數據…

? ? ? 隨后我們結合調研階段的成果，做了五大架構設計、落實了技術選型、制定了數倉規范并分發給所有參與者。

? ? ? 接下來我們就進入到了數倉建模階段，數倉建模對于數倉建設的成敗能起到決定性的作用。

? ? ? 經常的我會把數據倉庫類比成一個可以自運行的生態系統，當然我們拿人類自己來類比是最恰當了：人需要吃飯數倉也需要周期性的去源端獲取數據，人有大腦和中樞神經去控制身體數倉有調度去掌控全局，人有骨架肌肉而數倉的骨架肌肉就是數據模型。

? ? ? 數倉模型承載了數據存儲的重要職能，我們需要從全局視角去設計，因為它本身就是一個整體，人有手有腳數倉模型也要分成多個不同的部分，人的手腳身體大腦必須協調一致才能正常活動，數據模型的不同部分也需要協調一致數倉這個生態系統才能正常 運轉。人體如果筋脈不通就會生病，所以 Inmon 的數據建模思路講究的是全局思考統一設計，Kimball 的數據建模思路提出的是總線架構，殊途同歸其實都是提供給大家一套整體設計的方法論去打通數據模型甚至數倉運轉的奇經八脈。

? ? ? 2 理論聯系實踐的數倉建模方法探索

? ? ? 上邊兩頁出自之前的 PPT 供大家參考。

? ? ? 國外的眾多數據從業者經過幾十年的理論研究和實踐探索、多種方法論的碰撞，最終為我們留下了完整的方法論。而兩大權威理論實際上包含的分別是兩大不同的方法論：數倉建設方法和數倉建模方法。

? ? ? Inmon 的數倉建設方法論倡導一種自上而下的瀑布式的建設過程。其數據倉庫模型設計的出發點是整合數據，將各個系統中的數據從全企業視角分主題進行整合，打通所有數據源，剔除冗余、錯誤和不兼容，采用規范化的模型設計方法統一存儲企業所有數據，為數據分析決策服務，但這種規范化的模型設計方法不太適合分析決策這種場景，所以后來又在此基礎之上新增數據集市用于支撐各部門的業務應用。

? ? ? 規范化設計能夠減少冗余避免數據不一致，全局兼容完整的設計能夠保證數據的完整性。但是這種建模方法對建模人員的能力要求非常高，同時也需要對企業業務和數據有全面深入的了解，業務簡單還好但對于復雜的業務場景難免拉長了建設周期、極大增 加了模型設計的難度，以至于在一開始以這種方法實施的數據倉庫大都以失敗告終。

? ? ? Kimball 的數倉建設方法，倡導自下而上建設，不用建設復雜的數據倉庫，直接構建集市用于支撐業務需求，但當數據集市多了以后，多個數據集市間又造成了混亂和不兼容，而為了解決這種問題又提出了總線架構的概念。總線架構包含：一致性維度和一致性事實兩個部分，我們集中設計和管理所有維度、統一定義各種指標，然后讓所有數據集市都遵從這種一致性維度和一致性事實。

? ? ? 由于是直接構建數據集市，不需要過多的數據整合，Kimball 的構建方法相對于 Inmon 就會容易很多。雖然總線架構解決了多個數據集市間的兼容性問題，但這種建模方法還存在以下兩個問題：1、模型的穩定性完全取決于建模師對業務場景對分析需求的理解程度。2、完全基于業務需求的建模對于需求“用不到”的數據就會被丟棄從而造成數據的缺失，本質上講這是違背數倉建設原則的，那么我們就需要永久的保留 ODS 層的數據確保未來需要的時候有辦法可以找補回來。

? ? ? 3 實踐出真知適合自己的才是最好的

? ? ? 實際上我們并不會局限于某一種建模方法，我們需要在熟知各種建模理論的基礎上，結合實際業務場景去選擇合適的方法。

? ? ? 上圖是我們常規的數倉建模流程，接下來我會逐個給大家講解。我們主要采用統一調研、整體規劃、分散設計、集中評審的建設思路，以及自頂向下和自下而上相結合的設計方法。

? ? ? 說明：這里的上和下并非架構圖的上下，而是數據流向的上下游。我們稱之為上游數據源下游數據應用。

? ? ? 我們通過三步調研，了解了業務流程、明確了中短期需求、對源端的數據質量和存儲格式都有了清晰的了解。

? ? ? 三步調研之后，我們會制定數倉分層架構，邏輯上主要分為三層：ODS、DW、DM。目前大家常用的四層五層甚至七層本質上還是對這三層的細化。比如 ODS 層前邊還能有一個 STG 層，STG 英文翻譯 staging，也有說是 stage ，就是一個臨時數據存放區，數據源端每次抽取或上傳過來的數據（通常是增量）先入 STG 做短暫臨時的存放，ETL 進行簡單的清洗、合并、轉換后入 ODS 層存儲。DW 層還會被細分成 DWD、DWS 等，當然還有可能會構建主題寬表，那寬表是否需要再分為明細寬表和匯總寬表呢，寬表應該歸屬于 DW 還是 DM 呢？當然了放哪兒都行這些都不重要邏輯上能講通就行。

? ? ? 分層架構出來后，我們會根據每一層的不同用途有針對性的建模。

? ? ? ODS 層，原始數據存儲區，存儲結構跟源端保持一致原則上不做清洗轉換，命名上：數據來源+源端原始名稱，數據保留時長取決于下游。如果 ODS-DW 過程中沒有信息丟失，可以只保留 3-7 天，保留時間越短對運維人員要求越高。如果該過程有信息丟 失為防止萬一 ODS 層需要永久保留，保留策略有很多，比如從時間上劃分為冷熱數據冷數據可以歸檔轉移到更便宜的存儲，比如對數據內容上進行歸類對于一段時間后就失去價值的數據直接刪除即可例如系統運行日志。

? ? ? DW 層，數據倉庫的核心存儲層，這一層數倉建模的核心，相對標準的思路是我們在明細層采用范式建模的思路自頂向下設計把 ODS 層的數據完整的整合進來，打破孤島（ID 映射）、消除冗余，再往上層可以采用維度建模的思路，基于 DWD 層做輕度匯總、重度匯總，主要以滿足業務需求為主，后期如有需求新增或變化可以基于 DWD 層的完整數據重新匯總。DW 層的數據是需要長期保留的。

? ? ? 當然在大數據場景下，我們通常需要考慮存儲和計算開銷，會去評估這些成本投入是否產生了足夠的價值，明細層往往也會采用維度建模而且完全面向需求去設計，就是說短期用不到的數據我們就先不引入 DW 層了，等需要的時候再根據原始數據算。

? ? ? 這里需要說明一下，數據丟失遠比計算錯誤更需要引起大家重視。由于某些原因很多大數據從業者沒有認識到數據丟失的慘重后果。記得之前有一次為了降低成本老板甚至讓刪除一年之前的原始歸檔數據，結果沒幾天新的需求 DW 層無法滿足需要重刷歷史數據，幸好當時我們找借口拖著沒刪。

? ? ? DM 層，數據集市層在邏輯上會包含多個數據集市。DWS 層匯總的通常是公用的、經常被使用的數據，絕大多數常規業務也都可以基于 DWS 直接實現，滿足不了的時候我們需要根據各部門或者項目的需求去重新組織構建對應的數據集市，這一層通常也是采用維度建模方法自下而上完全面向需求去設計，數據集市往往伴隨著對應的部門或項目需求而建立或者終止。

? ? ? 這里先做個簡單的總結：

• ODS 不用建模直接用源端數據存儲結構。
• DWD 范式建模，保證 ODS 到 DW 信息不丟失，如果 DWD 也采用維度建模 ODS 數據一定要長期保留。
• DWS 維度建模面向需求設計，存儲一些全域經常被使用到的數據。
• DM 完全面向需求建模，生命周期跟對應需求的生命周期一致。

? ? ? 橫向分層講完了，那我們接下來聊聊縱向分域吧。

? ? ? 分域的目的是為了給數據或表進行歸類，從而方便數據管理。

? ? ? 分域的概念也主要用在 DW 和 DM 層。

• DW 層主要面向業務過程劃分數據域，數據域下邊再劃分多個主題，主題下邊會有多個業務過程，理論上每個業務過程對應一張表，但當所有表設計好以后需要結合 ETL 過程和業務使用習慣考慮是否需要對多張表進行合并操作。
• DM 層劃分數據域的方式就簡單了，完全對應需求場景或者使用部門就好了。

? ? ? 分層和分域的概念講完后，我們接下來需要制定相應的模型設計和使用規范。具體到落地階段了，那么很多事情我們就必須把它明確下來，上邊我們提到的內容在具體細節上可能會有多種選擇，比如 ODS 數據保留策略、DWD 采用何種建模方法、有無主題寬表以及寬表歸屬哪一層等等，這些都需要通過規范去明確從而避免多人協作過程中的混亂。更具體的內容可以參考文末推薦閱讀里的相關歷史文章。

? ? ? 對于一致性維度、一致性事實的保障策略，也需要通過規范去明確和約束，確保同一個維度或度量在數倉的所有地方有相同的含義。我們也要通過規范教會大家如何才能建設出來統一高質量的數據模型。

? ? ? 以上的統一調研、整體規劃（分層架構、規范制定、主題域劃分）后，我們進入了分散設計的階段。

? ? ? 分散設計

? ? ? 到這里，由于數倉模型設計的復雜性，我們需要多人合作共同完成建模工作，這時候架構師或者建模師可以結合之前分層分域的成果，按層按域將模型設計任務進行拆解后分發給不同的人完成。我們通常可以這樣拆分：ODS 層可以按源端類型拆分、DW 層可以按數據域分成多塊、DM 層就按數據集市拆分。這樣核心建模師只需要完成 DW 層即可，每人分別負責不同的數據域，ODS 層甚至可以分配給 ETL 工程師負責這樣剛好順便熟悉了源端存儲結構以及對數據質量的探查，DM 層完全可以分配給 BI 工程師通常會開發成單表查詢的模式。這樣子做完分工后，在模型設計規范的統一指導和架構師或總建模師的協調下，相信最終是可以設計出一套統一完善且相互兼容的數倉模型的。

? ? ? 統一評審

? ? ? 雖然我們有完善的模型設計規范做指導，但考慮到各個部分建模者的不同情況，設計上難免會有疏漏，這就需要最終的統一評審環節。我們可以逐層分域的去評審，參與方主要有以下角色：架構師、總建模師、該模塊主建模師、業務專家、數據運維、ETL 工程師。

? ? ? 交付與迭代

? ? ? 統一評審結束后，我們最終會形成一套完整的數據模型設計文檔，通常是邏輯模型。

? ? ? 我們根據邏輯模型生成物理模型，然后交付給 ETL 工程師負責后續的數據開發。我們通常需要 ETL 工程師除了具備基本的開發能力外，還要有一定的數據探查、數據建模能力，確保在數據開發階段能夠發現原有模型設計的不足并及時反饋，比如現有模型如果使得 ETL 開發變的異常復雜或者程序性能低下，這時候通常就需要考慮修改模型設計了。我們經常使用的維度退化和寬表“模型”就是最常見的為了提高程序執行效率而做的規范化方面的妥協。