數倉建設 | ODS、DWD、DWM等理論實戰（好文收藏）
本文目錄：
一、資料流向
二、應用示例
三、何為數倉DW
四、為何要分層
五、資料分層
六、資料集市
七、問題總結
導讀
數倉在建設過程中，對資料的組織管理上，不僅要根據業務進行縱向的主題域劃分，還需要橫向的數倉分層規範。本文作者圍繞企業數倉分層展開分析，希望對你有幫助。
因文章太長，本文不是完結版，文末可獲取完整PDF版
從事數倉相關工作的人員都知道數倉模型設計的首要工作之一就是進行模型分層，可見模型分層在模型設計過程中的重要性，確實優秀的分層設計是一個數倉專案能否建設成功的核心要素，讓資料易理解和高複用是分層的核心目標。
一、資料流向
二、應用示例
三、何為數倉DW
Data warehouse（可簡寫為DW或者DWH）資料倉庫，是在資料庫已經大量存在的情況下，它是一整套包括了etl、排程、建模在內的完整的理論體系。
1. 主要特點
面向主題
操作型資料庫組織面向事務處理任務，而資料倉庫中的資料是按照一定的主題域進行組織。 主題是指使用者使用資料倉庫進行決策時所關心的重點方面，一個主題通過與多個操作型資訊系統相關。
整合
需要對源資料進行加工與融合，統一與綜合 在加工的過程中必須消除源資料的不一致性，以保證資料倉庫內的資訊時關於整個企業的一致的全域性資訊。（關聯關係）
不可修改
DW中的資料並不是最新的，而是來源於其他資料來源 資料倉庫主要是為決策分析提供資料，涉及的操作主要是資料的查詢
與時間相關
處於決策的需要資料倉庫中的資料都需要標明時間屬性
與資料庫的對比
DW：專門為資料分析設計的，涉及讀取大量資料以瞭解資料之間的關係和趨勢 資料庫：用於捕獲和儲存資料
四、為何要分層
資料倉庫中涉及到的問題：
為什麼要做資料倉庫？ 為什麼要做資料質量管理？ 為什麼要做元資料管理？ 數倉分層中每個層的作用是什麼？
在實際的工作中，我們都希望自己的資料能夠有順序地流轉，設計者和使用者能夠清晰地知道資料的整個宣告週期，比如下面左圖。 但是，實際情況下，我們所面臨的資料狀況很有可能是複雜性高、且層級混亂的，我們可能會做出一套表依賴結構混亂，且出現迴圈依賴的資料體系，比如下面的右圖。
為了解決我們可能面臨的問題，需要一套行之有效的資料組織、管理和處理方法，來讓我們的資料體系更加有序，這就是資料分層。資料分層的好處：
清晰資料結構：讓每個資料層都有自己的作用和職責，在使用和維護的時候能夠更方便和理解 複雜問題簡化：將一個複雜的任務拆解成多個步驟來分步驟完成，每個層只解決特定的問題 統一資料口徑：通過資料分層，提供統一的資料出口，統一輸出口徑 減少重複開發：規範資料分層，開發通用的中間層，可以極大地減少重複計算的工作
五、資料分層
每個公司的業務都可以根據自己的業務需求分層不同的層次；目前比較成熟的資料分層：資料運營層ODS、資料倉庫層DW、資料服務層ADS(APP)。
1. 資料運營層ODS
資料運營層：Operation Data Store 資料準備區，也稱為貼源層。資料來源中的資料，經過抽取、洗淨、傳輸，也就是ETL過程之後進入本層。該層的主要功能：
ODS是後面資料倉庫層的準備區 為DWD層提供原始資料 減少對業務系統的影響
在源資料裝入這一層時，要進行諸如去噪（例如有一條資料中人的年齡是 300 歲，這種屬於異常資料，就需要提前做一些處理）、去重(例如在個人資料表中，同一 ID 卻有兩條重複資料，在接入的時候需要做一步去重)、欄位命名規範等一系列操作。 但是為了考慮後續可能需要追溯資料問題，因此對於這一層就不建議做過多的資料清洗工作，原封不動地接入原始資料也可以，根據業務具體分層的需求來做。這層的資料是後續資料倉庫加工資料的來源。資料來源的方式：
業務庫
經常會使用sqoop來抽取，例如每天定時抽取一次。 實時方面，可以考慮用canal監聽mysql的binlog，實時接入即可。
埋點日誌
日誌一般以檔案的形式儲存，可以選擇用flume定時同步 可以用spark streaming或者Flink來實時接入 kafka也OK
訊息佇列：即來自ActiveMQ、Kafka的資料等。
2. 資料倉庫層DW
資料倉庫層從上到下，又可以分為3個層：資料細節層DWD、資料中間層DWM、資料服務層DWS。
1) 資料細節層DWD
資料細節層：data warehouse details，DWD(資料清洗/DWI) 該層是業務層和資料倉庫的隔離層，保持和ODS層一樣的資料顆粒度；主要是對ODS資料層做一些資料的清洗和規範化的操作，比如去除空資料、髒資料、離群值等。為了提高資料明細層的易用性，該層通常會才採用一些維度退化方法，將維度退化至事實表中，減少事實表和維表的關聯。
2) 資料中間層DWM
資料中間層：Data Warehouse Middle，DWM該層是在DWD層的資料基礎上，對資料做一些輕微的聚合操作，生成一些列的中間結果表，提升公共指標的複用性，減少重複加工的工作。
簡答來說，對通用的核心維度進行聚合操作，算出相應的統計指標
3) 資料服務層DWS
資料服務層：Data Warehouse Service，DWS(寬表-使用者行為，輕度聚合)該層是基於DWM上的基礎資料，整合彙總成分析某一個主題域的資料服務層，一般是寬表，用於提供後續的業務查詢，OLAP分析，資料分發等。一般來說，該層的資料表會相對較少；一張表會涵蓋比較多的業務內容，由於其欄位較多，因此一般也會稱該層的表為寬表。
使用者行為，輕度聚合對DWD 主要對ODS/DWD層資料做一些輕度的彙總。
3. 資料應用層ADS
資料應用層：Application Data Service，ADS(APP/DAL/DF)-出報表結果。該層主要是提供給資料產品和資料分析使用的資料，一般會存放在ES、Redis、PostgreSql等系統中供線上系統使用；也可能存放在hive或者Druid中，供資料分析和資料探勘使用，比如常用的資料報表就是存在這裡的。
4. 事實表 Fact Table
事實表是指儲存有事實記錄的表，比如系統日誌、銷售記錄等。事實表的記錄在不斷地增長，比如電商的商品訂單表，就是類似的情況，所以事實表的體積通常是遠大於其他表。
5. 維表層Dimension（DIM）
維度表（Dimension Table）或維表，有時也稱查詢表（Lookup Table），是與事實表相對應的一種表；它儲存了維度的屬性值，可以跟事實表做關聯，相當於將事實表上經常重複出現的屬性抽取、規範出來用一張表進行管理。維度表主要是包含兩個部分：
高基數維度資料：一般是使用者資料表、商品資料表類似的資料表，資料量可能是千萬級或者上億級別 低基數維度資料：一般是配置表，比如列舉欄位對應的中文含義，或者日期維表等；資料量可能就是個位數或者幾千幾萬。
6. 臨時表TMP
每一層的計算都會有很多臨時表，專設一個DWTMP層來儲存我們資料倉庫的臨時表
六、資料集市
狹義ADS層；廣義上指hadoop從DWD DWS ADS 同步到RDS的資料資料集市（Data Mart），也叫資料市場，資料集市就是滿足特定的部門或者使用者的需求，按照多維的方式進行儲存，包括定義維度、需要計算的指標、維度的層次等，生成面向決策分析需求的資料立方體。從範圍上來說，資料是從企業範圍的資料庫、資料倉庫，或者是更加專業的資料倉庫中抽取出來的。資料中心的重點就在於它迎合了專業使用者群體的特殊需求，在分析、內容、表現，以及易用方面。資料中心的使用者希望資料是由他們熟悉的術語表現的。帶有資料集市的資料倉儲結構
區別資料倉庫
資料集市就是企業級資料倉庫的一個子集，它主要面向部門級業務，並且只面向某個特定的主題。為了解決靈活性與效能之間的矛盾，資料集市就是資料倉庫體系結構中增加的一種小型的部門或工作組級別的資料倉庫。資料集市儲存為特定使用者預先計算好的資料，從而滿足使用者對效能的需求。資料集市可以在一定程度上緩解訪問資料倉庫的瓶頸。 理論上講，應該有一個總的資料倉庫的概念，然後才有資料集市。實際建設資料集市的時候，國內很少這麼做。國內一般會先從資料集市入手，就某一個特定的主題（比如企業的客戶資訊）先做資料集市，再建設資料倉庫。資料倉庫和資料集市建立的先後次序之分，是和設計方法緊密相關的。而資料倉庫作為工程學科，並沒有對錯之分。 在資料結構上，資料倉庫是面向主題的、整合的資料的集合。而資料集市通常被定義為星型結構或者雪花型資料結構，資料集市一般是由一張事實表和幾張維表組成的。
七、問題總結
1. ODS與DWD區別？
問：還是不太明白 ods 和 dwd 層的區別，有了 ods 層後感覺 dwd 沒有什麼用了。
答：站在一個理想的角度來講，如果 ods 層的資料就非常規整，基本能滿足我們絕大部分的需求，這當然是好的，這時候 dwd 層其實也沒太大必要。但是現實中接觸的情況是 ods 層的資料很難保證質量，畢竟資料的來源多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來遮蔽一些底層的差異。
問：我大概明白了，是不是說 dwd 主要是對 ods 層做一些資料清洗和規範化的操作，dws 主要是對 ods 層資料做一些輕度的彙總?
答：對的，可以大致這樣理解。
2. APP層幹什麼的？
問：感覺DWS層是不是沒地方放了，各個業務的DWS表是應該在 DWD還是在 app?
答：這個問題不太好回答，我感覺主要就是明確一下DWS層是幹什麼的，如果你的DWS層放的就是一些可以供業務方使用的寬表表，放在 app 層就行。如果你說的資料集市是一個比較泛一點的概念，那麼其實 dws、dwd、app 這些合起來都算是資料集市的內容。
問：那存到 Redis、ES 中的資料算是 app層嗎?
答：算是的，我個人的理解，app 層主要存放一些相對成熟的表，能供業務側使用的。這些表可以在 Hive 中，也可以是從 Hive 匯入 Redis 或者 ES 這種查詢效能比較好的系統中