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

一、背景介紹

首先來介紹一下京東指標(biāo)中臺建設(shè)的背景。

1. 背景介紹-問題定義

在建設(shè)指標(biāo)中臺之前，公司內(nèi)部已經(jīng)存在指標(biāo)系統(tǒng)、指標(biāo)平臺或者類似的產(chǎn)品的，但都可以歸為"指標(biāo)登記/注冊系統(tǒng)"，這類系統(tǒng)會通常提供指標(biāo)查找，注冊等功能，希望可以達(dá)到指標(biāo)的統(tǒng)一維護(hù)，一處注冊，多處使用的效果，但因為本身的定位和架構(gòu)設(shè)計等問題，逐漸都以失敗告終。這類系統(tǒng)通常會有以下幾類問題：

（1）查找難

指標(biāo)難找的根源是定義的不夠清晰和準(zhǔn)確?！爸笜?biāo)登記系統(tǒng)”在找指標(biāo)的時候，往往只能通過一些關(guān)鍵字，例如“交易額”、“交易量”，來進(jìn)行搜索，會得到很多“相近”的結(jié)果，很難定位到最終想要的結(jié)果。存在很多“同名不同義”或“同義不同名”的指標(biāo)。

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

（2）定義難

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

（3）開發(fā)難

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

（4）使用難

由于沒有統(tǒng)一的查詢語言，每個指標(biāo)的調(diào)用方式都取決于開發(fā)團(tuán)隊，因此一個指標(biāo)想復(fù)用到另一個系統(tǒng)上就涉及重復(fù)開發(fā)，比如為大屏開發(fā)的指標(biāo)，BI 報表想復(fù)用，是無法直接復(fù)用的，需要進(jìn)行改造。

2. 背景介紹-解決思路

面對上述問題，我們把業(yè)務(wù)目標(biāo)定義為以下五點：

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

3. 定義用戶

指標(biāo)中臺是服務(wù)哪些用戶的：

• 業(yè)務(wù)師，分析師
  主要訴求是能夠清晰地獲取指標(biāo)，不太關(guān)注指標(biāo)的實現(xiàn)過程。對應(yīng)能力就是清晰的指標(biāo)目錄。
• 數(shù)據(jù)產(chǎn)品，資產(chǎn)產(chǎn)品
  負(fù)責(zé)定義指標(biāo)。對應(yīng)能力為指標(biāo)定義。
• 數(shù)據(jù)、服務(wù)開發(fā)
  負(fù)責(zé)指標(biāo)生產(chǎn)，準(zhǔn)確地實現(xiàn)指標(biāo)口徑。對應(yīng)能力為指標(biāo)開發(fā)。
• 數(shù)據(jù)消費
  準(zhǔn)確的消費數(shù)據(jù)，實現(xiàn)業(yè)務(wù)訴求。對應(yīng)能力為指標(biāo)消費。

二、指標(biāo)中臺建設(shè)

1. 整體架構(gòu)

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

2. 語義層建設(shè)

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

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

上面提到過，我們認(rèn)為定義指標(biāo)的過程，就是將業(yè)務(wù)的"自然語言"結(jié)構(gòu)化拆解的過程。而拆解規(guī)則設(shè)計得越好，指標(biāo)定義的就越準(zhǔn)確，既能保證區(qū)分度，也能保證精確度。這里的核心概念就是 4W1H，即 4 個 W 開頭的單詞，和一個 H 開頭的單詞，分別回答作用范圍，領(lǐng)域，動作，作用在誰身上，以及如何量化的問題，回答好了這幾個問題，一個原子指標(biāo)就定義好了。

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

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

在衍生指標(biāo)的基礎(chǔ)上進(jìn)行四則運算得出的新指標(biāo)，適合定義各種比率比值，可以得到復(fù)合指標(biāo)。

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

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

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

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

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

3. 指標(biāo)生產(chǎn)

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

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

如果維度是來自于維表，可以進(jìn)行關(guān)聯(lián)維表的配置。

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

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

指標(biāo)生產(chǎn)，其模型需要符合維度建模規(guī)范。創(chuàng)建模型時，我們希望指標(biāo)的口徑全部通過維度來區(qū)分，通過修飾來實現(xiàn)，而不是直接把維度打到每個字段里。如果這樣做，一是無法進(jìn)行靈活的分析，后續(xù)也沒有任何優(yōu)化的可能性。

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

下面介紹查詢加速策略。

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

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

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

最后介紹自定義桶深的能力。我們在一些場景，如排行榜，業(yè)務(wù)方是可以通過犧牲一些精度來提升性能的。對于 Clikehouse 來說，是可以通過在本地節(jié)點對數(shù)據(jù)進(jìn)行前置過濾，來減少網(wǎng)絡(luò)帶寬和協(xié)調(diào)節(jié)點匯總壓力，從而顯著提升查詢性能。

生產(chǎn)加速方面，要做到全鏈路系統(tǒng)化，這樣中間結(jié)果才是可知可控的，哪些中間結(jié)果是可以共用的，或者哪些不會再用可以刪掉。如果是人工來做，則完全沒有依據(jù)。只有系統(tǒng)化，才能從全局進(jìn)行把控。目前我們在數(shù)倉資產(chǎn)層只有數(shù)千個規(guī)模模型，處于相對穩(wěn)定的狀態(tài)。而到了應(yīng)用層，就迅速擴(kuò)展到了十?dāng)?shù)萬個，并且仍會以非常快的速度激增。我們所希望的是像右邊的梯形，通過系統(tǒng)化減少中間結(jié)果，讓應(yīng)用層的數(shù)據(jù)盡可能地復(fù)用。

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

4. 指標(biāo)治理

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

綜上，我們整體的治理目標(biāo)是，口徑清晰、數(shù)據(jù)新鮮、系統(tǒng)高效、成本經(jīng)濟(jì)。

三、應(yīng)用實戰(zhàn)案例

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

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

2. 指標(biāo)多端復(fù)用，口徑清晰統(tǒng)一

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

四、總結(jié)與展望

1. 成果總結(jié)

指標(biāo)中臺建立兩年多來，已經(jīng)成為零售指標(biāo)數(shù)據(jù)的統(tǒng)一出口，并逐步擴(kuò)展到其他 BGBU。支持零售多個核心數(shù)據(jù)產(chǎn)品，包括黃金眼，商智，大屏，AB 實驗等。日均調(diào)用量超過 4000W+ 次，注冊指標(biāo)超過 10000。目前整體的需求覆蓋度為 55% 以上。新需求覆蓋度則可以達(dá)到 80% 以上。節(jié)省人力超過 50%。

2. 未來規(guī)劃

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

• 更廣泛用數(shù)

繼續(xù)進(jìn)行能力建設(shè)，尤其是高階長尾的能力，繼續(xù)提升需求覆蓋度。

• 更集約用數(shù)

繼續(xù)提升系統(tǒng)化，智能化能力，基于主動元數(shù)據(jù)的數(shù)據(jù)治理覆蓋度更高，減少人力和存儲資源。

• 更放心用數(shù)

繼續(xù)提升數(shù)據(jù)和系統(tǒng)的穩(wěn)定性，提升指標(biāo)語義層質(zhì)量，結(jié)合大模型降低指標(biāo)查找和注冊的難度。