本文將分享京東零售在指標中臺建設方面的實踐經驗。京東指標中臺依據現代數據棧、Headless BI、數據虛擬化和數據編織等方法論，并結合自身了多運營模式，多運營視角，多數據維度等業務特點，構建了從指標定義到指標生產再到指標消費的全鏈路解決方案。指標中臺技術不僅僅是一個技術實現，更是一種組織和管理數據的戰略思維。指標中臺技術是企業在數字化轉型過程中的一種重要策略，它通過構建共享平臺來整合企業的核心能力，從而提升業務效率和市場響應速度。隨著技術的發展和市場的變化，中臺技術將繼續演進，為企業帶來更多的創新和價值。

一、背景介紹

首先來介紹一下京東指標中臺建設的背景。

1. 背景介紹-問題定義

在建設指標中臺之前，公司內部已經存在指標系統、指標平臺或者類似的產品的，但都可以歸為"指標登記/注冊系統"，這類系統會通常提供指標查找，注冊等功能，希望可以達到指標的統一維護，一處注冊，多處使用的效果，但因為本身的定位和架構設計等問題，逐漸都以失敗告終。這類系統通常會有以下幾類問題：

（1）查找難

指標難找的根源是定義的不夠清晰和準確?！爸笜说怯浵到y”在找指標的時候，往往只能通過一些關鍵字，例如“交易額”、“交易量”，來進行搜索，會得到很多“相近”的結果，很難定位到最終想要的結果。存在很多“同名不同義”或“同義不同名”的指標。

其次，即使可以找到，是否敢用？登記性質的指標系統，指標定義和指標生產的割裂的，指標的質量很難保證，指標的維護和治理都依賴"自上而下"的運動式的治理。用戶很難知道指標的確切口徑，以及是否是最新的，于是很可能不得不創建一個相似的指標為自己所用，因此慢慢的，這類系統最后都逐漸被淘汰了。

（2）定義難

我們認為指標的定義過程，是一個將業務中的自然語言進行結構化的過程，進行拆解的過程。之前的指標系統，往往沒有很明確的定義規范，有的雖然也是基于原子指標+衍生指標來定義，但定義的過程往往還是通過“非結構化”的自然語言來進行，這樣很難準確的表意；基于上述問題，可能還會成立諸如"資產小組"的組織，來協助指標定義，這樣做確實能比較有效的提升指標的質量，但這完全就依賴于個人經驗，"知識"并沒有沉淀在系統中，勢必會帶來諸如"人力短缺"以及"指標質量不穩定"等問題。

（3）開發難

早期的指標系統往往都不具備指標開發的功能，指標開發流程仍然是傳統的數據加工+數據服務開發+指標展示層開發，指標的開發和定義是完全割裂的。指標的質量完全取決于個人能力，開發過程中有多少中間表，有沒有不必要的浪費，完全不可控；而且口徑可能散落在這個過程中的各個環境，比如一個過濾條件，既可以在數據開發時的 spark 里做，也可能上提到指標服務 Java 中做，甚至在數據展示中進行，這樣對口徑的還原難度很大。我們就有發生過，兩個數據產品對口徑對一個月都對不齊的案例。對于口徑有變更，或者新功能開發，難度都很大。

（4）使用難

由于沒有統一的查詢語言，每個指標的調用方式都取決于開發團隊，因此一個指標想復用到另一個系統上就涉及重復開發，比如為大屏開發的指標，BI 報表想復用，是無法直接復用的，需要進行改造。

2. 背景介紹-解決思路

面對上述問題，我們把業務目標定義為以下五點：

