漫談數(shù)據(jù)倉庫之維度建模 - 簡書 http://www.reibang.com/p/17baa9f96ca7

0x00 前言
下面的內(nèi)容，是筆者在學習和工作中的一些總結(jié)怀偷，其中概念性的內(nèi)容大多來自書中吧凉，實踐性的內(nèi)容大多來自自己的工作和個人理解愚战。由于資歷尚淺瞻想，難免會有很多錯誤咆耿，望批評指正羹与！

概述
數(shù)據(jù)倉庫包含的內(nèi)容很多故硅，它可以包括架構(gòu)、建模和方法論纵搁。對應到具體工作中的話吃衅，它可以包含下面的這些內(nèi)容：
以Hadoop、Spark腾誉、Hive等組建為中心的數(shù)據(jù)架構(gòu)體系徘层。
各種數(shù)據(jù)建模方法，如維度建模利职。
調(diào)度系統(tǒng)趣效、元數(shù)據(jù)系統(tǒng)、ETL系統(tǒng)猪贪、可視化系統(tǒng)這類輔助系統(tǒng)跷敬。

我們暫且不管數(shù)據(jù)倉庫的范圍到底有多大，在數(shù)據(jù)倉庫體系中热押，數(shù)據(jù)模型的核心地位是不可替代的西傀。
因此，下面的將詳細地闡述數(shù)據(jù)建模中的典型代表：維度建模桶癣，對它的的相關(guān)理論以及實際使用做深入的分析拥褂。
文章結(jié)構(gòu)
本文將按照下面的順序進行闡述：
先介紹比較經(jīng)典和常用的數(shù)據(jù)倉庫模型，并分析其優(yōu)缺點牙寞。
詳細介紹維度建模的基本概念以及相關(guān)理論饺鹃。
為了能更真切地理解什么是維度建模，我將模擬一個大家都十分熟悉的電商場景间雀，運用前面講到的理論進行建模悔详。
理論和現(xiàn)實的工作場景畢竟會有所差距，這一塊雷蹂，我會分享一下企業(yè)在實際的應用中所做出的取舍。

0x01 經(jīng)典數(shù)據(jù)倉庫模型
下面將分別介紹四種數(shù)據(jù)倉庫模型杯道，其中前三種模型分別對應了三本書：《數(shù)據(jù)倉庫》匪煌、《數(shù)據(jù)倉庫工具箱》和《數(shù)據(jù)架構(gòu) 大數(shù)據(jù) 數(shù)據(jù)倉庫以及Data Vault》责蝠，這三本書都有中文版，非常巧的是萎庭，我只有三本數(shù)據(jù)倉庫的書霜医，正好對應了這三種理論。
Anchor模型我并不是特別熟悉驳规，放在這里以供參考肴敛。
一、實體關(guān)系（ER）模型
數(shù)據(jù)倉庫之父Immon的方法從全企業(yè)的高度設(shè)計一個3NF模型吗购，用實體加關(guān)系描述的數(shù)據(jù)模型描述企業(yè)業(yè)務(wù)架構(gòu)医男，在范式理論上符合3NF，它與OLTP系統(tǒng)中的3NF的區(qū)別捻勉，在于數(shù)據(jù)倉庫中的3NF上站在企業(yè)角度面向主題的抽象镀梭，而不是針對某個具體業(yè)務(wù)流程的實體對象關(guān)系抽象，它更多的是面向數(shù)據(jù)的整合和一致性治理踱启，正如Immon所希望達到的：“single version of the truth”报账。
但是要采用此方法進行構(gòu)建，也有其挑戰(zhàn)：
需要全面了解企業(yè)業(yè)務(wù)和數(shù)據(jù)
實施周期非常長
對建模人員的能力要求也非常高

