dw ：data warehouse 翻譯成資料倉儲
dw資料分層，由下到上為 dwd,dwb,dws
dwd：data warehouse detail 細節資料層，有的也稱為 ods層，是業務層與資料倉儲的隔離層
dwb：data warehouse base 基礎資料層，儲存的是客觀資料，一般用作中間層，可以認為是大量指標的資料層。
dws：data warehouse service 服務資料層，基於dwb上的基礎資料，整合彙總成分析某乙個主題域的服務資料，一般是寬表。
零、資料載入層：etl（extract-transform-load）
一、資料運營層：ods（operational data store）
二、資料倉儲層：dw（data warehouse）
資料明細層：dwd（data warehouse detail）
資料中間層：dwm（data warehouse middle）
資料分層是資料倉儲設計中十分重要的乙個環節，優秀的分層設計能夠讓整個資料體系更易理解和使用。
作為一名資料的規劃者，我們肯定希望自己的資料能夠有秩序地流轉，資料的整個生命週期能夠清晰明確被設計者和使用者感知到。直觀來講就是如下的左圖這般層次清晰、依賴關係直觀。
但是，大多數情況下，我們完成的資料體系卻是依賴複雜、層級混亂的。如下的右圖，在不知不覺的情況下，我們可能會做出一套表依賴結構混亂，甚至出現迴圈依賴的資料體系。
因此，我們需要一套行之有效的資料組織和管理方法來讓我們的資料體系更有序，這就是談到的資料分層。資料分層並不能解決所有的資料問題，但是，資料分層卻可以給我們帶來如下的好處：
清晰資料結構：每乙個資料分層都有它的作用域和職責，在使用表的時候能更方便地定位和理解
減少重複開發：規範資料分層，開發一些通用的中間層資料，能夠減少極大的重複計算
統一資料口徑：通過資料分層，提供統一的資料出口，統一對外輸出的資料口徑
複雜問題簡單化：將乙個複雜的任務分解成多個步驟來完成，每一層解決特定的問題
「面向主題的」資料運營層，也叫ods層，是最接近資料來源中資料的一層，資料來源中的資料，經過抽取、洗淨、傳輸，也就說傳說中的 etl 之後，裝入本層。本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的。
一般來講，為了考慮後續可能需要追溯資料問題，因此對於這一層就不建議做過多的資料清洗工作，原封不動地接入原始資料即可，至於資料的去噪、去重、異常值處理等過程可以放在後面的dwd層來做。
資料倉儲層是我們在做資料倉儲時要核心設計的一層，在這裡，從 ods 層中獲得的資料按照主題建立各種資料模型。dw層又細分為 dwd（data warehouse detail）層、dwm（data warehouse middle）層和dws（data warehouse servce）層。
1. 資料明細層：dwd（data warehouse detail）
該層一般保持和ods層一樣的資料粒度，並且提供一定的資料質量保證。同時，為了提高資料明細層的易用性，該層會採用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯。
另外，在該層也會做一部分的資料聚合，將相同主題的資料匯集到一張表中，提高資料的可用性，後文會舉例說明。
2. 資料中間層：dwm（data warehouse middle）
該層會在dwd層的資料基礎上，對資料做輕度的聚合操作，生成一系列的中間表，提公升公共指標的復用性，減少重複加工。
直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標。
3. 資料服務層：dws（data warehouse servce）
又稱資料集市或寬表。按照業務劃分，如流量、訂單、使用者等，生成字段比較多的寬表，用於提供後續的業務查詢，olap分析，資料分發等。
一般來講，該層的資料表會相對比較少，一張表會涵蓋比較多的業務內容，由於其字段較多，因此一般也會稱該層的表為寬表。
在實際計算中，如果直接從dwd或者ods計算出寬表的統計指標，會存在計算量太大並且維度太少的問題，因此一般的做法是，在dwm層先計算出多個小的中間表，然後再拼接成一張dws的寬表。由於寬和窄的界限不易界定，也可以去掉dwm這一層，只留dws層，將所有的資料在放在dws亦可。
在這裡，主要是提供給資料產品和資料分析使用的資料，一般會存放在 es、postgresql、redis等系統中供線上系統使用，也可能會存在 hive 或者 druid 中供資料分析和資料探勘使用。比如我們經常說的報表資料，一般就放在這裡。
最後補充乙個維表層，維表層主要包含兩部分資料：
高基數維度資料：一般是使用者資料表、商品資料表類似的資料表。資料量可能是千萬級或者上億級別。
低基數維度資料：一般是配置表，比如列舉值對應的中文含義，或者日期維表。資料量可能是個位數或者幾千幾萬。
至此，我們講完了資料分層設計中每一層的含義，這裡做乙個總結便於理解，如下圖。
趁熱打鐵，舉個栗子說明一下，如下圖，可以認為是乙個電商**的資料體系設計。我們暫且只關注使用者訪問日誌這一部分資料。
既然談到了資料分層，那不同的層次中會用到什麼計算引擎和儲存系統呢，本節來簡單分享一下。
資料層的儲存一般如下：
ods 層：ods 的資料量一般非常大，所以大多數公司會選擇存在hdfs上，即hive或者hbase，hive居多。 dw 層：一般和
計算引擎的話，可以簡單參考圖中所列就行。目前大資料相關的技術更新迭代比較快，本節所列僅為簡單參考
如同《漫談資料倉儲和正規化》一文在最後思考資料倉儲和正規化之間的關係一樣，本文也將思考和總結一下資料分層的原則是什麼？為什麼要這樣分層？每層之間的界限又是什麼？
我個人從這幾個角度來理解資料分層的劃分：
從能力範圍來講，我們希望80%需求由20%的表來支援。直接點講，就是大部分（80%以上）的需求，都用dws的表來支援就行，dws支援不了的，就用dwm和dwd的表來支援，這些都支援不了的極少一部分資料需要從原始日誌中撈取。結合第一點來講的話就是：80%的需求，我們都希望以對應用很友好的方式來支援，而不是直接暴露給應用方原始日誌。
從資料聚合程度來講，我們希望，越上層資料的聚合程度越高，看上面的例子即可，ods和dwd的資料基本是原始日誌的粒度，不做任何聚合操作，dwm做了輕度的聚合操作只保留了通用的維度，dws做了更高的聚合操作，可能只保留一到兩個能表徵當前描述主體的維度。從這個角度來看，我們又可以理解為我們是按照資料的聚合程度來劃分資料層次的。
資料倉儲分層DWD DWB DWS
dw data warehouse 翻譯成資料倉儲 dw資料分層，由下到上為 dwd,dwb,dws dwd data warehouse detail 細節資料層，有的也稱為 ods層，是業務層與資料倉儲的隔離層 dwb data warehouse base 基礎資料層，儲存的是客觀資料，一般用...
資料倉儲分層
下面的內容是基於參考中的文件進行的二次讀書筆記。傳統行業的資料倉儲工程師,開始嘗試架構工程領域比較流行的er模型 維度模型方式，構建出乙個四層的模型架構 阿里在構建er時碰到了較大的挑戰，主要是業務快速發展，人員快速變化 業務知識功底的不夠全面，導致er模型產出困難。阿里得出了乙個結論 在不太成熟 ...
資料倉儲分層
資料倉儲更多代表的是一種對資料的管理和使用的方式，它是一整套包括了etl 排程 建模在內的完整的理論體系。現在所謂的大資料更多的是一種資料量級的增大和工具的上的更新。兩者並無衝突，相反，而是一種更好的結合。資料倉儲在構建過程中通常都需要進行分層處理。業務不同，分層的技術處理手段也不同。分層的主要原因...