數(shù)據(jù)倉庫建模方法論

建模方法論

數(shù)倉的建?；蛘叻謱?，其實都是為了更好的去組織、管理、維護數(shù)據(jù),所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內存區(qū)域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區(qū)等)，大到國家的省市區(qū)的劃分，無一例外的都是為了更好的組織管理

  1. 訪問性能：能夠快速查詢所需的數(shù)據(jù)，減少數(shù)據(jù)I/O。
  2. 數(shù)據(jù)成本：減少不必要的數(shù)據(jù)冗余，實現(xiàn)計算結果數(shù)據(jù)復用，降低大數(shù)據(jù)系統(tǒng)中的存儲成本和計算成本。
  3. 使用效率：改善用戶應用體驗，提高使用數(shù)據(jù)的效率。
  4. 數(shù)據(jù)質量：改善數(shù)據(jù)統(tǒng)計口徑的不一致性，減少數(shù)據(jù)計算錯誤的可能性，提供高質量的、一致的數(shù)據(jù)訪問平臺。

    需要注意的建模其實是和公司的業(yè)務、公司的數(shù)據(jù)量、公司使用的工具、公司數(shù)據(jù)的使用方式密不可分的，因為模型是概念上的東西，需要理論落地至于落地到什么程度，就取決于公司的現(xiàn)狀了

范式建模(關系型數(shù)據(jù)庫)

范式建模法其實是我們在構建數(shù)據(jù)模型常用的一個方法，該方法的主要由Inmon所提倡，主要解決關系型數(shù)據(jù)庫得數(shù)據(jù)存儲，利用的一種技術層面上的方法，主要用于業(yè)務系統(tǒng)，所以范式建模主要是利用關系型數(shù)據(jù)庫進行數(shù)倉建設

目前，我們在關系型數(shù)據(jù)庫中的建模方法，大部分采用的是三范式建模法。

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

三范式

第一范式

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

1NF是所有關系型數(shù)據(jù)庫的最基本要求，你在關系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS），例如SQL Server，Oracle，MySQL中創(chuàng)建數(shù)據(jù)表的時候，如果數(shù)據(jù)表的設計不符合這個最基本的要求，那么操作一定是不能成功的。也就是說，只要在RDBMS中已經(jīng)存在的數(shù)據(jù)表，一定是符合1NF的

第二范式

這里我們先說一下，為什么有了第一范式，還需要第二范式，那是應為第一范式，不能消除重復，存在數(shù)據(jù)冗余過大，導致插入異常，刪除異常，修改異常的問題

所以要求每張表都要有一個主鍵，其它字段(列)完全依賴主鍵，也就是說要求實體的屬性完全依賴于主關鍵字。也就是說表只描述一個事實，因為這賬號表描述了3個事實，學生、課程、和系

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

第三范式

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

范式建模的優(yōu)缺點

優(yōu)點

節(jié)約存儲(尤其是利用數(shù)據(jù)庫進行數(shù)倉建設的時候)

規(guī)范化帶來的好處是通過減少數(shù)據(jù)冗余**提高更新數(shù)據(jù)的效率，同時保證數(shù)據(jù)完整性**。

結構清晰，易于理解

缺點

構建比較復雜

查詢復雜(需要很多的關聯(lián))

不適合在大數(shù)據(jù)環(huán)境下構建(1 查詢復雜 2 存儲很便宜)

由于建模方法限定在關系型數(shù)據(jù)庫之上，在某些時候反而限制了整個數(shù)據(jù)倉庫模型的靈活性，性能等，特別是考慮到數(shù)據(jù)倉庫的底層數(shù)據(jù)向數(shù)據(jù)集市的數(shù)據(jù)進行匯總時，需要進行一定的變通才能滿足相應的需求。

為什么要學習范式建模

上游數(shù)據(jù)源往往是業(yè)務數(shù)據(jù)庫，而這些業(yè)務數(shù)據(jù)庫采用的實范式建模，所以了解范式建?？梢詭椭覀內ズ侠淼慕ㄔO數(shù)倉