二埠偿、維度模型
維度模型是數(shù)據(jù)倉庫領(lǐng)域另一位大師Ralph Kimall所倡導透罢，他的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling，中文名《數(shù)據(jù)倉庫工具箱》冠蒋，是數(shù)據(jù)倉庫工程領(lǐng)域最流行的數(shù)倉建模經(jīng)典羽圃。維度建模以分析決策的需求出發(fā)構(gòu)建模型，構(gòu)建的數(shù)據(jù)模型為分析需求服務(wù)浊服，因此它重點解決用戶如何更快速完成分析需求统屈，同時還有較好的大規(guī)模復雜查詢的響應性能。
典型的代表是我們比較熟知的星形模型牙躺，以及在一些特殊場景下適用的雪花模型愁憔。
三、DataVault
DataVault是Dan Linstedt發(fā)起創(chuàng)建的一種模型方法論孽拷，它是在ER關(guān)系模型上的衍生吨掌，同時設(shè)計的出發(fā)點也是為了實現(xiàn)數(shù)據(jù)的整合，并非為數(shù)據(jù)決策分析直接使用脓恕。它強調(diào)建立一個可審計的基礎(chǔ)數(shù)據(jù)層膜宋，也就是強調(diào)數(shù)據(jù)的歷史性可追溯性和原子性，而不要求對數(shù)據(jù)進行過度的一致性處理和整合炼幔；同時也基于主題概念將企業(yè)數(shù)據(jù)進行結(jié)構(gòu)化組織秋茫，并引入了更進一步的范式處理來優(yōu)化模型應對源系統(tǒng)變更的擴展性。
它主要由：Hub（關(guān)鍵核心業(yè)務(wù)實體）乃秀、Link（關(guān)系）肛著、Satellite（實體屬性） 三部分組成 圆兵。
四、Anchor模型
Anchor模型是由Lars. R?nnb?ck設(shè)計的枢贿，初衷是設(shè)計一個高度可擴展的模型殉农，核心思想：所有的擴展只是添加而不是修改，因此它將模型規(guī)范到6NF局荚，基本變成了K-V結(jié)構(gòu)模型超凳。
Anchor模型由：Anchors 、Attributes 耀态、Ties 轮傍、Knots 組成，相關(guān)細節(jié)可以參考《AnchorModeling-Agile Information Modeling in Evolving Data Environments》
0x02 維度建模
一茫陆、什么是維度建模
維度模型是數(shù)據(jù)倉庫領(lǐng)域大師Ralph Kimall所倡導金麸，他的《數(shù)據(jù)倉庫工具箱》，是數(shù)據(jù)倉庫工程領(lǐng)域最流行的數(shù)倉建模經(jīng)典簿盅。維度建模以分析決策的需求出發(fā)構(gòu)建模型挥下，構(gòu)建的數(shù)據(jù)模型為分析需求服務(wù)，因此它重點解決用戶如何更快速完成分析需求桨醋，同時還有較好的大規(guī)模復雜查詢的響應性能棚瘟。
我們換一種方式來解釋什么是維度建模。學過數(shù)據(jù)庫的童鞋應該都知道星型模型喜最，星型模型就是我們一種典型的維度模型偎蘸。我們在進行維度建模的時候會建一張事實表，這個事實表就是星型模型的中心瞬内，然后會有一堆維度表迷雪，這些維度表就是向外發(fā)散的星星。那么什么是事實表虫蝶、什么又是維度表嗎章咧，下面會專門來解釋。
二能真、維度建模的基本要素
維度建模中有一些比較重要的概念赁严，理解了這些概念，基本也就理解了什么是維度建模粉铐。
1. 事實表
發(fā)生在現(xiàn)實世界中的操作型事件疼约，其所產(chǎn)生的可度量數(shù)值，存儲在事實表中蝙泼。從最低的粒度級別來看程剥，事實表行對應一個度量事件，反之亦然汤踏。

額织鲸，看了這一句哨免，其實是不太容易理解到底什么是事實表的。
比如一次購買行為我們就可以理解為是一個事實昙沦，下面我們上示例。

p1.png

圖中的訂單表就是一個事實表载荔，你可以理解他就是在現(xiàn)實中發(fā)生的一次操作型事件盾饮，我們每完成一個訂單，就會在訂單中增加一條記錄懒熙。
我們可以回過頭再看一下事實表的特征丘损，在維度表里沒有存放實際的內(nèi)容，他是一堆主鍵的集合工扎，這些ID分別能對應到維度表中的一條記錄徘钥。
2. 維度表
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關(guān)聯(lián)的任何事實表的外鍵肢娘，當然呈础，維度表行的描述環(huán)境應與事實表行完全對應。 維度表通常比較寬橱健，是扁平型非規(guī)范表而钞，包含大量的低粒度的文本屬性。

