數據倉庫建模方法論

建模方法論

數倉的建模或者分層，其實都是爲了更好的去組織、管理、維護數據,因此當你站在更高的維度去看的話，全部的劃分都是爲了更好的管理。小到JVM 內存區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是爲了更好的組織管理

1. 訪問性能：可以快速查詢所需的數據，減小數據I/O。
2. 數據成本：減小沒必要要的數據冗餘，實現計算結果數據複用，下降大數據系統中的存儲成本和計算成本。
3. 使用效率：改善用戶應用體驗，提升使用數據的效率。
4. 數據質量：改善數據統計口徑的不一致性，減小數據計算錯誤的可能性，提供高質量的、一致的數據訪問平臺。

須要注意的建模實際上是和公司的業務、公司的數據量、公司使用的工具、公司數據的使用方式密不可分的，由於模型是概念上的東西，須要理論落地至於落地到什麼程度，就取決於公司的現狀了

範式建模(關係型數據庫)

範式建模法實際上是咱們在構建數據模型經常使用的一個方法，該方法的主要由Inmon所提倡，主要解決關係型數據庫得數據存儲，利用的一種技術層面上的方法，主要用於業務系統，因此範式建模主要是利用關係型數據庫進行數倉建設

目前，咱們在關係型數據庫中的建模方法，大部分採用的是三範式建模法。

符合3NF要求的數據庫設計，基本上解決了數據冗餘過大，插入異常，修改異常，刪除異常的問題。

三範式

第一範式

屬性值不可再分，說直白點就是一列裏面不能包含多個小列，就像下面這樣

1NF是全部關係型數據庫的最基本要求，你在關係型數據庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中建立數據表的時候，若是數據表的設計不符合這個最基本的要求，那麼操做必定是不能成功的。也就是說，只要在RDBMS中已經存在的數據表，必定是符合1NF的

第二範式

這裏咱們先說一下，爲何有了第一範式，還須要第二範式，那是應爲第一範式，不能消除重複，存在數據冗餘過大，致使插入異常，刪除異常，修改異常的問題

因此要求每張表都要有一個主鍵，其它字段(列)徹底依賴主鍵，也就是說要求實體的屬性徹底依賴於主關鍵字。也就是說表只描述一個事實，由於這帳號表描述了3個事實，學生、課程、和系

例如，若是花名冊裏只有名字，沒有學號，則重名的話會很麻煩。
所謂徹底依賴是指不能存在僅依賴主關鍵字一部分的屬性，若是存在，那麼這個屬性和主關鍵字的這一部分應該分離出來造成一個新的實體，新實體與原實體之間是一對多的關係，例如上面的系主任和系名 就是不依賴學號的，因此這裏應該單獨拆出來

第三範式

全部字段只能直接依賴主鍵，不得依賴於其它字段(非主屬性) 消除依賴傳遞。所謂傳遞函數依賴指的是若是存在"A-->B-->C"的決定關係，則C傳遞函數依賴於A。也就是說表中的字段和主鍵直接對應不依靠其餘中間字段，說白了就是，決定某字段值的必須是主鍵，而不是一個依賴於主鍵的其餘字段

範式建模的優缺點

優勢

節約存儲(尤爲是利用數據庫進行數倉建設的時候)

規範化帶來的好處是經過減小數據冗餘****提升更新數據的效率，同時保證數據完整性。

結構清晰，易於理解

缺點

構建比較複雜

查詢複雜(須要不少的關聯)

不適合在大數據環境下構建(1 查詢複雜 2 存儲很便宜)

因爲建模方法限定在關係型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮到數據倉庫的底層數據向數據集市的數據進行彙總時，須要進行必定的變通才能知足相應的需求。

爲何要學習範式建模

上游數據源每每是業務數據庫，而這些業務數據庫採用的實範式建模，因此瞭解範式建模能夠幫助咱們去合理的建設數倉

若是瞭解範式建模，從er 模型能夠了解到數據架構，例如一個電商系統，從er模型就能夠知道哪些涉及到商品的管理、用戶的管理、訂單管理，拿到這些關係以後，咱們就能夠更好的進行數倉管理與建
數據源的規範定義須要咱們瞭解範式理論，能夠更好的和業務系統進行對接

數倉的稀有系統，如報表系統設計的時候也會使用到範式建模

ER實體建模

將事務抽象爲"實體"（Entity）、"屬性"（Property）、"關係"（Relationship）來表示數據關聯和事物描述，這種對數據的抽象建模一般被稱爲ER實體關係模型。

實體建模法並非數據倉庫建模中常見的一個方法，它來源於哲學的一個流派。

