簡單設計一個onedata指標管理體系

以阿里雲的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便可，很是簡單方便。