我們的圖中的用戶表拘荡、商家表臼节、時間表這些都屬于維度表，這些表都有一個唯一的主鍵珊皿，然后在表中存放了詳細的數(shù)據(jù)信息网缝。
0x03 實踐
下面我們將以電商為例，詳細講一下維度建模的建模方式蟋定，并舉例如果使用這個模型（這點還是很重要的）粉臊。
一、業(yè)務(wù)場景
假設(shè)我們在一家電商網(wǎng)站工作溢吻，比如某寶维费、某東。我們需要對這里業(yè)務(wù)進行建模促王。下面我們分析幾點業(yè)務(wù)場景：
電商網(wǎng)站中最典型的場景就是用戶的購買行為犀盟。
一次購買行為的發(fā)起需要有這幾個個體的參與：購買者、商家蝇狼、商品阅畴、購買時間、訂單金額迅耘。
一個用戶可以發(fā)起很多次購買的動作贱枣。

好监署，基于這幾點，我們來設(shè)計我們的模型纽哥。
二钠乏、模型設(shè)計
下面就是我們設(shè)計出來的數(shù)據(jù)模型，和之前的基本一樣春塌，只不過是換成了英文晓避，主要是為了后面寫sql的時候來用。

![Uploading p3_414705.png . . .]

我就不再解釋每個表的作用了只壳，現(xiàn)在只說一下為什么要這樣設(shè)計俏拱。
首先，我們想一下吼句，如果我們不這樣設(shè)計的話锅必，我們一般會怎么做？
如果是我惕艳，我會設(shè)計下面這張表搞隐。你信不信，我能列出來50個字段远搪！其實我個人認為怎么設(shè)計這種表都有其合理性尔许，我們不論對錯，單說一下兩者的優(yōu)缺點终娃。

p3.png

先說我們的維度模型：
數(shù)據(jù)冗余形独取（因為很多具體的信息都存在相應的維度表中了，比如用戶信息就只有一份）
結(jié)構(gòu)清晰（表結(jié)構(gòu)一目了然）
便于做OLAP分析（數(shù)據(jù)分析用起來會很開心）
增加使用成本棠耕，比如查詢時要關(guān)聯(lián)多張表
數(shù)據(jù)不一致余佛，比如用戶發(fā)起購買行為的時候的數(shù)據(jù)，和我們維度表里面存放的數(shù)據(jù)不一致

再說我們這張大款表的優(yōu)缺點：
業(yè)務(wù)直觀窍荧，在做業(yè)務(wù)的時候辉巡，這種表特別方便，直接能對到業(yè)務(wù)中蕊退。
使用方便郊楣，寫sql的時候很方便。
數(shù)據(jù)冗余巨大瓤荔，真的很大净蚤，在幾億的用戶規(guī)模下，他的訂單行為會很恐怖
粒度僵硬输硝，什么都寫死了今瀑，這張表的可復用性太低。

三、使用示例
數(shù)據(jù)模型的建立必須要為更好的應用來服務(wù)橘荠，下面我先舉一個例子屿附，來切實地感受一下來怎么用我們的模型。
需求：求出2016年在帝都的男性用戶購買的LV品牌商品的總價格哥童。
實現(xiàn)：
SELECT SUM(order.money) FROM order, product, date, address, user, WHERE date.year = '2016' AND user.sex = 'male' AND address.province = '帝都' AND product.name = 'LV'

0xFF 總結(jié)
維度建模是一種十分優(yōu)秀的建模方式挺份，他有很多的優(yōu)點，但是我們在實際工作中也很難完全按照它的方式來實現(xiàn)贮懈，都會有所取舍压恒，比如說為了業(yè)務(wù)我們還是會需要一些寬表，有時候還會有很多的數(shù)據(jù)冗余错邦。