指標系統計算架構設計

前言

前一篇《指標管理系統設計》，我講了指標體系要解決的問題，以及指標系統宏觀搭建和模型上的設計。其中對具體實施時的計算存儲架構說的不是特別清楚。這一篇，我將着重介紹指標計算架構的設計。

過往的一些實現問題

指標體系跟標簽體系其實有些類似，都有很多的字段，甚至在某種程度上，他們還可以成為依托關系。比如標簽系統可以使用指標體系作為數據基礎，當然這是題外話。這里列舉下我之前參與的標簽系統和一些報表開發所存在的問題。

下圖是一個標簽系統的的標簽加工邏輯片段，這個腳本一次性的將標簽體系中的所有標簽挨個計算出來

下圖是一個報表sql的腳本片段，它也一次性計算出了該表報的多個字段，有很復雜的加工邏輯

從軟件設計的角度來看，上述的開發方式耦合度很高，這會帶來一些列的問題

• 所有邏輯耦合在一起，后續閱讀理解很困難
• 要下線、新增、更新一個指標/標簽需要更改原來的腳本，代價較高，出現bug時還會影響之前的指標/標簽
• 多個報表擁有相同口徑的指標時，該指標的加工邏輯需要在多個報表中重復編寫，修改時也需要多處修改，難免掛一漏萬

計算架構設計

對於上述問題，解決的主要思想是，低耦合高內聚。將報表拆散到指標粒度，計算存儲的單元不是報表，而是指標。從而讓指標的復用性增強，也是的對單個指標增刪改的效率更高，提升整個系統的穩健性。

整個計算架構分為如下圖的四層

• 基礎數倉層，這一層主要是數倉模型
• 指標計算層，一個指標一個計算任務(任務可以是sql或其他加工腳本代碼)，它基於底層的基礎數倉層進行加工
• 指標存儲層，每一個加工好的指標，都有一個對應的表來存儲
• 報表層，業務報表的輸出，通過靈活的join組合各指標表，即可得出最終的報表

為什么要一個指標一個表

不同指標其使用的維度個數不同，這使得指標結果數據的字段都是不同的，無法統一用一個表來存放所有指標值。比如最近30天各大區的銷售額指標，使用了一個維度，大區

大區	銷售額
華中	500000
華北	600000
華東	700000
...	...

而最近30天，各大區，各產品線的銷售額度，就使用了兩個維度，大區，產品線

大區	產品線	銷售額
華中	女裝	10000
華中	男裝	20000
華北	男裝	30000
華北	童裝	40000
...	...	...

一個表一個指標是否過多

指標只要不重復建設，上萬個差不多能覆蓋一般公司的所有報表需求。上萬個表對於一般的大數據處理系統比如hive來說，沒什么大問題。何況這些指標表只是多，並不一定數據量大。

參考資料

https://mp.weixin.qq.com/s/uavKimWskRE8Ea83fv_tpA
https://www.cnblogs.com/niceshot/p/13640630.html