• 首先要有一個清晰的指標目錄，這個指標目錄里要能很便捷很準確地找到需要的指標，好用且敢用。
• 第二，指標定義一定要清晰，既可以保證區分度，又要保證精確度，避免指標二義性的問題。
• 第三，要有比較強大的指標生產能力，通過指標的定義來驅動指標生產，系統可以解決的問題一定要系統來解決，盡量減少人工參與。在性能上，可以滿足業務需要，能從全局考慮數據加速的問題。
• 第四，指標消費有統一的查詢語句，與最終的展示層無關，即 headless BI 的概念。
• 最后是指標治理，保證指標口徑永遠都是最新的，從開始加工到最后展示這條鏈路中，如果發現有低頻使用，那么從數據到服務到指標應用都要有相應的指標退出機制，從而釋放整條數據鏈路上的資源。

3. 定義用戶

指標中臺是服務哪些用戶的：

• 業務師，分析師
  主要訴求是能夠清晰地獲取指標，不太關注指標的實現過程。對應能力就是清晰的指標目錄。
• 數據產品，資產產品
  負責定義指標。對應能力為指標定義。
• 數據、服務開發
  負責指標生產，準確地實現指標口徑。對應能力為指標開發。
• 數據消費
  準確的消費數據，實現業務訴求。對應能力為指標消費。

二、指標中臺建設

1. 整體架構

虛線以內的都是指標中臺的范圍，從左往右看，首先是用戶交互的部分，用戶可以在"指標市場"中檢索想要的指標，還可以進行指標定義，指標的定義依賴指標語義層的建設。語義層包括 4W1H，指標，維度，修飾等概念和規范，下面會詳細介紹。中間是一整套數據鏈路，從數據生產到數據查詢，都可以通過系統化進行配置，大大減少了人力投入。最右側是元數據，包括配置信息，語義信息等，為數據的生產，查詢，治理提供依據。下面將會展開詳細介紹。

2. 語義層建設

關于語義層應該建設在哪里，業界大致有三種方案，分別是在模型層，展示層，或者獨立一層。隨著近年來的發展和迭代，大家發現將語義層耦合在模型層或者展示層都是有明顯弊端的。如果語義層建設在模型層，那勢必跟業務耦合得太緊。數倉產出的結果應該是一個個“積木”，可以根據業務需要進行組合，而不應該與上層業務耦合，否則隨著業務的成長，數倉的數據將會爆炸。另外一個更重要的原因，如果語義層放在數倉，生產血緣可以很容易的進行構建，通過調度系統就知道數據整個的加工鏈路，但是消費血緣將是缺失的，不知道指標數據該如何使用。反過來，如果與展示層耦合得比較緊，那么只能回答消費血緣，而不知道指標數據是如何加工的。

所以最合適的一種方式是語義層要有一個獨立的建設，對下要屏蔽業務，對上要屏蔽數據模型的概念。但這樣做的缺點就是對語義的制定規范會比較難，但考慮到其收益，現在也是業界普遍認可的一種方式。

上面提到過，我們認為定義指標的過程，就是將業務的"自然語言"結構化拆解的過程。而拆解規則設計得越好，指標定義的就越準確，既能保證區分度，也能保證精確度。這里的核心概念就是 4W1H，即 4 個 W 開頭的單詞，和一個 H 開頭的單詞，分別回答作用范圍，領域，動作，作用在誰身上，以及如何量化的問題，回答好了這幾個問題，一個原子指標就定義好了。

基于原子指標，結合業務限定和函數就可以得到衍生指標，這是用戶最常用的指標類型。業務限定簡單點說就是數據的過濾條件，SQL 中的 where 語句。業務限定有兩個子類型，一類叫做修飾，它由維度操作符和維值組成，比如部門 id = 1 或者成交 flag = 0 的。另一個是“裁剪口徑”，“裁剪口徑”是一些列修飾的集合。我們發現，大部分用戶在定義指標時，都是參考某些核心指標來定義的，比如保證和零售大盤成交金額的業務限定保持一致，而核心指標上有很多修飾，如果一個一個添加，操作起來是很麻煩的；而且一旦這個核心指標的口徑有變化，用戶定義的這新指標是很難感知到的，因此，我們在修飾的基礎上封裝了”裁剪口徑“，這樣在指標定義時不僅可以通過選擇和核心指標一致的“裁剪口徑”，就能很輕易的就能和其保持口徑對齊，如果口徑有更改，還可以第一時間知道。

