一文帶你認清資料倉庫“維度模型設計”與“分層架構”| 原力計劃

資料倉庫緯度模型設計

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)Operatedata store(操作資料-儲存),是最接近資料來源中資料的一層,資料來源中的資料,經過抽取、洗淨、傳輸,也就說傳說中的ETL之後,裝入ODS層。本層的資料,總體上大多是按照源頭業務系統的分類方式而分類的。

例如:MySQL裡面的一張表可以透過sqoop之間抽取到ODS層。

ODS層資料的來源方式:

業務庫

經常會使用sqoop來抽取,比如我們每天定時抽取一次。在實時方面,可以考慮用canal監聽mysql的binlog,實時接入即可。

埋點日誌

線上系統會打入各種日誌,這些日誌一般以檔案的形式儲存,我們可以選擇用flume定時抽取,也可以用用spark streaming或者Flink來實時接入,當然,kafka也會是一個關鍵的角色。

訊息佇列

來自ActiveMQ、Kafka的資料等。

資料倉庫層(DW)

Datawarehouse(資料倉庫)。在這裡,從ODS層中獲得的資料按照主題建立各種資料模型。例如以研究人的旅遊消費為主題的資料集中,便可以結合航空公司的登機出行資訊,以及銀聯絡統的刷卡記錄,進行結合分析,產生資料集。在這裡,我們需要了解四個概念:維(dimension)、事實(Fact)、指標(Index)和粒度( Granularity)。

DW資料分層,由下到上為 DWD,DWB,DWS:

DWD:data warehouse detail細節資料層,是業務層與資料倉庫的隔離層。

DWB:data warehouse base 基礎資料層,儲存的是客觀資料,一般用作中間層,可以認為是大量指標的資料層。

DWS:data warehouseservice 服務資料層,基於DWB上的基礎資料,整合彙總成分析某一個主題域的服務資料,一般是寬表。

資料服務層/應用層(ADS):ApplicationData Service(應用資料服務)。該層主要是提供資料產品和資料分析使用的資料,一般會存放在ES、MySQL等系統中供線上系統使用。

例如:我們經常說的報表資料,或者說那種大寬表,一般就放在這裡。

下面為大家介紹一下阿里巴巴的資料倉庫分層架構:

3. 阿里巴巴資料倉庫分層架構

(1)ODS 資料準備層 功能:ODS層是資料倉庫準備區,為DWD層提供基礎原始資料,可減少對業務系統的影響。建模方式及原則:

從業務系統增量抽取、保留時間由業務需求決定、可分表進行週期儲存、資料不做清洗轉換與業務系統資料模型保持一致、按主題邏輯劃分。

(2)DWD 資料明細層 功能:

為DW層提供來源明細資料,提供業務系統細節資料的長期沉澱,為未來分析類需求的擴充套件提供歷史資料支撐。

建模方式及原則:

資料模型與ODS層一致,不做清洗轉換處理,為支援資料重跑可額外增加資料業務日期欄位、可按年月日進行分表、用增量ODS層資料和前一天DWD相關表進行merge處理。

(3)DW(B/S) 資料彙總層功能:為DW、ST層提供細粒度資料,細化成DWB和DWS;

DWS是根據DWB層資料按各個維度ID進行高粒度彙總聚合,如按交易來源,交易型別進行匯合。

建模方式及原則:

資料模型可能採用反正規化設計,合併資訊等。

(4)DataMarket(資料集市)層功能:

滿足一些特定查詢、資料探勘應用;

應用集市資料儲存

建模方式及原則:

分表儲存

(5)ST 資料應用層(ADS層)功能:

聯機事務處理OLTP、聯機分析處理OLAP。

OLTP是傳統的關係型資料庫的主要應用,主要是基本的、日常的事務處理,例如銀行交易。OLAP是資料倉庫系統的主要應用,支援複雜的分析操作,側重決策支援,並且提供直觀易懂的查詢結果。

OLAP聯機分析處理的使用者是企業中的專業分析人員及管理決策人員,他們在分析業務經營的資料時,從不同的角度來審視業務的衡量指標是一種很自然的思考模式。例如分析銷售資料,可能會綜合時間週期、產品類別、分銷渠道、地理分佈、客戶群類等多種因素來考量。

根據DW層經過聚合彙總統計後的粗粒度事實表

建模方式及原則:

不分表儲存

版權宣告:本文源自 網路, 於,由 楠木軒 整理釋出,共 3549 字。

轉載請註明: 一文帶你認清資料倉庫“維度模型設計”與“分層架構”| 原力計劃 - 楠木軒