寫在前面： 博主是一名軟件工程系大數據應用開發專業大二的學生，暱稱來源於《愛麗絲夢遊仙境》中的Alice和自己的暱稱。作爲一名互聯網小白，
寫博客一方面是爲了記錄自己的學習歷程，一方面是希望能夠幫助到很多和自己一樣處於起步階段的萌新。由於水平有限，博客中難免會有一些錯誤，有紕漏之處懇請各位大佬不吝賜教！個人小站:http://alices.ibilibili.xyz/ , 博客主頁:https://alice.blog.csdn.net/
儘管當前水平可能不及各位大佬，但我還是希望自己能夠做得更好，因爲一天的生活就是一生的縮影。我希望在最美的年華，做最好的自己！
本篇博客，博主爲大家帶來關於數倉項目中緯度模型設計與分層架構的一個說明。
文章目錄
數據倉庫緯度模型設計
1. 緯度建模基本概念
維度模型是數據倉庫領域大師Ralph Kimall所倡導，他的《數據倉庫工具箱》，是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。
維度建模是專門應用於分析型數據庫、數據倉庫、數據集市建模的方法。數據集市可以理解爲是一種"小型數據倉庫"。
1.1 事實表
發生在現實世界中的操作型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實錶行對應一個度量事件，反之亦然。
事實表表示對分析主題的度量。比如一次購買行爲我們就可以理解爲是一個事實。
圖中的訂單表就是一個事實表，可以理解他就是在現實中發生的一次操作型事件，每完成一個訂單，就會在訂單中增加一條記錄。
事實表的特徵：表裏沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。事實表包含了與各維度表相關聯的外鍵，可與維度表關聯。事實表的度量通常是數值類型（條/個/次），且記錄數會不斷增加，表數據規模迅速增長。
1.2 維度表
維度表示要對數據進行分析時所用的一個量，比如你要分析產品銷售情況，你可以選擇按類別進行分析,或按區域分析。這樣的按…分析就構成一個維度。上圖中的用戶表、商家表、時間表這些都屬於維度表。這些表都有一個唯一的主鍵，然後在表中存放了詳細的數據信息。
例如：交易金額分析分析
男性用戶的訂單金額、聯想商品的訂單金額、第一季度的訂單金額、手機的訂單金額、家裏下單的訂單金額
例如：學生分析
姓張的同學有多少、男性的同學有多少、江蘇的同學有多少、身高小於170cm的同學有多少、年齡小於23歲的同學有多少。
維度表的特徵：每個維度表都包含單一的主鍵列。維度表的主鍵可以作爲與之關聯的任何事實表的外鍵，當然，維度錶行的描述環境應與事實錶行完全對應。維度表通常比較寬，是扁平型非規範表，包含大量的低粒度的文本屬性。
總的說來，在數據倉庫中不需要嚴格遵守規範化設計原則。因爲數據倉庫的主導功能就是面向分析，以查詢爲主，不涉及數據更新操作。
需要強調的是:
事實表的設計是以能夠正確記錄歷史信息爲準則。
維度表的設計是以能夠以合適的角度來聚合主題內容爲準則。
2. 維度建模三種模式
2.1 星形模型
星形模式(Star Schema)是最常用的維度建模方式。星型模式是以事實表爲中心，所有的維度表直接連接在事實表上，像星星一樣。
星形模式的維度建模由一個事實表和一組維度表成，且具有以下特點：
a. 維表只和事實表關聯，維表之間沒有關聯；
b. 每個維表主鍵爲單列，且該主鍵放置在事實表中，作爲兩邊連接的外鍵；
c. 以事實表爲核心，維度表圍繞核心呈星形分佈；
2.2 雪花模式
雪花模式(Snowflake Schema)是對星形模式的擴展。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規範一些，但是由於這種模型不太容易理解，維護成本比較高，而且性能方面需要關聯多層維表，性能也比星型模型要低。所以一般不是很常用。
2.3 星座模式
星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，而且共享維度信息。
前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。
數據倉庫分層架構
1. 爲什麼要分層
分層的主要原因是在管理數據的時候，能對數據有一個更加清晰的掌控，詳細來講，主要有下面幾個原因：
清晰數據結構：
每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。
方便數據血緣追蹤：
簡單來說，我們最終給業務呈現的是一個能直接使用業務表，但是它的來源有很多，如果有一張來源表出問題了，我們希望能夠快速準確地定位到問題，並清楚它的危害範圍。
減少重複開發：
規範數據分層，開發一些通用的中間層數據，能夠減少極大的重複計算。
把複雜問題簡單化：
將一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的準確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。
屏蔽原始數據的異常:
屏蔽業務的影響，不必改一次業務就需要重新接入數據。
2.數倉分層思想
數據分層，每個企業根據自己的業務需求可以分成不同的層次，但是最基礎的分層思想，理論上數據分爲三個層，數據運營層、數據倉庫層、數據服務層。基於這個基礎分層之上添加新的層次，來滿足不同的業務需求。
數據運營層（ODS）
Operate data store（操作數據-存儲），是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗淨、傳輸，也就說傳說中的ETL之後，裝入ODS層。本層的數據，總體上大多是按照源頭業務系統的分類方式而分類的。
例如：MySQL裏面的一張表可以通過sqoop之間抽取到ODS層。
ODS層數據的來源方式：
- 業務庫
經常會使用sqoop來抽取，比如我們每天定時抽取一次。在實時方面，可以考慮用canal監聽mysql的binlog，實時接入即可。
- 埋點日誌
線上系統會打入各種日誌，這些日誌一般以文件的形式保存，我們可以選擇用flume定時抽取，也可以用用spark streaming或者Flink來實時接入，當然，kafka也會是一個關鍵的角色。
- 消息隊列
來自ActiveMQ、Kafka的數據等。
數據倉庫層（DW）
Data warehouse（數據倉庫）。在這裏，從ODS層中獲得的數據按照主題建立各種數據模型。例如以研究人的旅遊消費爲主題的數據集中，便可以結合航空公司的登機出行信息，以及銀聯繫統的刷卡記錄，進行結合分析，產生數據集。在這裏，我們需要了解四個概念：維（dimension）、事實（Fact）、指標（Index）和粒度（ Granularity）。
DW數據分層，由下到上爲 DWD,DWB,DWS
DWD：data warehouse detail 細節數據層，是業務層與數據倉庫的隔離層。
DWB：data warehouse base 基礎數據層，存儲的是客觀數據，一般用作中間層，可以認爲是大量指標的數據層。
DWS：data warehouse service 服務數據層，基於DWB上的基礎數據，整合彙總成分析某一個主題域的服務數據，一般是寬表。
數據服務層/應用層（ADS）：
Application Data Service(應用數據服務)。該層主要是提供數據產品和數據分析使用的數據，一般會存放在ES、MySQL等系統中供線上系統使用。
例如：我們經常說的報表數據，或者說那種大寬表，一般就放在這裏。
下面爲大家介紹一下阿里巴巴的數據倉庫分層架構：
3. 阿里巴巴數據倉庫分層架構
1. ODS 數據準備層
功能
ODS層是數據倉庫準備區，爲DWD層提供基礎原始數據，可減少對業務系統的影響
建模方式及原則：
從業務系統增量抽取、保留時間由業務需求決定、可分表進行週期存儲、數據不做清洗轉換與業務系統數據模型保持一致、按主題邏輯劃分。
2、DWD 數據明細層
功能：
爲DW層提供來源明細數據，提供業務系統細節數據的長期沉澱，爲未來分析類需求的擴展提供歷史數據支撐 。
建模方式及原則：
數據模型與ODS層一致，不做清洗轉換處理，爲支持數據重跑可額外增加數據業務日期字段、可按年月日進行分表、用增量ODS層數據和前一天DWD相關表進行merge處理。
3、DW(B/S) 數據彙總層
功能：
爲DW、ST層提供細粒度數據，細化成DWB和DWS；
DWB是根據DWD明細數據進行轉換，如維度轉代理鍵、身份證清洗、會員註冊來源清晰、字段合併、空值處理、髒數據處理、IP清晰轉換、賬號餘額清洗、資金來源清洗等；
DWS是根據DWB層數據按各個維度ID進行高粒度彙總聚合，如按交易來源，交易類型進行匯合。
建模方式及原則：
聚合、彙總增加派生事實；
關聯其它主題的事實表，DW層可能會跨主題域；
DWB保持低粒度彙總加工數據，DWS保持高粒度彙總數據；
數據模型可能採用反範式設計，合併信息等。
4、 DataMarket(數據集市)層
功能:
可以是一些寬表，是根據DW層數據按照各種維度或多種維度組合把需要查詢的一些事實字段進行彙總統計並作爲單獨的列進行存儲；
滿足一些特定查詢、數據挖掘應用；
應用集市數據存儲
建模方式及原則：
儘量減少數據訪問時計算(優化檢索)
維度建模，星型模型
事實拉寬，度量預先計算
分表存儲
5、ST 數據應用層（ADS層）
功能：
ST層面向用戶應用和分析需求，包括前端報表、分析圖表、KPI、儀表盤、OLAP、專題等分析，面向最終結果用戶；
適合作OLAP、報表模型，如ROLAP , MOLAP；
聯機事務處理OLTP、聯機分析處理OLAP。
OLTP是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。
OLAP聯機分析處理的用戶是企業中的專業分析人員及管理決策人員，他們在分析業務經營的數據時，從不同的角度來審視業務的衡量指標是一種很自然的思考模式。例如分析銷售數據，可能會綜合時間週期、產品類別、分銷渠道、地理分佈、客戶羣類等多種因素來考量。
根據DW層經過聚合彙總統計後的粗粒度事實表
建模方式及原則：
保持數據量小；
維度建模，星形模型；
各位維度代理鍵+度量；
增加數據業務日期字段，支持數據重跑；
不分表存儲
本次關於數倉【維度模型設計】與【分層架構】的內容就到這裏！
如果以上過程中出現了任何的紕漏錯誤，煩請大佬們指正😅
受益的朋友或對大數據技術感興趣的夥伴記得點贊關注支持一波🙏
