數(shù)據(jù)中臺：指標管理中臺演進路徑及價值

數(shù)據(jù)中臺：指標管理中臺演進路徑及價值收到一個朋友關(guān)于指標管理中臺的問題咨詢，關(guān)于設(shè)計指標管理中臺時，針對同一個指標業(yè)務(wù)口徑和財務(wù)口徑不一致時，在指標數(shù)據(jù)集綁定時是否需要支持多個數(shù)據(jù)源。就著這個問題，展開聊一聊指標管理中臺的產(chǎn)品演進過程。一、指標管理中臺的產(chǎn)品演進路徑中臺的概念沒出來之前，會稱之為指標管理平臺。對于指標管理平臺這個偏后端數(shù)據(jù)資產(chǎn)管理與治理的數(shù)據(jù)產(chǎn)品來講，其建設(shè)的初衷主要解決以下幾個問題，如果你也要做指標管理，可以看下這幾個需求場景是否都覆蓋了。1.指標字典的存檔與信息查詢企業(yè)發(fā)展初期數(shù)據(jù)產(chǎn)品不成熟，經(jīng)營管理會上不同部門（產(chǎn)品、運營、銷售等）一起給老板開會匯報業(yè)績，發(fā)現(xiàn)數(shù)據(jù)對不上。于是為了方便排除數(shù)據(jù)問題，就形成了指標統(tǒng)計口徑說明字典，那個時候在線文檔還不流行，主要是excel或者Wiki維護。主要問題：信息傳遞困難、流程不清晰、更新不及時，且無法和報表產(chǎn)品聯(lián)動。指標管理平臺1.0的版本首先先要把指標統(tǒng)計口徑能夠線上化維護起來，并且可以把信息輸出給下游報表應(yīng)用，鼠標懸浮時，tooltips就可以展示指標說明。2.統(tǒng)一指標口徑的業(yè)務(wù)流程規(guī)范有了指標字典，還是沒法解決數(shù)據(jù)對不上的問題，于是老板給數(shù)據(jù)部門下了個需求，數(shù)據(jù)團隊牽頭把指標口徑統(tǒng)一一下，下次會議不要再出現(xiàn)會上對數(shù)的問題了。于是，數(shù)據(jù)PM想了個辦法，新增指標需求的時候，要有統(tǒng)一的流程，業(yè)務(wù)部分申請，數(shù)據(jù)分析師審核，數(shù)據(jù)PM整理需求，數(shù)據(jù)開發(fā)進行數(shù)據(jù)報表開發(fā)，把這個流程集成到指標管理平臺當中。并且可以通過工單流轉(zhuǎn)的方式，進行IM或者郵件的提醒。這樣一來，流程是規(guī)范了，但是犧牲的是指標開發(fā)效率，比較涉及不同角色協(xié)同。對于指標數(shù)量比較少，且更新不頻繁的業(yè)務(wù)是沒問題的。3.指標的數(shù)據(jù)統(tǒng)計邏輯業(yè)務(wù)統(tǒng)計口徑是明確了，但業(yè)務(wù)經(jīng)常反饋數(shù)據(jù)問題，數(shù)據(jù)開發(fā)排查時，要逐層翻代碼才能知道這個指標使用的是哪個數(shù)據(jù)源，SQL邏輯是什么，每個任務(wù)光點開操作就要好幾層，有時不小心誤操作保存了，就導(dǎo)致了數(shù)據(jù)bug，所以，指標還需要和數(shù)據(jù)源綁定。有了指標和數(shù)據(jù)源的映射，就可以把指標血緣做起來了。指標血緣是指可以鏈路追蹤指標數(shù)據(jù)加工的來源，以及輸出的報表或API應(yīng)用，當業(yè)務(wù)端質(zhì)疑指標異?；蛐枰_認指標口徑時，可以基于血緣工具找到產(chǎn)出表，以及最源頭的數(shù)據(jù)來源。同時，當數(shù)據(jù)質(zhì)量監(jiān)控測發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題時，可以及時反饋到下游應(yīng)用，應(yīng)用端對用戶進行提醒，避免錯誤的數(shù)據(jù)給用戶帶來負面的決策影響。通常數(shù)據(jù)血緣是服務(wù)于整個數(shù)據(jù)中臺體系，所以指標平臺可以復(fù)用公共的血緣查詢能力，沒必要單獨建設(shè)，只需要把平臺內(nèi)的模型、數(shù)據(jù)集、指標、應(yīng)用的關(guān)系數(shù)據(jù)采集好，反饋給血緣模塊，血緣模塊進行數(shù)據(jù)鏈路擴展即可。4.指標數(shù)據(jù)API接口輸出主要是在做定制化Dashboard或者可視化大屏開發(fā)時，需要前端開發(fā)改造Echart，Java后端開發(fā)寫接口查數(shù)據(jù)開發(fā)清洗好的數(shù)據(jù)表（根據(jù)數(shù)量大小和實時性要求，放到不同的查詢引擎，如MySQL，Greenplum，Clickhouse等）。這樣一來，一個可視化頁面可能就需要一周的時間。對于報表需求來說，就是指標和分析維度，指標API的結(jié)構(gòu)相對固定，能不能讓系統(tǒng)配置化，而不是Java開發(fā)寫沒技術(shù)含量的代碼呢，這里其實有點低代碼和中臺的意思了。因為指標已經(jīng)和數(shù)據(jù)源綁定，查詢邏輯也有了，自動生成一個查詢體的接口，通過一些JDBC/ODBC的鏈接返回數(shù)據(jù)，給前端畫圖使用。5.自助式指標分析數(shù)據(jù)化運營促使人人都需要用數(shù)據(jù)，會員業(yè)務(wù)部要看會員的訂單量，營銷部門要看活動訂單量。都是一個訂單數(shù)指標，限制條件不同。標準化的指標生存流程已經(jīng)很難支撐業(yè)務(wù)爆炸式增長的數(shù)據(jù)需求。所以，業(yè)務(wù)人員開始手寫SQL或者推動公司自研或者外采自助BI產(chǎn)品。知道了數(shù)據(jù)集、字段含義后，自己拖拉拽進行可視化分析，配置可視化Dashboard。這樣一來，定制化開發(fā)的可視化報表需求越來越少，主要在一些大屏或者給管理層使用的定制化功能方面了。這個時候，指標平臺想要發(fā)揮余熱，就要和自助BI分析結(jié)合（自研產(chǎn)品），把指標管理平臺作為一個數(shù)據(jù)源類型，用戶可以直接選擇指標、共有的分析維度，借助自助BI的可視化配置能力，基于指標配置報表。畢竟相比較基于數(shù)據(jù)模型來說，指標的加工程度更高。6.智能AI指標分析ChatGpt火了后，各行各業(yè)都想著蹭上熱點，很多人擔心被AI替代。對于數(shù)據(jù)結(jié)構(gòu)化程度較高的指標管理平臺，天然就有了可以和AI結(jié)合的優(yōu)勢，18年在攜程的時候嘗試做過一個數(shù)據(jù)問答的產(chǎn)品，即用戶輸入數(shù)據(jù)指標需求，通過知識圖譜返回指標的拆解分析?，F(xiàn)在AI更加智能，能夠做的事情和功能會更加強大。比如昨天App訂單數(shù)是多少？幫我做一個營銷效果分析的報表（利用NLP和AI把營銷域的指標呼喚出來，組合成一個可視化報表）。二、指標管理平臺徹底解決數(shù)據(jù)口徑不一致的問題嗎？從指標管理平臺提供的解決方案可以看出，主要是指標建設(shè)流程的規(guī)范化，以及指標生產(chǎn)到應(yīng)用流程的全鏈路產(chǎn)品化。流程的規(guī)范化涉及一個指標需求在不同工種之間的需求流轉(zhuǎn)，在系統(tǒng)初期指標上線效率整體還是比較低的。再者就是數(shù)據(jù)中臺的思想是提高數(shù)據(jù)輸出效率，很多數(shù)據(jù)中臺的產(chǎn)品解決方案會包括自主BI數(shù)據(jù)產(chǎn)品，即產(chǎn)品和運營可以直接基于數(shù)據(jù)集進行拖拽式的分析和可視化報表配置。規(guī)范化和自助化存在交叉和沖突。不做指標統(tǒng)一管理，指標永遠是錯綜混亂，指標標準化，一定程度又會影響數(shù)據(jù)分析的時效性，那到底該如何權(quán)衡，或者確定好指標管理平臺的目標和邊界呢？指標的建設(shè)是需要長期的積累和完善的，可能規(guī)范化的初期會有一段時間的陣痛期，但隨著平臺內(nèi)指標的豐富，新增的需求可能會越來越少，即可以確定的是對于業(yè)務(wù)條線多的企業(yè)是需要將指標統(tǒng)一管理，對于在公共層面的通用指標，必須由指標管理平臺統(tǒng)一生產(chǎn)和管理。而對于一些業(yè)務(wù)臨時性、個性化強的指標或者數(shù)據(jù)報表需求，可以基于自助BI工具，以及SQL取數(shù)工具等，快速自助化獲取所需的數(shù)據(jù)即可。例如，某運營部門需要對端午節(jié)新上線的一個盲盒活動進行數(shù)據(jù)監(jiān)控分析，直接基于盲盒數(shù)據(jù)模型，利用自助分析進行可視化配置的效率遠遠高于先生產(chǎn)指標，再利用指標的流程。三、總結(jié)指標管理平臺是可以幫助企業(yè)進行指標規(guī)范化管理的有效工具，但規(guī)范化帶來的犧牲就是流程的冗長和效率問題。對于共用的指標以及緩慢變化的業(yè)務(wù)，可以基于系統(tǒng)進行管理和維護，而對