數據倉庫的建設方法篇

數據倉庫的原由

數據倉庫存在的初期，甚至沒有數據倉庫的時候，貓眼的平常需求報表和數據接口提供方式如圖一：

數據散落在企業各部門應用的數據存儲中，它們之間有着複雜的業務鏈接關係，從總體上看就如一張巨大的蜘蛛網：結構上錯綜複雜，卻又四通八達。在企業級數據應用上單一業務使用方便，且靈活多變；但涉及到跨業務、多部門聯合應用就會存在：①數據來源多樣化，管理決策數據過於分散；②數據缺少標準，難以整合；③數據口徑不統一，可信度低；④缺少數據管控體系，數據質量根本沒法保證。

從這種原始數據存儲的方式提取數據，長期以往將會遇見

1.數據缺少可信性

2.數據愈來愈分散化

3.數據缺少統一的標準，將失去數據準確性的意義

數據倉庫的定義

數據倉庫之父Bill Inmon在1991年出版的「Building the Data Warehouse」一書中所提出的定義被普遍接受：數據倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策（Decision Making Support）

• 面向主題的：普通的操做型數據庫主要面向事務性處理，而數據倉庫中的全部數據通常按照主題進行劃分。主題是對業務數據的一種抽象，是從較高層次上對信息系統中的數據進行概括和整理。面向主題的數據能夠劃分紅兩部分----根據原系統業務數據的特色進行主題的抽取和肯定每一個主題所包含的數據內容。例如用戶主題、折扣卡主題、賣品主題、活動主題、財務主題等；分析數據倉庫主題的時候，通常方法是先肯定幾個基本的主題，而後再將範圍擴大，最後再逐步求精

• 集成性：面向操做型的數據庫一般是異構的、而且相互獨立，因此沒法對信息進行歸納和反映信息的本質。而數據倉庫中的數據是通過數據的抽取、清洗、切換、加載獲得的，因此爲了保證數據不存在二義性，必須對數據進行編碼統一和必要的彙總，以保證數據倉庫內數據的一致性。數據倉庫在經歷數據集成階段後，使數據倉庫中的數據都遵照統一的編碼規則，而且消除許多冗餘數據。

• 穩定性：數據倉庫中的數據反映的都是一段歷史時期的數據內容，它的主要操做是查詢、分析而不進行通常意義上的更新（數據集成前的操做型數據庫主要完成數據的增長、修改、刪除、查詢），一旦某個數據進入到數據倉庫後，通常狀況下數據會被長期保留，當超過規定的期限纔會被刪除。一般數據倉庫須要作的工做就是加載、查詢和分析，通常不進行任何修改操做，是爲了企業高層人員決策分析之用，（以上方法對於專資數據不太適用，專資數據老是存在部分影院延遲上報的問題）

• 反映歷史變化：數據倉庫不斷從操做型數據庫或其餘數據源獲取變化的數據，從而分析和預測須要的歷史數據，因此通常數據倉庫中數據表的鍵碼（維度）都含有時間鍵，以代表數據的歷史時期信息，而後不斷增長新的數據內容。經過這些歷史信息能夠對企業的發展歷程和趨勢作出分析和預測。數據倉庫的建設須要大量的業務數據做爲積累，並將這些寶貴的歷史信息通過加工、整理，最後提供給決策分析人員，這是數據倉庫建設的根本目的。

數據倉庫建模方法

實體建模法

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

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

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

從上面列舉的例子能夠了解，咱們使用的抽象概括方法其實很簡單，任何業務能夠當作3個部分：

• 實體：指領域建模中特定的概念主題，指發生業務關係的對象；

• 事件：指概念主體之間完成一次業務流程的過程，指特定的業務過程；

• 說明：主要是針對實體和事件的特殊說明。

因爲實體建模法，可以很輕鬆的實現業務建模的劃分。所以，在業務建模階段和領域建模階段，實體建模方法有着普遍的應用。通常在沒有現成的行業建模的狀況下，能夠採用實體建模的方法，和客戶一塊兒清理整個業務的模型，進行領域概念的劃分，抽象出具體的業務概念，結合客戶的使用特色，徹底能夠建立出一個符合本身須要的數據倉庫模型來。

