深刻剖析數據倉庫
數據倉庫概念:前端
英文名稱爲Data Warehouse，可簡寫爲DW或DWH。數據倉庫的目的是構建面向分析的集成化數據環境，爲企業提供決策支持（Decision Support）。它出於分析性報告和決策支持目的而建立。sql
數據倉庫自己並不「生產」任何數據，同時自身也不須要「消費」任何的數據，數據來源於外部，而且開放給外部應用，這也是爲何叫「倉庫」，而不叫「工廠」的緣由。數據庫
基本特徵:安全
數據倉庫是面向主題的、集成的、非易失的和時變的數據集合，用以支持管理決策。數據結構
注：文章首發於公衆號：五分鐘學大數據架構
-
面向主題:併發
傳統數據庫中，最大的特色是面向應用進行數據的組織，各個業務系統多是相互分離的。而數據倉庫則是面向主題的。主題是一個抽象的概念，是較高層次上企業信息系統中的數據綜合、歸類並進行分析利用的抽象。在邏輯意義上，它是對應企業中某一宏觀分析領域所涉及的分析對象。數據庫設計
-
集成性:工具
經過對分散、獨立、異構的數據庫數據進行抽取、清理、轉換和彙總便獲得了數據倉庫的數據，這樣保證了數據倉庫內的數據關於整個企業的一致性。性能
數據倉庫中的綜合數據不能從原有的數據庫系統直接獲得。所以在數據進入數據倉庫以前，必然要通過統一與綜合，這一步是數據倉庫建設中最關鍵、最複雜的一步，所要完成的工做有：
-
要統一源數據中全部矛盾之處，如字段的同名異義、異名同義、單位不統1、字長不一致，等等。
-
進行數據綜合和計算。數據倉庫中的數據綜合工做能夠在從原有數據庫抽取數據時生成，但許可能是在數據倉庫內部生成的，即進入數據倉庫之後進行綜合生成的。
下圖說明一個保險公司綜合數據的簡單處理過程，其中數據倉庫中與「保險」 主題有關的數據來自於多個不一樣的操做型系統。這些系統內部數據的命名可能不一樣，數據格式也可能不一樣。把不一樣來源的數據存儲到數據倉庫以前，須要去除這些不一致。
數倉主題
-
非易失性（不可更新性）
數據倉庫的數據反映的是一段至關長的時間內歷史數據的內容，是不一樣時點的數據庫快照的集合，以及基於這些快照進行統計、綜合和重組的導出數據。
數據非易失性主要是針對應用而言。數據倉庫的用戶對數據的操做大可能是數據查詢或比較複雜的挖掘，一旦數據進入數據倉庫之後，通常狀況下被較長時間保留。數據倉庫中通常有大量的查詢操做，但修改和刪除操做不多。所以，數據經加工和集成進入數據倉庫後是極少更新的，一般只須要按期的加載和更新。
-
時變性
數據倉庫包含各類粒度的歷史數據。數據倉庫中的數據可能與某個特定日期、星期、月份、季度或者年份有關。數據倉庫的目的是經過分析企業過去一段時間業務的經營情況，挖掘其中隱藏的模式。雖然數據倉庫的用戶不能修改數據，但並非說數據倉庫的數據是永遠不變的。分析的結果只能反映過去的狀況，當業務變化後，挖掘出的模式會失去時效性。所以數據倉庫的數據須要更新，以適應決策的須要。從這個角度講，數據倉庫建設是一個項目，更是一個過程。數據倉庫的數據隨時間的變化表如今如下幾個方面：
（1） 數據倉庫的數據時限通常要遠遠長於操做型數據的數據時限。
（2） 操做型系統存儲的是當前數據，而數據倉庫中的數據是歷史數據。
（3） 數據倉庫中的數據是按照時間順序追加的，它們都帶有時間屬性。
1. 數據倉庫與數據庫的區別
數據庫與數據倉庫的區別實際講的是 OLTP 與 OLAP 的區別。
操做型處理，叫聯機事務處理 OLTP（On-Line Transaction Processing，），也能夠稱面向交易的處理系統，它是針對具體業務在數據庫聯機的平常操做，一般對少數記錄進行查詢、修改。用戶較爲關心操做的響應時間、數據的安全性、完整性和併發支持的用戶數等問題。傳統的數據庫系統做爲數據管理的主要手段，主要用於操做型處理，像Mysql，Oracle等關係型數據庫通常屬於OLTP。
分析型處理，叫聯機分析處理 OLAP（On-Line Analytical Processing）通常針對某些主題的歷史數據進行分析，支持管理決策。
首先要明白，數據倉庫的出現，並非要取代數據庫。數據庫是面向事務的設計，數據倉庫是面向主題設計的。數據庫通常存儲業務數據，數據倉庫存儲的通常是歷史數據。
數據庫設計是儘可能避免冗餘，通常針對某一業務應用進行設計，好比一張簡單的User表，記錄用戶名、密碼等簡單數據便可，符合業務應用，可是不符合分析。數據倉庫在設計是有意引入冗餘，依照分析需求，分析維度、分析指標進行設計。
數據庫是爲捕獲數據而設計，數據倉庫是爲分析數據而設計。
以銀行業務爲例。數據庫是事務系統的數據平臺，客戶在銀行作的每筆交易都會寫入數據庫，被記錄下來，這裏，能夠簡單地理解爲用數據庫記帳。數據倉庫是分析系統的數據平臺，它從事務系統獲取數據，並作彙總、加工，爲決策者提供決策的依據。好比，某銀行某分行一個月發生多少交易，該分行當前存款餘額是多少。若是存款又多，消費交易又多，那麼該地區就有必要設立ATM了。
顯然，銀行的交易量是巨大的，一般以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢須要幾十秒是沒法忍受的，這就要求數據庫只能存儲很短一段時間的數據。而分析系統是過後的，它要提供關注時間段內全部的有效數據。這些數據是海量的，彙總計算起來也要慢一些，可是，只要可以提供有效的分析數據就達到目的了。
數據倉庫，是在數據庫已經大量存在的狀況下，爲了進一步挖掘數據資源、爲了決策須要而產生的，它決不是所謂的「大型數據庫」。
2. 數據倉庫分層架構
按照數據流入流出的過程，數據倉庫架構可分爲：源數據、數據倉庫、數據應用
數據倉庫
數據倉庫的數據來源於不一樣的源數據，並提供多樣的數據應用，數據自下而上流入數據倉庫後向上層開放應用，而數據倉庫只是中間集成化數據管理的一個平臺。
源數據：此層數據無任何更改，直接沿用外圍系統數據結構和數據，不對外開放；爲臨時存儲層，是接口數據的臨時存儲區域，爲後一步的數據處理作準備。
數據倉庫：也稱爲細節層，DW層的數據應該是一致的、準確的、乾淨的數據，即對源系統數據進行了清洗（去除了雜質）後的數據。
數據應用：前端應用直接讀取的數據源；根據報表、專題分析需求而計算生成的數據。
數據倉庫從各數據源獲取數據及在數據倉庫內的數據轉換和流動均可以認爲是ETL（抽取Extra, 轉化Transfer, 裝載Load）的過程，ETL是數據倉庫的流水線，也能夠認爲是數據倉庫的血液，它維繫着數據倉庫中數據的新陳代謝，而數據倉庫平常的管理和維護工做的大部分精力就是保持ETL的正常和穩定。
那麼爲何要數據倉庫進行分層呢?
-
用空間換時間，經過大量的預處理來提高應用系統的用戶體驗（效率），所以數據倉庫會存在大量冗餘的數據；不分層的話，若是源業務系統的業務規則發生變化將會影響整個數據清洗過程，工做量巨大。
-
經過數據分層管理能夠簡化數據清洗的過程，由於把原來一步的工做分到了多個步驟去完成，至關於把一個複雜的工做拆成了多個簡單的工做，把一個大的黑盒變成了一個白盒，每一層的處理邏輯都相對簡單和容易理解，這樣咱們比較容易保證每個步驟的正確性，當數據發生錯誤的時候，每每咱們只須要局部調整某個步驟便可。
3. 數據倉庫元數據的管理
元數據（Meta Date），主要記錄數據倉庫中模型的定義、各層級間的映射關係、監控數據倉庫的數據狀態及ETL的任務運行狀態。通常會經過元數據資料庫（Metadata Repository）來統一地存儲和管理元數據，其主要目的是使數據倉庫的設計、部署、操做和管理能達成協同和一致。
元數據是數據倉庫管理系統的重要組成部分，元數據管理是企業級數據倉庫中的關鍵組件，貫穿數據倉庫構建的整個過程，直接影響着數據倉庫的構建、使用和維護。
-
構建數據倉庫的主要步驟之一是ETL。這時元數據將發揮重要的做用，它定義了源數據系統到數據倉庫的映射、數據轉換的規則、數據倉庫的邏輯結構、數據更新的規則、數據導入歷史記錄以及裝載週期等相關內容。數據抽取和轉換的專家以及數據倉庫管理員正是經過元數據高效地構建數據倉庫。
-
用戶在使用數據倉庫時，經過元數據訪問數據，明確數據項的含義以及定製報表。
-
數據倉庫的規模及其複雜性離不開正確的元數據管理，包括增長或移除外部數據源，改變數據清洗方法，控制出錯的查詢以及安排備份等。
元數據可分爲技術元數據和業務元數據。技術元數據爲開發和管理數據倉庫的IT 人員使用，它描述了與數據倉庫開發、管理和維護相關的數據，包括數據源信息、數據轉換描述、數據倉庫模型、數據清洗與更新規則、數據映射和訪問權限等。而業務元數據爲管理層和業務分析人員服務，從業務角度描述數據，包括商務術語、數據倉庫中有什麼數據、數據的位置和數據的可用性等，幫助業務人員更好地理解數據倉庫中哪些數據是可用的以及如何使用。
由上可見，元數據不只定義了數據倉庫中數據的模式、來源、抽取和轉換規則等，並且是整個數據倉庫系統運行的基礎，元數據把數據倉庫系統中各個鬆散的組件聯繫起來，組成了一個有機的總體。
數倉建模方法
數據倉庫的建模方法有不少種，每一種建模方法表明了哲學上的一個觀點，表明了一種概括、歸納世界的一種方法。常見的有 範式建模法、維度建模法、實體建模法等，每種方法從本質上將是從不一樣的角度看待業務中的問題。
1. 範式建模法（Third Normal Form，3NF）
範式建模法實際上是咱們在構建數據模型經常使用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關係型數據庫的數據存儲，利用的一種技術層面上的方法。目前，咱們在關係型數據庫中的建模方法，大部分採用的是三範式建模法。
範式 是符合某一種級別的關係模式的集合。構造數據庫必須遵循必定的規則，而在關係型數據庫中這種規則就是範式，這一過程也被稱爲規範化。目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、Boyce-Codd範式（BCNF）、第四範式（4NF）和第五範式（5NF）。
在數據倉庫的模型設計中，通常採用第三範式。一個符合第三範式的關係必須具備如下三個條件 :
-
每一個屬性值惟一，不具備多義性 ;
-
每一個非主屬性必須徹底依賴於整個主鍵，而非主鍵的一部分 ;
-
每一個非主屬性不能依賴於其餘關係中的屬性，由於這樣的話，這種屬性應該歸到其餘關係中去。
範式建模
根據 Inmon 的觀點，數據倉庫模型的建設方法和業務系統的企業數據模型相似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分爲兩個層次，即主題域模型和邏輯模型。一樣，主題域模型能夠當作是業務模型的概念模型，而邏輯模型則是域模型在關係型數據庫上的實例化。
2. 維度建模法（Dimensional Modeling）
維度模型是數據倉庫領域另外一位大師Ralph Kimall所倡導，他的《數據倉庫工具箱》是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，所以它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。
維度建模
典型的表明是咱們比較熟知的星形模型（Star-schema），以及在一些特殊場景下適用的雪花模型（Snow-schema）。
維度建模中比較重要的概念就是 事實表（Fact table）和維度表（Dimension table）。其最簡單的描述就是，按照事實表、維度表來構建數據倉庫、數據集市。
目前在互聯網公司最經常使用的建模方法就是維度建模，稍後將重點講解
3. 實體建模法（Entity Modeling）
實體建模法並非數據倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是能夠細分的，客觀世界應該能夠分紅由一個個實體，以及實體與實體之間的關係組成。那麼咱們在數據倉庫的建模過程當中徹底能夠引入這個抽象的方法，將整個業務也能夠劃分紅一個個的實體，而每一個實體之間的關係，以及針對這些關係的說明就是咱們數據建模須要作的工做。
雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即咱們能夠將任何一個業務過程劃分紅 3 個部分，實體，事件，說明，以下圖所示：
實體建模
上圖表述的是一個抽象的含義，若是咱們描述一個簡單的事實：「小明開車去學校上學」。以這個業務事實爲例，咱們能夠把「小明」，「學校」當作是一個實體，「上學」描述的是一個業務過程，咱們在這裏能夠抽象爲一個具體「事件」，而「開車去」則能夠當作是事件「上學」的一個說明。
維度建模
維度建模是專門應用於分析型數據庫、數據倉庫、數據集市建模的方法。數據集市能夠理解爲是一種"小型數據倉庫"。
1. 維度建模中表的類型
1. 事實表
發生在現實世界中的操做型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實錶行對應一個度量事件，反之亦然。
事實表表示對分析主題的度量。好比一次購買行爲咱們就能夠理解爲是一個事實。
事實與維度
圖中的訂單表就是一個事實表，你能夠理解他就是在現實中發生的一次操做型事件，咱們每完成一個訂單，就會在訂單中增長一條記錄。 事實表的特徵：表裏沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外鍵，可與維度表關聯。事實表的度量一般是數值類型，且記錄數會不斷增長，表數據規模迅速增加。
明細表（寬表）：
事實表的數據中，有些屬性共同組成了一個字段（糅合在一塊兒），好比年月日時分秒構成了時間,當須要根據某一屬性進行分組統計的時候，須要截取拼接之類的操做，效率極低。 如：
| local_time |
|---|
| 2021-03-18 06:31:42 |
爲了分析方便，能夠事實表中的一個字段切割提取多個屬性出來構成新的字段，由於字段變多了，因此稱爲寬表，原來的成爲窄表。
將上述的local_time字段擴展爲以下6個字段：
| year | month | day | hour | m | s |
|---|---|---|---|---|---|
| 2021 | 03 | 18 | 06 | 31 | 42 |
又由於寬表的信息更加清晰明細，因此也能夠稱之爲明細表。
2．維度表
每一個維度表都包含單一的主鍵列。維度表的主鍵能夠做爲與之關聯的任何事實表的外鍵，固然，維度錶行的描述環境應與事實錶行徹底對應。維度表一般比較寬，是扁平型非規範表，包含大量的低粒度的文本屬性。
維度表示你要對數據進行分析時所用的一個量，好比你要分析產品銷售狀況， 你能夠選擇按類別來進行分析，或按區域來分析。每一個類別就構成一個維度。上圖中的用戶表、商家表、時間表這些都屬於維度表，這些表都有一個惟一的主鍵，而後在表中存放了詳細的數據信息。
總的說來，在數據倉庫中不須要嚴格遵照規範化設計原則。由於數據倉庫的主導功能就是面向分析，以查詢爲主，不涉及數據更新操做。事實表的設計是以可以正確記錄歷史信息爲準則，維度表的設計是以可以以合適的角度來聚合主題內容爲準則。
2. 維度建模三種模式
1. 星型模式
星形模式(Star Schema)是最經常使用的維度建模方式。星型模式是以事實表爲中心，全部的維度表直接鏈接在事實表上，像星星同樣。 星形模式的維度建模由一個事實表和一組維表成，且具備如下特色： a. 維表只和事實表關聯，維表之間沒有關聯； b. 每一個維表主鍵爲單列，且該主鍵放置在事實表中，做爲兩邊鏈接的外鍵； c. 以事實表爲核心，維表圍繞核心呈星形分佈；
2. 雪花模式
雪花模式(Snowflake Schema)是對星形模式的擴展。雪花模式的維度表能夠擁有其餘維度表的，雖然這種模型相比星型更規範一些，可是因爲這種模型不太容易理解，維護成本比較高，並且性能方面須要關聯多層維表，性能也比星型模型要低。因此通常不是很經常使用
雪花模式
3．星座模式
星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，並且共享維度信息。 前面介紹的兩種維度建模方法都是多維表對應單事實表，但在不少時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。
星座模型
3. 維度建模過程
咱們知道維度建模的表類型有事實表，維度表；模式有星形模型，雪花模型，星座模型這些概念了，可是實際業務中，給了咱們一堆數據，咱們怎麼拿這些數據進行數倉建設呢，數倉工具箱做者根據自身60多年的實際業務經驗，給咱們總結了以下四步，請務必記住！
數倉工具箱中的維度建模四步走：
維度建模四步走
請牢記以上四步，無論什麼業務，就按照這個步驟來，順序不要搞亂，由於這四步是環環相扣，步步相連。下面詳細拆解下每一個步驟怎麼作
一、選擇業務過程
維度建模是緊貼業務的，因此必須以業務爲根基進行建模，那麼選擇業務過程，顧名思義就是在整個業務流程中選取咱們須要建模的業務，根據運營提供的需求及往後的易擴展性等進行選擇業務。好比商城，整個商城流程分爲商家端，用戶端，平臺端，運營需求是總訂單量，訂單人數，及用戶的購買狀況等，咱們選擇業務過程就選擇用戶端的數據，商家及平臺端暫不考慮。業務選擇很是重要，由於後面全部的步驟都是基於此業務數據展開的。
二、聲明粒度
先舉個例子：對於用戶來講，一個用戶有一個身份證號，一個戶籍地址，多個手機號，多張銀行卡，那麼與用戶粒度相同的粒度屬性有身份證粒度，戶籍地址粒度，比用戶粒度更細的粒度有手機號粒度，銀行卡粒度，存在一對一的關係就是相同粒度。爲何要提相同粒度呢，由於維度建模中要求咱們，在同一事實表中，必須具備相同的粒度，同一事實表中不要混用多種不一樣的粒度，不一樣的粒度數據創建不一樣的事實表。而且從給定的業務過程獲取數據時，強烈建議從關注原子粒度開始設計，也就是從最細粒度開始，由於原子粒度可以承受沒法預期的用戶查詢。可是上卷彙總粒度對查詢性能的提高很重要的，因此對於有明確需求的數據，咱們創建針對需求的上卷彙總粒度，對需求不明朗的數據咱們創建原子粒度。
三、確認維度
維度表是做爲業務分析的入口和描述性標識，因此也被稱爲數據倉庫的「靈魂」。在一堆的數據中怎麼確認哪些是維度屬性呢，若是該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性每每是維度屬性，數倉工具箱中告訴咱們緊緊掌握事實表的粒度，就能將全部可能存在的維度區分開，而且要確保維度表中不能出現重複數據，應使維度主鍵惟一
四、確認事實
事實表是用來度量的，基本上都以數量值表示，事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱爲粒度。維度建模的核心原則之一是同一事實表中的全部度量必須具備相同的粒度。這樣能確保不會出現重複計算度量的問題。有時候每每不能肯定該列數據是事實屬性仍是維度屬性。記住最實用的事實就是數值類型和可加類事實。因此能夠經過分析該列是不是一種包含多個值並做爲計算的參與者的度量，這種狀況下該列每每是事實。
實際業務中數倉分層
數倉分層要結合公司業務進行，而且須要清晰明確各層職責，要保證數據層的穩定又要屏蔽對下游影響，通常採用以下分層結構：
數據分層架構
數據層具體實現
使用四張圖說明每層的具體實現
-
數據源層ODS
數據源層
數據源層主要將各個業務數據導入到大數據平臺，做爲業務數據的快照存儲。
-
數據明細層DW
數據明細層
事實表中的每行對應一個度量，每行中的數據是一個特定級別的細節數據，稱爲粒度。維度建模的核心原則之一是同一事實表中的全部度量必須具備相同的粒度。這樣能確保不會出現重複計算度量的問題。
維度表通常都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重複數據，不然和事實表關聯會出現數據發散問題。
有時候每每不能肯定該列數據是事實屬性仍是維度屬性。記住最實用的事實就是數值類型和可加類事實。因此能夠經過分析該列是不是一種包含多個值並做爲計算的參與者的度量，這種狀況下該列每每是事實；若是該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性每每是維度屬性。可是仍是要結合業務進行最終判斷是維度仍是事實。
-
數據輕度彙總層DM
數據輕度彙總層
此層命名爲輕彙總層，就表明這一層已經開始對數據進行彙總，可是不是徹底彙總，只是對相同粒度的數據進行關聯彙總，不一樣粒度可是有關係的數據也可進行彙總，此時須要將粒度經過聚合等操做進行統一。
-
數據應用層APP
數據應用層
數據應用層的表就是提供給用戶使用的，數倉建設到此就接近尾聲了，接下來就根據不一樣的需求進行不一樣的取數，如直接進行報表展現，或提供給數據分析的同事所需的數據，或其餘的業務支撐。
最後
技術是爲業務服務的，業務是爲公司創造價值的，離開業務的技術是無心義的。因此數倉的建設與業務是息息相關的，公司的業務不一樣，數倉的建設也是不一樣的，只有適合的纔是最好的。
本分分享自公衆號【五分鐘學大數據】，各位看官若是感受文章不錯，可關注一波！
推薦閱讀：
更多大數據技術文章可關注公衆號【五分鐘學大數據】