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

前言

          咱們在數倉項目的時候每每是須要將它分層的，可是爲何分層你真正的瞭解過嗎，那它分層的好處又是什麼呢。好咱們今天就針對這個話題進行講解。若是你還不瞭解數倉中的模型能夠去看這篇（數倉模型設計詳細講解）,編寫不易請給個一鍵三連。

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等系統中供線上系統使用，也可能會存在Hive或者Druid中供數據分析和數據挖掘使用。例如：咱們常常說的報表數據，或者說那種大寬表，通常就放在這裏。

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

ODS 數據準備層

功能：         

        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