從哲學的意義上說，客觀世界應該是能夠細分的，客觀世界應該能夠分紅由一個個實 體，以及實體與實體之間的關係組成。咱們在數據倉庫的建模過程當中徹底能夠引入這個抽象的方法，將整個業務也能夠劃分紅一個個的實體，而每一個實體之間的 關係，以及針對這些關係的說明就是咱們數據建模須要作的工做。

在平常建模中，"實體"用矩形表示，"關係"用菱形，"屬性"用橢圓形。ER實體關係模型也稱爲E-R關係圖

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即咱們能夠將任何一個業務過程劃分紅 3 個部分，實體，事件和說明。

描述一個簡單的事實：「小明開車去學校上學」。以這個業務事實爲例，咱們能夠把「小明」，「學校」當作是一個實體， 「上學」描述的是一個業務過程，咱們在這裏能夠抽象爲一個具體「事件」，而「開車去」則能夠當作是事件「上學」的一個說明。

應用場景

ER模型是數據庫設計的理論基礎，當前幾乎全部的OLTP系統設計都採用ER模型建模的方式。

Bill Inom提出的數倉理論，推薦採用ER關係模型進行建模。

BI架構提出分層架構，數倉底層ods、dwd也多采用ER關係模型進行設計。

因爲實體建模法，可以很輕鬆的實現業務模型的劃分，所以，在業務建模階段和領域概念建模階段，實體建模法有着普遍的應用。

業務概括

使用的抽象概括方法其實很簡單，任何業務能夠當作 3 個部分：

1. 實體，主要指領域模型中特定的概念主體，指發生業務關係的對象
2. 事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程
3. 說明，主要是針對實體和事件的特殊說明

維度建模

概念和背景

維度模型是數據倉庫領域大師Ralph Kimball 所倡導，他的《數據倉庫工具箱》，是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，所以它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。

維度建模源自數據集市，主要面向分析場景 Ralph Kimball 推崇數據集市的集合爲數據倉庫，同時也提出了對數據集市的維度建模，將數據倉庫中的表劃分爲事實表、維度表兩種類型。

通常也稱之爲星型結構建模，有時也加入一些雪花模型在裏面。維度建模是一種面向用戶需求的、容易理解的、訪問效率高的建模方法

維度模型一般以一種被稱爲星型模式的方式構建。所謂星型模式，就是以一個事實表爲中心，周圍環繞着多個維度表。

還有一種模式叫作雪花模式，是對維度作進一星型模型作OLAP分析很方便

爲何選擇維度建模

適配大數據的處理方式

維度模型的非強範式的，能夠更好的利用大數據處理框架的處理能力，避免範式操做的過多關聯操做，能夠實現高度的並行化。

數據倉庫大多數時候是比較適合使用星型模型構建底層數據Hive表，經過大量的冗餘來提高查詢效率，星型模型對OLAP的分析引擎支持比較友好，這一點在Kylin中比較能體現。

雪花模型在關係型數據庫中如MySQL，Oracle中很是常見，尤爲像電商的數據庫表。

自下而上的建設現狀

表已經存在，業務已經開發完畢，需求直接提過來了，這幾乎是一個廣泛現狀，由於不多有公司會提早成立數據部門，讓數據部門跟隨着業務從頭開始一直成長，都是當業務發展到必定的階段了，想經過數據來提升公司的運營效果

簡單的模型 使用簡單

這個模型相對來講是比較簡單的，簡單主要體如今兩個方面

1. 維度建模很是直觀，牢牢圍繞着業務模型，能夠直觀的反映出業務模型中的業務問題。不須要通過特別的抽象處理，便可以完成維度建模。這一點也是維度建模的優點。
2. 星型結構的實現不用考慮不少正規化的因素，設計與實現都比較簡單。

分層和建模的關係

明細層的範式模型

明細層採用傳統的三範式關係模型。這一層次的數據模型要將業務過程描述清楚，將源數據（即業務系統）中隱含的、有歧義的概念進行清晰化，如活躍用戶、VIP用戶等。該層次的數據模型追求的目標是靈活地表達業務過程，要保證數據一致性、惟一性、正確性，以儘可能少的代價與源數據保持數據同步，同時該層次的數據模型不建議開給不懂技術的業務人員直接使用，所以，採用關係型的三範式模型是最佳的選擇。

集市層的維度模型

集市層是按照業務主題、分主題構建出來的、面向特定部門或人員的數據集合，該層次的數據模型會開放給業務人員使用，進行數據挖掘及業務分析。因爲業務員多數不懂數據庫技術，缺乏將業務需求轉換爲關係型數據結構的邏輯思惟，更寫不出複雜的SQL語句，所以，越簡單的數據模型，越能被他們所接受，所以，這個層次所構建出來的數據模型，要按照業務過程進行組織，每一個事實表表明一個獨立的業務過程，事實表之間不存在直接的依賴關係，這樣業務人員能夠很容易地將分析需求對應到事實表上，利用工具或手工寫出簡單的SQL，將統計數據提取出來進行分析。