可是，實體建模也有着本身先天的缺陷，因爲實體說明法只是一種抽象客觀事件的方法，所以，註定了該建模方法只能侷限在業務建模和領域概念建模階段。所以，到了邏輯建模階段和物理建模階段，則是範式建模和維度建模發揮長處的階段。

範式建模法

範式建模法實際上是咱們在構建數據模型經常使用的一個方法，該方法的主要由inmon所提倡，主要解決關係型數據庫中數據存儲，利用的一種技術層面上的方法。目前，在關係型數據庫中的建模方法，大部分採用的是三範式建模法。

範式是數據庫邏輯模型設計的基本理論，一個關係模型能夠從第一範式到第三範式進行無損分解，這個過程也能夠稱爲規範化。在數據倉庫的模型設計中目前通常採用第三範式，他有着嚴格的數學定義。從其表達的含義來看，一個符合第三範式的關係必須具備如下三個條件：

• 每一個屬性值惟一，不具備多義性；

• 每一個非主屬性必須徹底依賴於整個主鍵，而非主鍵的一部分；

• 每一個非主屬性不能依賴於其餘關係中的屬性，由於這樣的話，這種屬性應該歸到其餘關係中去。

根據Inmon的觀點，數據倉庫模型的建設方法和業務系統的企業數據模型相似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分爲兩個層次，即主題域模型和邏輯模型。一樣，主題域模型能夠當作業務模型的概念模型，而邏輯模型則是域模型在關係型數據庫上的實例化。

從業務數據模型轉向數據倉庫模型時，一樣也須要有數據倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。這裏，業務模型中的數據模型和數據倉庫的模型稍稍有一些不一樣，主要區別在於：

• 數據倉庫的域模型應該包含企業數據模型的域模型之間的關係，以及各個域模型定義。數據倉庫的域模型的概念應該比業務系統的主題域模型規範更加廣。

• 在數據倉庫的邏輯模型須要從業務系統的數據模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關係等。

範式建模法的最大優勢就是從關係型數據庫的角度出發，結合了業務系統的數據模型，可以比較方便的實現數據倉庫的建模。但其缺點也很明顯，因爲建模方法限定在關係型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮數據倉庫的底層數據向數據集市的數據進行彙總時，須要進行必定的變通才能知足響應的需求。

維度建模

維度建模法，是Kimball 最早提出的概念，將數據抽象爲事實表與維度表兩種，而根據兩者之間的關係將總體的模型劃分爲星型模型與雪花模型兩種。這種建模方法的優點在於，根據各個維度對數據進行了預處理，好比按照時間維度進行預先的統計、分類等等，能夠提升數據分析應用時的效率，是適於分析的一種方法。具體來看看幾個概念：

1.維度表與事實表。維度表，描述的是事物的屬性，反映了觀察事物的角度。事實表，描述的是業務過程的事實數據，是要關注的具體內容，每行數據對應一個或多個度量事件。好比，分析「某地區某商品某季度的銷量」，就是從地區、商品、時間（季度）三個角度來觀察商品的銷量，維度表有地區表、商品表和時間表，事實表爲銷量表。在銷量表中，經過鍵值關聯到三個維度表中，經過度量值來表示對應的銷量，所以事實表一般有兩種字段：鍵值列、度量值列。

2.星型模型與雪花模型。兩種模型表達的是事實表與維度表之間的關係。當全部須要的維度表都直接關聯到事實表時，看上去就是一顆星星，稱之爲星型模型；當有一個或多個維表沒有直接關聯到到事實表上，而是經過其餘維度錶鏈接到事實表上時，看上去就是一顆雪花，稱之爲雪花模型。兩者的區別在於，雪花模型必定程度上下降了信息冗餘度，可是合適的冗餘信息能有效的幫助咱們提升查詢效率。

3.基本的維度建模思路。維度建模的基本思路能夠概括爲這麼幾點：第一，肯定主題，即搞清楚要分析的主題是什麼，好比上述的「某地區某商品某季度的銷量」；第二，肯定分析的維度，準備從哪幾個角度來分析數據；第三，肯定事實表中每行的數據粒度，好比時間粒度細化到季度就能夠了；第四，肯定分析的度量事件，即數據指標是什麼。