通過上圖的示例可以看到是如何通過 4W1H 來定義一個原子指標的。再加上裁剪口徑，就可以得到衍生指標。另外，我們通過函數來定義時間周期和指標的二次聚合，比如近 7 天，近半年，年至今等時間函數，和均值，累計值，最值等二次聚合。

在衍生指標的基礎上進行四則運算得出的新指標，適合定義各種比率比值，可以得到復合指標。

以上介紹了指標定義和體系建成的過程，而實際使用過程中還是會遇到很多問題。這里介紹其中一些關鍵問題。

首先，在推廣 4W1H 這一核心理念時，有些用戶不太理解，覺得又是在造輪子。我們經過了很詳細地推演，證明這套策略可以覆蓋絕大部分指標定義過程，并在小范圍進行實驗性落地后，才開始大范圍推進推廣。經過一年，用戶也慢慢發現這套體系真的能夠幫助其提效，能做到多方共贏，最終逐漸走向正軌。

4W1H 的內容怎么選也是很重要的，現在業務域主題有 40 個，業務過程和主題上百個，對缺乏經驗的用戶來說，很難從中做出選擇。比如成交購買用戶數，其中主體是用戶，度量是數量。在最初還沒有口徑繼承能力時，業務方要建一個時尚業務域的成交購買用戶數，主體選擇了“購買_用戶”，度量是“人數”，也不能說他定義的就是不對的，但基于此，在系統中就很難匹配出這兩個指標是存在關系的。這里存在一定的靈活性和不確定性，如果以這種方式建立下去，就會出現相似指標太多的情況。因此我們采用了主動治理和被動治理的方式來解決該問題。主動治理是由系統推薦一些最佳實踐，比如被使用最多的，有其他核心產品的信用背書的等等，主動幫助用戶進行選擇，減少出錯的可能。被動處理是在后臺分析合理性，并進行總結經驗，推動用戶進行治理。經過以上的優化，用戶定義指標的準確率得到了顯著提高。

第三個問題和第二個類似，是一個更加細化的問題。4w1h 的有些概念，是可以搭配使用的，比如廣告主題下的流量-頁面，以及點擊-坑位，這種搭配是需要業務常識的，如果不知道，就可能選擇點擊-頁面這個組合，看起來也沒錯，但并不專業，容易出現二義性。我們在工作中，也在逐步收集用戶的數據進行分析，并和有經驗的同事來共同制定相關標準。

最后，由于注冊流程比較冗長，很多審批需要人工完成。我們也結合了上面主動治理和被動治理的方式，在指標定義過程中，如果滿足一些條件，就會簡化審批流程。

3. 指標生產

下面介紹指標生產。傳統的指標生產，服務研發和數據研發基于約定進行開發，當一個需求出現后，服務研發主導和數據研發主導的解決思路是不一樣的。如果是數據研發主導，比如某個需求要做三個看板，可能就開發三個對應的模型，如果性能不好，可以再做預計算，預關聯。如果是服務研發，會分析需求中這三張表是否有一些共用的信息，是不是可以只用一張表。兩方都是從自己的角度出發來進行設計。實際采用哪種方式，哪種方式是相對更優的，就完全取決于研發的個人能力以及整個團隊的能力，并沒有一個絕對的評判標準。所以我們希望通過系統來替代人工的開發，來屏蔽掉這種不確定性。

下面介紹配置化生產的工作過程。比如配置一個類似于成交金額的訂單金額，首先要設置好物理表，把這個指標所需要的維度和修飾都定義好，系統可以自動翻譯出來一個 SQL 查詢語句，對應的指標，維度和修飾都可以體現在 SQL 上面。