模型實現

模型的實現主要指的是在維度建模過程當中，須要對維度表和事實表進行關聯設計，而這裏咱們對維度表的設計，就決定了咱們最終與事實表關聯的以後的形態。也就是說咱們能夠根據事實表和維度表的關係，又可將常見的模型分爲星型模型和雪花型模型

星型模型和雪花模型的主要區別在於對維度表的拆分，對於雪花模型，維度表的設計更加規範，通常符合3NF；而星型模型，通常採用降維的操做，利用冗餘來避免模型過於複雜，提升易用性和分析效率。

星型模型

核心是一個事實表及多個非正規化描述的維度表組成，維度表之間是沒有關聯的，維度表是直接關聯到事實表上的，只有當維度表極大，存儲空間是個問題時，才考慮雪花型維度，簡而言之，最好就用星型維度便可

當全部維表都直接鏈接到「 事實表」上時，整個圖解就像星星同樣，故將該模型稱爲星型模型

星型架構是一種非正規化的結構，多維數據集的每個維度都直接與事實表相鏈接，不存在漸變維度，因此數據有必定的冗餘，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B 的信息分別存儲了兩次，即存在冗餘。

雪花模型

星形模式中的維表相對雪花模式來講要大，並且不知足規範化設計。雪花模型至關於將星形模式的大維表拆分紅小維表，知足了規範化設計。然而這種模式在實際應用中不多見，由於這樣作會致使開發難度增大，而數據冗餘問題在數據倉庫裏並不嚴重

能夠認爲雪花模型是星型模型的一個擴展，每一個維度表能夠繼續向外擴展，鏈接多個子維度。

當有一個或多個維表沒有直接鏈接到事實表上，而是經過其餘維錶鏈接到事實表上時，其圖解就像多個雪花鏈接在一塊兒，故稱雪花模型

星座模型

前面介紹的兩種維度建模方法都是多維表對應單事實表，但在不少時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。

能夠認爲是多個事實表的關聯或者是星型模型的關聯，其實到了業務發展後期都是星座模型

應用場景

維度建模是面向分析場景而生，針對分析場景構建數倉模型，重點關注快速、靈活的解決分析需求，同時可以提供大規模數據的快速響應性能。

針對性強，主要應用於數據倉庫構建和OLAP引擎底層數據模型

優勢

方便使用，模型簡單

適合大數據下的處理操做(其實就是shuffle)

適合OLAP操做(上鑽下鑽)

維度建模很是直觀，牢牢圍繞着業務模型，能夠直觀的反映出業務模型中的業務問題。不須要通過特別的抽象處理，便可以完成維度建模。

可擴展，維度模型是可擴展的。因爲維度模型容許數據冗餘，所以當向一個維度表或事實表中添加字段時，不會像關係模型那樣產生巨大的影響，帶來的結果就是更容易容納不可預料的新增數據。

缺點

數據冗餘，維度補全後形成的數據浪費

靈活性差，維度變化形成的數據更新量大(例如刷數據的時候，須要刷大量的表)

與典型的範式理論差別很大，如數據不一致，好比用戶發起購買行爲的時候的數據，和咱們維度表裏面存放的數據不一致

既然如此爲何還要使用範式建模呢，其實和咱們使用的工具備關係

因爲在構建星型模式以前須要進行大量的數據預處理，所以會致使大量的數據處理工做。並且，當業務發生變化，須要從新進行維度的定義時，每每須要從新進行維度數據的預處理。而在這些與處理過程當中，每每會致使大量的數據冗餘。

若是隻是依靠單純的維度建模，不能保證數據來源的一致性和準確性，並且在數據倉庫的底層，不是特別適用於維度建模的方法。

維度建模的領域主要適用與數據集市層，它的最大的做用實際上是爲了解決數據倉庫建模中的性能問題。維度建模很難可以提供一個完整地描述真實業務實體之間的複雜關係的抽象方法

總結

上述的這些方法都有本身的優勢和侷限性，在建立本身的數據倉庫模型的時候，能夠參考使用上述的三種數據倉庫得建模方法，在各個不一樣階段採用不一樣的方法，從而可以保證整個數據倉庫建模的質量。

方法論僅僅停留在理論層面上，落地實現的才真正決定了數倉設計的好壞，固然再好的方法，只有在合適的階段使用，纔有意義，才能發揮它最大的價值