1、概述
數據倉庫中，常見的分層包括ods、dwd、dws、dwt、ads、dim等
2、傳統上的數據分層
早期的大數據平台是以hadoop為核心，數據開發也是以MapReduce為主，hive等sql類開發很少見。
因為當數據從多個源頭采集上來之后，格式化便成了原始數據。
原始數據經過MapReduce的開發之后，生成各個報表。然后統一導入到mysql或者oracle中，便可以直接看到報表。
在數據量相對較小並且看數據的人較少時，這種方式是非常高效且實用的。
但是，別的部門在看到hadoop的性能之后，放棄了原有編寫的數據庫腳本，轉而將邏輯應用了進來，這時候平台就不可避免的增加負荷。各種邏輯雜糅使得邏輯變得模糊不清，這時候需要做功能上的耦合。
公司的規模一路飆升，數據團隊也從幾個人快速增長到了十幾個人，架構也發生了更多的變化，這個時候你就意識到了，我們可能要有一套系統的理論來組織數據倉庫了。
3、標准分層
阿里雲數倉分層解決方案 
4、命名規范
- 表命名
- ODS層命名為：ods_表名
- DWD層命名為：dwd_dim_表名、dwd_fact_表名
- DWS層命名為：dws_表名
- DWT層命名為：dwt_表名
- ADS層命名為：ads_表名
- 臨時表命名為：表名_tmp
- 用戶行為表命名為：表名_log
- 腳本命名
- 數據源_to_目標_db/log.sh
- 用戶行為腳本以log為后綴
- 業務數據腳本以db為后綴
5、為什么要分層
- 把復雜問題簡單化
將復雜的任務分解成多層來完成，每一層只處理簡單的任務，方便定位問題
- 減少重復開發
規范數據分層，通過中間層數據，能夠極大的減少重復計算，增加一次計算結果的復用性
- 隔離原始數據
不論是數據的異常還是數據敏感性，使真是數據與統計數據解耦。
6、各層詳細解釋
- ODS
- 保持數據原貌
- 采用壓縮（壓縮比一般100g數據壓縮完10g左右）、列式存儲
- 創建分區表
- DWD
- 數據清洗
- 去除空值
- 過濾核心字段無意義的數據（如：用戶id為null）
- 清洗手段
- sql
- mr
- rdd
- kettle
- py
- 清洗掉多少數據算合理
- 1萬數據清洗掉1條
- 脫敏
- 對手機號、身份證號、密碼等敏感數據脫敏
- 維度退化
- 對業務數據傳過來的表進行維度退化和降維（如：商品一級二級、省市縣、年月日）
- 采用壓縮、列式存儲
- 創建分區表
- 數據清洗
- DWS
- 有3-10張寬表（能處理70%以上的需求）
- 用戶行為寬表
- 商品寬表
- 登錄注冊寬表
- 用戶購買商品明細寬表
- 購物車寬表
- 售后寬表
- 異常錯誤寬表
- 有3-10張寬表（能處理70%以上的需求）
- ADS
- 指標層
7、總結
- 關聯范圍廣
在很多時候，有些數據是需要跨多個業務線的，每個業務線的數據都很大，這時候不僅是計算邏輯復雜無比，一個SQL幾百行，而且對於數據傾斜的問題挑戰更大，Hive運算的時間也非常長。這種情況下需要適當考慮在運算節點中加入一些MR的運算過程，以提高計算速度，單純的優化Hive SQL並不是一個好主意。
- 血緣關系
盡管DWS是統計中間層的數據，但由於業務的變化多種多樣，一個中間層需要關聯幾張甚至十幾張表，每張表都有自身的業務邏輯，關聯很多，這就導致了一張完整的中間表上游特別多，發現某個數據異常時非常難以追溯問題。這時候你需要額外的技術支持：元數據平台（atlas），通過分析這張表的上游關聯關系，來進行問題的定位。
- 產出時間長
某些DWS表動輒需要幾個小時的計算時間，對於數據的准時產出影響很大。同時如果需要做小時級的報表統計，那么太過於復雜的中間層設計就顯得很累贅。建議這個過程有產品經理的介入，以梳理需求的重要性和優先級，如果非必要統計，盡量的就不要做中間層，開放一些sql查詢的權限也是可以的，這里做好數據安全管理即可。
- 重構難度大
分層理論盡管聽上去容易理解，但真的需要到這個理論時，你所搭建的數據平台勢必已經非常大了，而需要適應這套理論，原有的統計邏輯大多數都要重寫，這里花上幾個月的時間都是很常見的，並且很可能需要雙平台同時進行數據計算，以渡過重構的不穩定期。這個階段的挑戰就是如何解釋投入產出比，要有充分的的信心，詳情這項工作完成后，節省的開發時間至少是一個數量級的。原來1天的開發工作，因為有了數據分層，1小時甚至幾分鍾，都是可以開發完的。
參考1：https://mp.weixin.qq.com/s/aPTzSuD9RaE3dLQm-fXi1w
參考2：https://www.aliyun.com/solution/datavexpo/datawarehouse?spm=5176.12825654.h2v3icoap.550.56c82c4aPRC8FK