如果了解范式建模，從er 模型可以了解到數(shù)據(jù)架構，例如一個電商系統(tǒng)，從er模型就可以知道哪些涉及到商品的管理、用戶的管理、訂單管理，拿到這些關系之后，我們就可以更好的進行數(shù)倉管理與建
數(shù)據(jù)源的規(guī)范定義需要我們了解范式理論，可以更好的和業(yè)務系統(tǒng)進行對接

數(shù)倉的稀有系統(tǒng)，如報表系統(tǒng)設計的時候也會使用到范式建模

ER實體建模

將事務抽象為"實體"（Entity）、"屬性"（Property）、"關系"（Relationship）來表示數(shù)據(jù)關聯(lián)和事物描述，這種對數(shù)據(jù)的抽象建模通常被稱為ER實體關系模型。

實體建模法并不是數(shù)據(jù)倉庫建模中常見的一個方法，它來源于哲學的一個流派。

從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實 體，以及實體與實體之間的關系組成。我們在數(shù)據(jù)倉庫的建模過程中完全可以引入這個抽象的方法，將整個業(yè)務也可以劃分成一個個的實體，而每個實體之間的 關系，以及針對這些關系的說明就是我們數(shù)據(jù)建模需要做的工作。

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

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業(yè)務過程劃分成 3 個部分，實體，事件和說明。

描述一個簡單的事實：“小明開車去學校上學”。以這個業(yè)務事實為例，我們可以把“小明”，“學?！笨闯墒且粋€實體， “上學”描述的是一個業(yè)務過程，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。

應用場景

ER模型是數(shù)據(jù)庫設計的理論基礎，當前幾乎所有的OLTP系統(tǒng)設計都采用ER模型建模的方式。

Bill Inom提出的數(shù)倉理論，推薦采用ER關系模型進行建模。

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

由于實體建模法，能夠很輕松的實現(xiàn)業(yè)務模型的劃分，因此，在業(yè)務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。

業(yè)務歸納

使用的抽象歸納方法其實很簡單，任何業(yè)務可以看成 3 個部分：

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

維度建模

概念和背景

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

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

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

維度模型通常以一種被稱為星型模式的方式構建。所謂星型模式，就是以一個事實表為中心，周圍環(huán)繞著多個維度表。

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

為什么選擇維度建模

適配大數(shù)據(jù)的處理方式

維度模型的非強范式的，可以更好的利用大數(shù)據(jù)處理框架的處理能力，避免范式操作的過多關聯(lián)操作，可以實現(xiàn)高度的并行化。

數(shù)據(jù)倉庫大多數(shù)時候是比較適合使用星型模型構建底層數(shù)據(jù)Hive表，通過大量的冗余來提升查詢效率，星型模型對OLAP的分析引擎支持比較友好，這一點在Kylin中比較能體現(xiàn)。

雪花模型在關系型數(shù)據(jù)庫中如MySQL，Oracle中非常常見，尤其像電商的數(shù)據(jù)庫表。

自下而上的建設現(xiàn)狀

表已經(jīng)存在，業(yè)務已經(jīng)開發(fā)完畢，需求直接提過來了，這幾乎是一個普遍現(xiàn)狀，因為很少有公司會提前成立數(shù)據(jù)部門，讓數(shù)據(jù)部門跟隨著業(yè)務從頭開始一直成長，都是當業(yè)務發(fā)展到一定的階段了，想通過數(shù)據(jù)來提高公司的運營效果

簡單的模型 使用簡單

這個模型相對來說是比較簡單的，簡單主要體現(xiàn)在兩個方面

  1. 維度建模非常直觀，緊緊圍繞著業(yè)務模型，可以直觀的反映出業(yè)務模型中的業(yè)務問題。不需要經(jīng)過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優(yōu)勢。
  2. 星型結構的實現(xiàn)不用考慮很多正規(guī)化的因素，設計與實現(xiàn)都比較簡單。

分層和建模的關系

明細層的范式模型

明細層采用傳統(tǒng)的三范式關系模型。這一層次的數(shù)據(jù)模型要將業(yè)務過程描述清楚，將源數(shù)據(jù)（即業(yè)務系統(tǒng)）中隱含的、有歧義的概念進行清晰化，如活躍用戶、VIP用戶等。該層次的數(shù)據(jù)模型追求的目標是靈活地表達業(yè)務過程，要保證數(shù)據(jù)一致性、唯一性、正確性，以盡量少的代價與源數(shù)據(jù)保持數(shù)據(jù)同步，同時該層次的數(shù)據(jù)模型不建議開給不懂技術的業(yè)務人員直接使用，因此，采用關系型的三范式模型是最佳的選擇。