如果維度是來自于維表，可以進行關聯維表的配置。

再復雜一些的情況，明細數據的粒度很細，按某些維度看是有重復數據，比一個訂單有多條記錄，那么就要按訂單 ID 或者 sku_id 先做去重，之后再做聚合。這里可以進行二次聚合的配置。

上述是指標口徑的配置。對于在線查詢的要求，性能上還達不到，需要將數據加速到 OLAP 存儲引擎中，因此這里需要配置加速策略。我們當前支持介質加速、輕聚合、預計算，以及智能加速。支持 ClickHouse、HBase、Redis 等多種數據源。配置完調度任務后，系統會自動翻譯成執行語句并生成加工任務，把事實表和維表按配置好的加速類型推到相應的計算引擎里面。

指標生產，其模型需要符合維度建模規范。創建模型時，我們希望指標的口徑全部通過維度來區分，通過修飾來實現，而不是直接把維度打到每個字段里。如果這樣做，一是無法進行靈活的分析，后續也沒有任何優化的可能性。

下面我們從整體上看看系統提供的數據加速能力。業界著名的 F1Query SQL 優化引擎，在查詢優化上非常優秀，但該優化只停留在查詢范疇上，可能會出現性能斷崖，因為物理上的極限是無法突破的，而且不可能保證穩定的快。而我們會分別從查詢和生產兩方面進行加速，查詢需要什么樣的加速數據，生產就進行該數據的生產，兩者相互配合，理論上是可以做到所有的查詢都是 O（1） 的時間復雜度。而且和傳統的預計算相比，我們的數據加速擺脫了盲目性，會根據需要進行按需加速，低頻退化，在成本上也盡量做到極致。

下面介紹查詢加速策略。

首先是合并查詢，其核心思想是盡量減少查詢次數，比如兩個同源查詢，可以通過把這些過濾條件放到指標中，通過 case when 來解決。對于非同源查詢，可以通過 union all 的方式來合并。

另一種加速方式是謂詞上拉。在 ClickHouse 中使用 arrayJoin，可能會出現性能急劇下降的情況。如果放到 prewhere 里做，就可以減少很多掃描的數據，查詢的性能可以得到大幅提升。

屬性拼接也是一種很有效果的優化。我們發現有很多維度，是沒有對其進行分析的訴求的，只是為了和其他維度一起展示使用，比如 sku 顏色，sku 尺寸等，通常只是展示 sku 信息時才會用到，很少有對其進行分析的場景。在查詢時，如果按 sku 的粒度進行分析，需要在 groupby 中加上 sku 顏色，sku 尺寸等需要的維度，這對查詢性能是巨大的挑戰。另外，如果整條數據鏈路都帶上這部分數據，勢必會造成極大的浪費。基于此，在確定沒有對這類維度進行分析的前提下，整個數據鏈路都不生產這部分數據，只根據需要在數據服務側進行結果的拼接，這樣不僅可以提升查詢效率，還可以很大程度上節約計算資源和存儲資源。

最后介紹自定義桶深的能力。我們在一些場景，如排行榜，業務方是可以通過犧牲一些精度來提升性能的。對于 Clikehouse 來說，是可以通過在本地節點對數據進行前置過濾，來減少網絡帶寬和協調節點匯總壓力，從而顯著提升查詢性能。

生產加速方面，要做到全鏈路系統化，這樣中間結果才是可知可控的，哪些中間結果是可以共用的，或者哪些不會再用可以刪掉。如果是人工來做，則完全沒有依據。只有系統化，才能從全局進行把控。目前我們在數倉資產層只有數千個規模模型，處于相對穩定的狀態。而到了應用層，就迅速擴展到了十數萬個，并且仍會以非?？斓乃俣燃ぴ觥Ｎ覀兯Ｍ氖窍裼疫叺奶菪?，通過系統化減少中間結果，讓應用層的數據盡可能地復用。

