以阿里雲的maxcompute的資料倉儲架構為例，
從上往下定義，
dwp的資料，來源是dws+dim，最主要是dws。這裡不討論dim的作用。
dws的資料來源於dwd。
dwd的資料來源於ods。
--------
接下來我們定義原子指標和派生指標。
派生指標定義在dws層。並且繫結原子指標。所有的應用資料由派生指標去group by。
原子指標定義在dwd層+虛擬層。原子指標繫結一個dwd的度量值，但是有可能會有計算，所以不完全在dwd，執行的時候可能會進行計算。稱為一個虛擬的層。
當然可以把這個虛擬層做出來，專門做一層原子指標層。
這個時候我們的指標管理系統裡面應該有以下東西：
| 指標名稱 | 指標來源 | 指標口徑 | |
| 原子指標 | 可以與度量值一致，也可以不一致 | 繫結dwd的表名和欄位 |
1.和繫結的dwd的度量值完全對應 2.需要一點計算，錄入計算邏輯 |
| 派生指標 | 修飾詞+原子指標名稱+時間週期 | 繫結一個原子指標 |
①修飾詞：作為where過濾的欄位 ②時間週期：近7天，近一個月等 ③聚合操作：平均，求和等 ③聚合維度，也可以不錄，在模型管理裡錄 |
| 應用指標 | 同環比+修飾詞+派生指標 | 繫結一個派生指標 |
①聚合的維度：派生指標所在表的欄位 ②可能有一些簡單的過濾。 ③可能會有一些同環比的計算 絕對不允許有欄位計算，如加減乘除，if轉化等，如果有，說明邏輯沒有下沉。
|
舉個例子：
應用指標需要：當月人流量大於2w次並且支付渠道為支付寶的的平均訂單金額淨增長，維度：每一個城市
擁有的業務過程：訂單表。門店人流量表。
| 名稱 | 來源 | 口徑 | |
| 原子指標 | 訂單金額 | 交易表：支付金額，退款金額 | 支付金額-退款金額 |
| 派生指標 |
當月人流量大於2w次 並且支付渠道為支付寶的的平均訂單金額 |
訂單金額 |
①修飾詞： where 支付渠道=支付寶 having 月人流量>2w ②時間週期 where 訂單時間是一個月 ③聚合操作：平均 ③維度：城市，品類 (聚合維度比業務指標更寬） |
| 應用指標 |
當月人流量大於2w次 並且支付渠道為支付寶的的平均訂單金額淨增長 |
當月人流量大於2w次 並且支付渠道為支付寶的的平均訂單金額 |
①聚合維度：城市 ②環比計算，當月減上月 |
以上將一個應用指標的計算邏輯沉澱到不同的層次中的指標管理方式，實現了從度量值到最後應用指標的統一，再加上術語管理系統，
可以解決指標同名不同義，同義不同名的口徑問題。稱之為one data，即一個應用指標有且只有唯一的計算邏輯。
----------------------------------------------------------------------------------------
《模型的作用》
dws的表可以稱之為派生指標的模型。
一個派生指標可以有不同的維度。比如近7月，近一個月，城市品類的，城市商圈的，所以 派生指標：模型 = 1：n
可以在錄入不同維度的派生指標時，
①當做是不同的派生指標，將維度當做口徑記錄下來
②當做是同一個派生指標，建設不同維度的模型(表)，繫結這個派生指標。如果這麼做，應用指標繫結的將不是派生指標，而是dws模型裡的欄位。
----------------------------------------------------------------------------------------
《是否可以將度量值認為是原子指標》
原子指標代表的是指標的最底層，是服務於指標系統的。度量值代表的是業務發生的過程中產生的資料，是記錄業務客觀現象的。
雖然兩者的欄位有很多重合的地方，最好將原子指標重新定義，防止指標管理體系和數倉公共表建設過於耦合而增大統一指標口徑的難度。
----------------------------------------------------------------------------------------
《派生指標和應用指標的區別》
應用指標的來源是派生指標，不一定要計算同環比，很多時候名稱是一模一樣的。
他們的區別在於維度。
dws為了滿足更多的應用指標的計算，維度會更多 更細。
打個比方，維度為城市 品類 商圈 門店等級 的訂單金額，可以上卷 城市維度，品類維度，商圈維度，城市+品類維度，等多達15個組合的應用指標。
這樣BI計算應用指標的時候，就只要根據自己關心的維度做group by即可，非常簡單方便。