集市層的維度模型

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

模型實現(xiàn)

模型的實現(xiàn)主要指的是在維度建模過程中，需要對維度表和事實表進行關聯(lián)設計，而這里我們對維度表的設計，就決定了我們最終與事實表關聯(lián)的之后的形態(tài)。也就是說我們可以根據(jù)事實表和維度表的關系，又可將常見的模型分為星型模型和雪花型模型

星型模型和雪花模型的主要區(qū)別在于對維度表的拆分，對于雪花模型，維度表的設計更加規(guī)范，一般符合3NF；而星型模型，一般采用降維的操作，利用冗余來避免模型過于復雜，提高易用性和分析效率。

星型模型

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

當所有維表都直接連接到“ 事實表”上時，整個圖解就像星星一樣，故將該模型稱為星型模型

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

雪花模型

星形模式中的維表相對雪花模式來說要大，而且不滿足規(guī)范化設計。雪花模型相當于將星形模式的大維表拆分成小維表，滿足了規(guī)范化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發(fā)難度增大，而數(shù)據(jù)冗余問題在數(shù)據(jù)倉庫里并不嚴重

可以認為雪花模型是星型模型的一個擴展，每個維度表可以繼續(xù)向外擴展，連接多個子維度。

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

星座模型

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

可以認為是多個事實表的關聯(lián)或者是星型模型的關聯(lián)，其實到了業(yè)務發(fā)展后期都是星座模型

應用場景

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

針對性強，主要應用于數(shù)據(jù)倉庫構建和OLAP引擎底層數(shù)據(jù)模型

優(yōu)點

方便使用，模型簡單

適合大數(shù)據(jù)下的處理操作(其實就是shuffle)

適合OLAP操作(上鉆下鉆)

維度建模非常直觀，緊緊圍繞著業(yè)務模型，可以直觀的反映出業(yè)務模型中的業(yè)務問題。不需要經(jīng)過特別的抽象處理，即可以完成維度建模。

可擴展，維度模型是可擴展的。由于維度模型允許數(shù)據(jù)冗余，因此當向一個維度表或事實表中添加字段時，不會像關系模型那樣產生巨大的影響，帶來的結果就是更容易容納不可預料的新增數(shù)據(jù)。

缺點

數(shù)據(jù)冗余，維度補全后造成的數(shù)據(jù)浪費

靈活性差，維度變化造成的數(shù)據(jù)更新量大(例如刷數(shù)據(jù)的時候，需要刷大量的表)

與典型的范式理論差異很大，如數(shù)據(jù)不一致，比如用戶發(fā)起購買行為的時候的數(shù)據(jù)，和我們維度表里面存放的數(shù)據(jù)不一致

既然如此為什么還要使用范式建模呢，其實和我們使用的工具有關系

由于在構建星型模式之前需要進行大量的數(shù)據(jù)預處理，因此會導致大量的數(shù)據(jù)處理工作。而且，當業(yè)務發(fā)生變化，需要重新進行維度的定義時，往往需要重新進行維度數(shù)據(jù)的預處理。而在這些與處理過程中，往往會導致大量的數(shù)據(jù)冗余。

如果只是依靠單純的維度建模，不能保證數(shù)據(jù)來源的一致性和準確性，而且在數(shù)據(jù)倉庫的底層，不是特別適用于維度建模的方法。

維度建模的領域主要適用與數(shù)據(jù)集市層，它的最大的作用其實是為了解決數(shù)據(jù)倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業(yè)務實體之間的復雜關系的抽象方法

總結

上述的這些方法都有自己的優(yōu)點和局限性，在創(chuàng)建自己的數(shù)據(jù)倉庫模型的時候，可以參考使用上述的三種數(shù)據(jù)倉庫得建模方法，在各個不同階段采用不同的方法，從而能夠保證整個數(shù)據(jù)倉庫建模的質量。

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




作者：柯廣的網(wǎng)絡日志

微信公眾號：Java大數(shù)據(jù)與數(shù)據(jù)倉庫