舉個例子，業務場景是：一款作連鎖企業招聘工做的產品，好比爲麥當勞的全部連鎖門店招聘員工，如今要分析「每家門店的招聘狀況如何？」。結合具體業務，咱們引入六個維度：時間維度、地區維度、品牌維度、門店維度、職位維度、申請渠道；數據指標上，主要有申請工做人數、申請工做次數、聘用人數、拒絕人數，每一個指標分別有增量值和總量值兩種；數據粒度上，時間維度細分到以小時爲單位，地區維度細分到市一級。下圖所示即是相應的星型模型，有三點值得一提：

能夠看到咱們只創建了四張維度表，地區維度和渠道維度是直接以字符串的形式放到事實表中的。這是維度設計中常常遇到的一個問題：若是這個維度只有一個屬性，那麼是做爲單獨的一張表仍是做爲事實表的一部分？其實並無徹底對與錯的答案，只有是否適合本身的答案。這裏，城市與渠道的信息並不會發生變化，因此放入事實表中能夠避免聯合查詢。

創建了統一的時間維度，能夠支持各類時間統計方案，避免在查詢時進行時間值運算。

在品牌維度、門店維度、職位維度三張表中，都有prod_xxxx_id的字段，其值是產品業務數據庫中相應數據的id，做用是爲了與業務數據庫中的信息進行同步。當業務數據庫中的相關信息發生變化時，會經過ETL來更新數據倉庫中的信息，所以咱們須要這樣的一個字段來進行惟一標識。

數倉在維度建模層次劃分

通過長時間的探索，在物理建模這個過程當中通常會進行層次劃分，分別是：基礎事實、輕度彙總層、集市寬表層。

1. 基礎事實層（detail）：基礎層的數據粒度比較細，一般與ods層的粒度類似，只是在ods數據的基礎上作了清洗、規範化和爲了方便分析而做的一些整合，有可能須要結合維度表。

2. 輕度彙總層（aggr）：彙總層是根據各集市的數據需求，抽象出比較通用的數據，對明細層按照一些統計偏向（例如：口徑、業務方向）進行彙總獲得。

3. 集市款表層（topic）：集市寬表主要是在輕度彙總層的基礎之上建立，因爲輕度彙總層的數據有所偏向，因此按照這些事實表的粒度和公共維度，經過更高等級的視圖將它們整合起來

4. 維度表：包括直接從業務方同步的維度表、根據事實表整理成的維度表以及直接生成的維度表等。

貓眼的數據倉庫建設的發展史

階段一：

2015年的貓眼初步建設數據倉庫的時候，以快速知足業務需求爲主，爲了儘快達到數據展現效果，多數需求以煙筒式開發爲主，針對每一個需求的特色，獨立開發每一個需求，需求之間沒有關聯，沒有交互，沒有複用，

底層數據表結構調整後，數據測修改的更多。運維成本出奇的高，隨時時間的推移，數據存在不一致性。

階段二：

針對階段一的貓眼數據倉庫的缺點，後期升級貓眼離線數據倉庫，針對一的缺點，咱們發現需求方多來自同一個業務，好比選座，折扣卡，券碼等產品或者運營。

咱們按照業務方的特色，建設以業務爲主題的數據倉庫模型，改變同一業務沒法複用數據，改變同一業務數據一致性的

階段三

面向模型開發，針對不一樣業務，怎麼解決同名同義性，異名異議性，以及如何解決數據孤島的問題，咱們提出用模型解決，前期咱們將從訂單模型，UGC模型，以及支付模型，財務模型出發，統一同源數據，統一公司口徑，統一數據生成出口

三階段對比效果

階段名稱	階段一	階段二	階段三
優勢	快速開發響應	1.代碼部分解耦，開發速度較快。 2.層級明顯，可以複用部分邏輯	1.運維成本低 2.代碼複用性高 3.業務區分明顯
缺點	1.數據不一致，同一份數據存在多種定義 2.耦合性太強，代碼複用性太拆 3.容易出現環形依賴，任務不能保證SLA	1.運維成本高，發生一部分數據修改，整個體系都須要變化。 2.代碼出口表過於臃腫，公司數據所有都在主題層串聯，致使主題數據過去臃腫，部分狀況下影響性能。 3.重複代碼較多	1。開發週期比較一和二慢，適合穩定的系統 2.對規範要求比較嚴格。