預計算是通過空間換取時間，要預計算哪些數據往往根據用戶的業務需要，如果不夠精確，會浪費大量的存儲空間。為了解決這個問題，我們開發了基于 HBO 的加速策略，用戶只需要輸入 QPS 和 TP99 等業務目標，系統會根據用戶的歷史查詢情況，自動將高頻的維度組合，時間分區等進行預計算加速，讓性能優化更加具有針對性，既滿足用戶的業務目標，又能最大化的節省存儲資源。

4. 指標治理

最后要分享的是指標治理。目前我們的數據治理工作覆蓋了從數據目錄到最后的數據展示的端到端全鏈路。在數據目錄中，對指標進行調用量監控，長期沒有調用的指標要進行指標下線，對全部指標進行質量評分；在指標定義方面，對 4W1H 里的元素有進行推薦，對同質化的指標進行監控；生產方面，對中間結果進行物化并監控其生命周期，對低頻的數據進行數據退出；數據服務方面，包括動態擴容，QPS 使用率監控，當前真正調用的 QPS 大約只占申請 QPS 的 1/3，這里有很大的優化空間；最后是數據展示方面，有很多看板，比如今年贊助春晚的一些定制大屏，以后就再也不使用了，這種低頻的要去推進它下線。

綜上，我們整體的治理目標是，口徑清晰、數據新鮮、系統高效、成本經濟。

三、應用實戰案例

1. 從指標定義到指標展示的低成本，高時效交付

上面介紹了指標中臺的很多能力，實際工作中我們是如何使用的呢？這里主要涉及上面提到的 3 類角色，分別是產品，數據開發，前端開發。對于一般復雜度的看板，每個角色只需要一名人員投入，而且全程 codeless，對技術要求的門檻比較低。產品通過指標市場查找現有指標并定義新指標，包括對應的修飾和裁剪口徑等。這部分工作 1-2 天可以完成，并把定義好的指標同時交付給數據開發和前端，并行進行數據開發和展示層開發。數據開發通過配置化指標生產，并通過加速策略滿足性能要求，這部分工作 1-3 天可以完成。前端開發通過前端低代碼平臺，也是配置化完成看板的搭建，也只需要 1-2 天即可完成。后續還有聯調和壓測等工作，順利的話 5-7 天可以交付一個高質量看板。這徹底改變數據交付模式，根據我們的統計，在戰報、大屏、黃金眼等核心數據決策場景研發成本降低 40%+，大促備戰人力下降 20%，數據需求交付效率提升 70%+。

2. 指標多端復用，口徑清晰統一

經統計，在已注冊的有效指標中，有過復用（被使用超過 1 次）的指標占比超過 50%，其中被使用最多的一些核心主題指標復用率超過 80%。以零售通用域的“成交金額”指標為例，該指標被應用在 20+ 的數據看板、系統上，保障了多端看到的數據一致性。在此基礎上開發的復合指標和子指標，與前端低代碼平臺進行高效聯動，可以完成日內的看板需求交付。

四、總結與展望

1. 成果總結

指標中臺建立兩年多來，已經成為零售指標數據的統一出口，并逐步擴展到其他 BGBU。支持零售多個核心數據產品，包括黃金眼，商智，大屏，AB 實驗等。日均調用量超過 4000W+ 次，注冊指標超過 10000。目前整體的需求覆蓋度為 55% 以上。新需求覆蓋度則可以達到 80% 以上。節省人力超過 50%。

2. 未來規劃

未來的工作主要有三個思路，即讓用戶用數用得更廣泛、更集約、更放心。

• 更廣泛用數

繼續進行能力建設，尤其是高階長尾的能力，繼續提升需求覆蓋度。

• 更集約用數

繼續提升系統化，智能化能力，基于主動元數據的數據治理覆蓋度更高，減少人力和存儲資源。

• 更放心用數

繼續提升數據和系統的穩定性，提升指標語義層質量，結合大模型降低指標查找和注冊的難度。