數據倉庫分層架構深度講解

前言

          我們在數倉項目的時候往往是需要將它分層的,但是爲什麼分層你真正的瞭解過嗎,那它分層的好處又是什麼呢。好我們今天就針對這個話題進行講解。如果你還不瞭解數倉中的模型可以去看這篇(數倉模型設計詳細講解),編寫不易請給個一鍵三連。0f8f7a06f767ab238cff5a95c66bb201.jpg

一、爲什麼要分層

         分層的主要原因是在管理數據的時候,能對數據有一個更加清晰的掌控,詳細來講,主要有下面幾個原因:

清晰數據結構:

         每一個數據分層都有它的作用域,這樣我們在使用表的時候能更方便地定位和理解。

方便數據血緣追蹤:

          簡單來說,我們最終給業務呈現的是一個能直接使用業務表,但是它的來源有很多,如果有一張來源表出問題了,我們希望能夠快速準確地定位到問題,並清楚它的危害範圍。

減少重複開發:

          規範數據分層,開發一些通用的中間層數據,能夠減少極大的重複計算。

把複雜問題簡單化:

         將一個複雜的任務分解成多個步驟來完成,每一層只處理單一的步驟,比較簡單和容易理解。而且便於維護數據的準確性,當數據出現問題之後,可以不用修復所有的數據,只需要從有問題的步驟開始修復。

屏蔽原始數據的異常:

         屏蔽業務的影響,不必改一次業務就需要重新接入數據

二、數倉分層思想

         數據分層每個企業根據自己的業務需求可以分成不同的層次,但是最基礎的分層思想,理論上數據分爲三個層數據運營層數據倉庫層數據服務層。基於這個基礎分層之上添加新的層次,來滿足不同的業務需求。

數據運營層(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等系統中供線上系統使用,也可能會存在Hive或者Druid中供數據分析和數據挖掘使用。例如:我們經常說的報表數據,或者說那種大寬表,一般就放在這裏。

三、阿里數據倉庫分層架構

6225d07e75b17a74f88b69aa738236b4.jpgODS 數據準備層

功能:         

        ODS層是數據倉庫準備區,爲DWD層提供基礎原始數據,可減少對業務系統的影響

建模方式及原則:     

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

DWD 數據明細層

功能:       

      爲DW層提供來源明細數據,提供業務系統細節數據的長期沉澱,爲未來分析類需求的擴展提供歷史數據支撐

建模方式及原則:       

        數據模型與ODS層一致,不做清洗轉換處理、爲支持數據重跑可額外增加數據業務日期字段、可按年月日進行分表、用增量ODS層數據和前一天DWD相關表進行merge處理

DW(B/S) 數據彙總層

功能:         

       爲DW、ST層提供細粒度數據,細化成DWB和DWS;       

       DWB是根據DWD明細數據進行轉換,如維度轉代理鍵、身份證清洗、會員註冊來源清晰、字段合併、空值處理、髒數據處理、IP清晰轉換、賬號餘額清洗、資金來源清洗等;      

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

建模方式及原則:

         聚合、彙總增加派生事實;

         關聯其它主題的事實表,DW層可能會跨主題域;

         DWB保持低粒度彙總加工數據,DWS保持高粒度彙總數據;

         數據模型可能採用反範式設計,合併信息等。

Data Market (數據集市)層

功能:        

       可以是一些寬表,是根據DW層數據按照各種維度或多種維度組合把需要查詢的一些事實字段進行彙總統計並作爲單獨的列進行存儲;         

        滿足一些特定查詢、數據挖掘應用         

         應用集市數據存儲

建模方式及原則:         

     儘量減少數據訪問時計算(優化檢索)         

     維度建模,星型模型;        

     分表存儲

ST 數據應用層(ADS層)

功能:        

       ST層面向用戶應用和分析需求,包括前端報表、分析圖表、KPI、儀表盤、OLAP、專題等分析,面向最終結果用戶         

     適合做OLAP、報表模型,如ROLAP,MOLAP

聯機事務處理OLTP、聯機分析處理OLAP。
OLTP是傳統的關係型數據庫的主要應用,主要是基本的、日常的事務處理,例如銀行交易。
OLAP是數據倉庫系統的主要應用,支持複雜的分析操作,側重決策支持,並且提供直觀易懂的查詢結果。   
聯機分析處理的用戶是企業中的專業分析人員及管理決策人員,他們在分析業務經營的數據時,從不同的角度來審視業務的衡量指標是一種很自然的思考模式。例如分析銷售數據,可能會綜合時間週期、產品類別、分銷渠道、地理分佈、客戶羣類等多種因素來考量。


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

建模方式及原則:         

保持數據量小;        

維度建模,星形模型;         

  各位維度代理鍵+度量;        

 增加數據業務日期字段,支持數據重跑;       

 不分表存儲

小結

         本篇文章主要講解數倉項目中爲什麼分層,比如我們在完成一個需要的需求的時候也許只需要一個複雜的SQL語句就可以完成。但一個複雜的SQL語句方便後面維護嗎?當出現了問題方便追蹤嗎? 這時候就體現出分層的好處。順便給大家分享阿里的數倉模型是什麼樣的。信自己,努力和汗水總會能得到回報的。我是大數據老哥,我們下期見~~~

獲取Flink面試題,Spark面試題,程序員必備軟件,hive面試題,Hadoop面試題,Docker面試題,簡歷模板等資源請去GitHub自行下載 https://github.com/lhh2002/Framework-Of-BigData

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章