數據中臺數據模型的分層，業界比較通用的分層方式是將數據模型分為5層：①ODS（Operate Data Store，操作數據層）、②DIM（Dictionary Data Layer ，維度數據層）、③DWD（Data Warehouse Detail ，明細數據層）、④DWS（Data Warehouse Service，匯總數據層）、⑤ADS（Application Data Store，數據應用層）。
各層數據模型之間的關係如圖1-1所示。
圖1-1 分層模體系
第一層是ODS和DIM層。ODS層數據是數據倉庫的第一層數據，是業務資料庫的原始數據的複製，例如，每條產品線的用戶信息、訂單信息等數據一般都是原封不動地同步到數據中臺的ODS層中。ODS層的作用是在業務系統和數據倉庫之間形成一個隔離層，在數據中臺進行計算任務時，可以以ODS層的數據為基礎進行計算，從而不給業務資料庫增加負擔。DIM層存儲的是維度數據如城市、省份、客戶端等維度的數據。
第二層是DWD。DWD層數據是數據倉庫的第二層數據，一般是基於ODS和DIM層的數據做輕度匯總。DWD層儲存經過處理後的標準數據，需要對ODS層數據進行再次清洗（如去空/去髒數據、去超過極限的數據等操作）。DWD層的結構和粒度一般與ODS層保持一致，但是DWD匯總了DIM層的維度數據，比如在ODS層只能看到客戶端的ID欄位，但是在DWD不但能看到客戶端ID欄位，還能看到客戶端的名稱欄位。
第三層是DWS層。DWS層數據是數據倉庫的第三層數據，是以DWD層的數據為基礎進行匯總計算的數據。DWS層都是各個維度的匯總數據，比如某日某產品線的訪問用戶數、收藏用戶數、加購用戶數、下單用戶數、支付用戶數等。
第四層是ADS層。ADS層數據是數據倉庫的最後一層數據，以DWS層數據為基礎進行數據處理。設計ADS層的最主要目的就是給數據可視化應用提供最終的數據。後端開發工程師基於ADS層的數據將最終數據結果以接口的形式展示給數據中臺的應用層。
數據倉庫為什麼要分層建模呢？我們還是通過實際案例來理解。假設還是要統計某條產品線A當月的交易額，如果沒有採用分層建模，那麼數據統計就是以結果導向的，直接提取業務資料庫中的產品線A的訂單時間、訂單金額，然後篩選時間為當月的訂單，並基於訂單金額做匯總計算，最後通過接口的方式將數據輸出到應用層。
如果採用分層建模，第一步是將業務資料庫的數據同步到ODS層中，第二步是通過DWD豐富統計指標的維度，目前案例中的需求是時間維度，可以預先增加其他常用的維度如產品線、客戶端的維度，第三步是在DWD層匯總各個維度的交易額，第四步是基於現在的需求，計算出產品線A的當月交易額，在ADS層提供要顯示的數據。
在實際數據中臺項目中針對數據指標的開發，有以下2種情況比較常見。
（1）數據指標口徑發生變化。隨著業務的變化，數據指標的統計口徑不是一成不變的，數據指標經常會基於業務目標的變化而變化，相應的統計邏輯也會變化。
（2）增加數據指標的統計維度。單個維度的數據指標統計隨著業務的發展有可能不再滿足需求，此時很有可能遇到給數據指標增加統計維度的情況，數據指標的統計維度越豐富，就越有利於數據分析。
針對這兩種情況我們分別看一下沒有分層建模和分層建模的區別。
首先是第一種情況。
數據指標的統計口徑發生了變化，比如統計口徑由之前的統計產品線A的當月全部訂單的交易額變為統計產品線A當月的訂單狀態為「已支付」的訂單的交易額。此時其實數據指標並沒有發生變化，仍然叫「交易額」，但是統計口徑發生了變化。
如果沒有進行分層建模，那麼對外的接口要增加訂單狀態篩選的邏輯，再進行測試、核對數據、發布新版本接口才能完成針對交易額統計的優化。
如果進行了分層建模，ADS層、DWD層的數據是不用變化的，因為業務資料庫的原始數據沒有變化。此外，因為數據指標的顯示沒有變化，所以只需針對DWS層增加篩選訂單狀態為「已支付」的統計邏輯，然後由數據開發工程師、測試工程師測試DWS層並統計數據即可，不用發布新版本的對外接口，所以應用層並不用再針對接口做對接。
再看第二種情況。
給數據指標增加統計維度，比如不但要查看產品線A的當月交易額，還要查看產品線A的當月安卓端、iOS端的交易額。如果沒有進行分層建模，每增加一個維度就增加一倍的工作量，要重新修改計算邏輯、重新定義對外接口、重新測試、重新發布新的版本才能完成數據指標的新的維度統計。如果進行了分層建模，由於DWD層和DWS層已經豐富了交易額的維度如產品線、客戶端等，那麼只需後端開發工程師在通過接口提取ADS層數據時新增維度「安卓端」和「iOS端」的統計結果，然後重新發布對外的接口即可，由於新的數據指標統計不需要數據開發工程師的參與，所以大大減少了數據中臺開發的工作量。
-
----END-------