“指標”是指對於數據的統計值，建立指標體系是為了在報表、Dashboard等工具中快速靈活體現公司數據。
一、指標系統介紹
從直觀上來理解，報表系統中的每張報表是通過一些SQL語句計算出來的，系統只要每天按照每張報表的SQL定時去跑數據就可以了。
但是隨著時間的推移，報表數量越來越多，每天的定時SQL任務跑不動了。但是會發現其實很多報表用到了類似的指標，可能維度不同或者可能完全相同。
這時候就需要昇華一下方案，將報表的計算，細化到指標的計算上。
上述問題的解決需要通過一套完善的指標管理服務來實現，指標服務相當於存儲了某個指標各種維度下的SQL查詢結果。如下圖所示，對於指標1，指標服務需要存儲其在維度1和維度2等維度下的所有拆分值，即存儲的是“維度1-維度2-指標1的值”這樣的索引結構。
有些數據團隊會把這些指標值存儲為數據倉庫中的一個層級，相當於是對DW層明細數據的統計值計算，但是在實際應用中，對指標值的調用需要滿足很強的即時性，存在數據倉庫中可能達不到這樣的性能要求，於是改為存儲在HBase這種Key-Value存儲方式的數據庫中。
按照這樣的存儲方式好處是什麼呢？
當你想要看指標1在“維度1=A&維度2=a”等各種組合條件下的值的時候，可以方便取出來，如果指標1是可以簡單加和的，那麼你還可以查看各種維度組合加和的數據。比如：不選擇維度1和維度2的條件，直接看指標1的總計值，也是可以通過加和做到的。
這樣的處理方式還為用戶自助創建報表提供了可能，用戶可以選擇想看的指標在任意維度下的數據，還可以任意拼接指標形成自己的專屬報表。
而且，這樣做，一個指標不管被多少個報表用到，只用計算一遍數據即可。具體報表呈現的時候，實際只是將各種統計值進行組合，不需要運行SQL實時拉取計算數據，效率也就提高了很多。
二、指標系統的SQL實現
指標系統實際就是寫一個稍微複雜的包含多個group by的SQL，其實看到上面的圖，大家也可以聯想到，其實就是自己在運行SQL的時候得到的一個包含多個索引的group by結果。
思路即使將指標拆分到最小粒度，再在報表中根據需要組合各個維度下的值。
三、指標系統的優缺點
上面解決方案聽起來很完美，實際操作中還是有不少問題存在的。
- 對於計算時需要去重的指標（比如：一個用戶多個訂單這種事實表，要計算用戶的數量），你得到的只是在當前維度組合下的指標。並不能簡單實現只取部分指標的場景，或不選擇維度的場景，大家可以自己思考下為什麼。
- 因為指標系統拆為了儘可能增大指標的可重複使用性，拆分了儘可能多的維度，有時候甚至維度的組合行數已經達到了10萬+的級別。這就造成在報表系統中組合不同維度的數據有時候，實時處理壓力很大。當然也是有辦法進行優化的，這裡就不深入介紹了。
- 因為指標是一層數據抽象，當指標數據出現問題的時候，排查問題就相當於多了一層。類似的，修復數據也要多修復一層。
- 另外，如果要給現有指標體系增加維度，舊數據的處理也是一件比較麻煩的事情，因為需要重跑之前的歷史數據。
四、業務的指標體系建立
指標的原理講完了，那麼在實際操作中，我們需要做哪些指標出來呢？
其實指標需求主要來自業務方運營人員等，但是不同運營部門可能關心的側重點不同，而且會有遺漏情況。
首先我們要把不同部門的需求收集完，然後根據需求指標類型進行分類。在分類中要cover到大家的需求，還要儘可能窮舉其他可能的指標。這部分也是依賴自己對於業務系統的瞭解及數據庫的瞭解，其實跟數據倉庫的搭建是一體的事情。
閱讀更多 人人都是產品經理 的文章
