一、數(shù)據(jù)分析與治理面臨的挑戰(zhàn)

1. 數(shù)據(jù)分析與治理面臨的挑戰(zhàn)

企業(yè)中不同角色在數(shù)據(jù)分析和治理上面臨著不同的挑戰(zhàn)。

【業(yè)務(wù)視角】

• 看數(shù)難（質(zhì)量）：數(shù)據(jù)孤島普遍存在，各數(shù)據(jù)產(chǎn)品間的同名不同義和同義不同名現(xiàn)象頻發(fā)，導(dǎo)致業(yè)務(wù)人員難以獲取一致且可靠的數(shù)據(jù)視圖，增加了理解和使用難度，阻礙高效決策。
• 提需久（效率）：需求從提出到實(shí)現(xiàn)的過程冗長繁瑣，包含多個環(huán)節(jié)，人工介入過多，嚴(yán)重影響數(shù)據(jù)分析和決策效率。

【研發(fā)視角】

• 口徑不一、運(yùn)維成本高：指標(biāo)口徑分散于多種數(shù)據(jù)源，修改指標(biāo)前需全面梳理，復(fù)雜度高，維護(hù)成本大。功能上線后常遭遇數(shù)據(jù)一致性問題，需反復(fù)核查與調(diào)試，消耗大量運(yùn)維資源。
• 人力資源不足：專業(yè)數(shù)據(jù)團(tuán)隊(duì)規(guī)模有限，難以滿足全方位需求。

【組織視角】

• 存儲冗余：數(shù)據(jù)重復(fù)存儲現(xiàn)象普遍，缺乏有效整合機(jī)制，加重了存儲負(fù)擔(dān)，尤以基礎(chǔ)信息字段為甚。
• 計(jì)算冗余：跨 BG 和 BU 的商品交易數(shù)據(jù)引發(fā)的重復(fù)計(jì)算問題凸顯，雖欲削減卻礙于數(shù)據(jù)鏈路與業(yè)務(wù)緊密相連，難以操作。計(jì)算冗余難以根除，還進(jìn)一步擠壓有限的資源空間。
• 無序的數(shù)據(jù)增長：這是數(shù)據(jù)治理的巨大障礙。本質(zhì)上，熵增原理映射出人的自然傾向——傾向于輕松狀態(tài)，如無人約束時，私人物品易雜亂無章。同樣，若無視計(jì)算與存儲成本，數(shù)據(jù)開發(fā)者可能為每項(xiàng)業(yè)務(wù)創(chuàng)建專用的 APP 表，導(dǎo)致數(shù)倉內(nèi)星型、雪花型模型混雜。數(shù)據(jù)爆炸式增長疊加重復(fù)計(jì)算/存儲，不斷惡化治理環(huán)境，威脅線上業(yè)務(wù)穩(wěn)定性。

2. 數(shù)據(jù)分析與治理目標(biāo)

我們的目標(biāo)是將傳統(tǒng)數(shù)據(jù)處理方式升級至指標(biāo)中臺模式，旨在革新數(shù)據(jù)計(jì)算與加工流程。

解決“看數(shù)難”

• 業(yè)務(wù)語言：構(gòu)建指標(biāo)定義體系，采用 4W（Who, What, Where, When）+ How + 裁剪口徑的業(yè)務(wù)化表達(dá)，確保不同人員定義相同指標(biāo)時遵循同一標(biāo)準(zhǔn)，避免多義性。
• 唯一資產(chǎn)表認(rèn)證：業(yè)務(wù)語言背后，每個指標(biāo)需技術(shù)負(fù)責(zé)人實(shí)現(xiàn)，綁定唯一資產(chǎn)表，保障數(shù)據(jù)輸出一致性（5W2H 驗(yàn)證）。
• 元素被定義及生產(chǎn)：系統(tǒng)識別業(yè)務(wù)語言中的各項(xiàng)參數(shù)，如裁剪口徑下的維度、操作符、值，自動匹配資產(chǎn)表字段，實(shí)現(xiàn)指標(biāo)自動化生產(chǎn)，無縫對接業(yè)務(wù)和技術(shù)兩端。

應(yīng)對“人力短缺”

指標(biāo)服務(wù)平臺賦能不同角色，緩解人力壓力：

• 邏輯資產(chǎn)層：釋放數(shù)據(jù)資產(chǎn)管理人力，優(yōu)化數(shù)據(jù)倉儲效率。
• 自動化生產(chǎn)：基于標(biāo)準(zhǔn)數(shù)倉表，提供一鍵加速服務(wù)，節(jié)省數(shù)據(jù)加速人力。
• 自動化服務(wù)：依據(jù)引擎特性，自動化處理加速數(shù)據(jù)，提高查詢速度，降低延遲，同時減輕數(shù)據(jù)服務(wù)團(tuán)隊(duì)負(fù)擔(dān)。
• 全鏈路系統(tǒng)化：釋放數(shù)據(jù)測試人力。

管控“數(shù)據(jù)無序增長”

• 業(yè)務(wù)視角的數(shù)據(jù)治理：業(yè)務(wù)方有權(quán)停用無效看板或指標(biāo)，借助平臺全鏈路元數(shù)據(jù)追蹤，一次性下線關(guān)聯(lián)實(shí)體，避免遺留問題。
• 智能運(yùn)維與調(diào)度：依賴生產(chǎn)消費(fèi)日志，實(shí)現(xiàn)系統(tǒng)級智能優(yōu)化，動態(tài)調(diào)整資源分配，預(yù)防計(jì)算與存儲冗余，提升整體效能。

二、數(shù)據(jù)編織在指標(biāo)平臺中的落地

接下來探討數(shù)據(jù)編織概念及其在指標(biāo)平臺中的應(yīng)用。

數(shù)據(jù)編織是一種架構(gòu)模式，旨在使可信數(shù)據(jù)能夠通過一個公共層從所有相關(guān)數(shù)據(jù)源傳送給所有相關(guān)數(shù)據(jù)使用者，從而能以高效的方式整合不同數(shù)據(jù)源。

實(shí)現(xiàn)數(shù)據(jù)編織，第一個核心技術(shù)焦點(diǎn)為數(shù)據(jù)虛擬化，指標(biāo)服務(wù)平臺通過邏輯表與邏輯資產(chǎn)構(gòu)筑業(yè)務(wù)和技術(shù)溝通的橋梁。然而，僅此不足以滿足業(yè)務(wù)方多元化的數(shù)據(jù)使用需求，因?yàn)樗麄冞€需知曉數(shù)據(jù)的具體應(yīng)用情境，例如 QPS（Query Per Second）與 DPU（Data Processing Unit）。為此，就需要第二個關(guān)鍵技術(shù)——智能加速。智能加速依托數(shù)據(jù)虛擬化，將可信數(shù)據(jù)源引入公共層，同時賦予智能加速的能力，以適應(yīng)各類引擎需求，無論離線批量處理還是實(shí)時查詢，都能游刃有余，確保用戶體驗(yàn)一致無差別。至此，看似已覆蓋大部分需求，但仍存一大隱憂——數(shù)據(jù)治理挑戰(zhàn)。

面對業(yè)務(wù)快速迭代，被動式治理顯然力不從心，僅在資源無限的理想狀態(tài)下，前述方案可行，而現(xiàn)實(shí)則不然。為此，必須引入主動數(shù)據(jù)治理，這就需要依托于主動元數(shù)據(jù)，即通過生產(chǎn)消費(fèi)血緣，提供智能退化與編排能力。

三項(xiàng)關(guān)鍵技術(shù)相互支撐，共同構(gòu)建指標(biāo)服務(wù)平臺的強(qiáng)大能力，以滿足多元化需求。在后文中將對其進(jìn)行詳細(xì)介紹。

整體架構(gòu)如下圖所示，也是圍繞以上三個關(guān)鍵詞設(shè)計(jì)的。

三、數(shù)據(jù)分析與治理技術(shù)詳解與實(shí)戰(zhàn)案例

1. 數(shù)據(jù)虛擬化

圍繞數(shù)據(jù)虛擬化這一核心概念，京東零售指標(biāo)服務(wù)平臺通過邏輯表與邏輯資產(chǎn)搭建起業(yè)務(wù)與技術(shù)溝通的橋梁，實(shí)現(xiàn)數(shù)據(jù)處理的高效與靈活。

（1）邏輯表

邏輯表作為數(shù)據(jù)虛擬化的基石，其構(gòu)成從不同角度解讀呈現(xiàn)多樣化特征。從業(yè)務(wù)視角觀察，邏輯表聚焦于所支持的指標(biāo)、維度與修飾，形成一套系統(tǒng)可識別并應(yīng)用于指標(biāo)生產(chǎn)的業(yè)務(wù)語言。從技術(shù)視角審視，邏輯表強(qiáng)調(diào)其所依賴的物理模型，無論是經(jīng) 5W2H 認(rèn)證的數(shù)倉模型或是源自邏輯模型的二次處理結(jié)果，邏輯表兼容多種數(shù)據(jù)源形式，支持任意 SQL 片段與 JOIN 操作，確保業(yè)務(wù)需求與技術(shù)實(shí)現(xiàn)的無縫銜接。

完成邏輯表定義后，平臺引入了一系列加速策略，包括介質(zhì)加速、計(jì)算加速與智能加速，以提升數(shù)據(jù)分析效能。每種加速策略生成相應(yīng)的邏輯表實(shí)現(xiàn)版本，對外表現(xiàn)為抽象層級，用戶無須深入了解，只需專注業(yè)務(wù)需求。這一設(shè)計(jì)有效簡化了用戶界面，降低了學(xué)習(xí)成本，使得技術(shù)細(xì)節(jié)對終端用戶透明，同時確保了數(shù)據(jù)服務(wù)功能的完整發(fā)揮，后續(xù)章節(jié)將詳細(xì)介紹智能尋址等高級特性。

（2）邏輯資產(chǎn)

除了邏輯表，指標(biāo)服務(wù)平臺還引入了邏輯資產(chǎn)概念，以增強(qiáng)平臺靈活性與響應(yīng)性。邏輯資產(chǎn)相比物理資產(chǎn)，最大特色在于其“無需物化”的性質(zhì)，即在滿足業(yè)務(wù)需求的同時，不必實(shí)際轉(zhuǎn)化為物理存儲。當(dāng)前平臺支持多種類型的邏輯資產(chǎn)，如基于衍生指標(biāo)構(gòu)建的復(fù)合指標(biāo)，無需單獨(dú)物化即可實(shí)現(xiàn)數(shù)學(xué)運(yùn)算；復(fù)合維度，基于基礎(chǔ)維度二次處理而成，同樣免于物化，但能滿足業(yè)務(wù)查詢要求；修飾包，處理修飾間 AND/OR 關(guān)系，無需額外物理存儲；以及邏輯模型，允許對物理模型進(jìn)行任意組合，最終輸出邏輯列及其字段類型信息，極大地提高了存儲效率。未來邏輯資產(chǎn)的種類還將繼續(xù)擴(kuò)充，以適應(yīng)更多業(yè)務(wù)場景的需求。

通過邏輯表與邏輯資產(chǎn)的創(chuàng)新運(yùn)用，京東零售指標(biāo)服務(wù)平臺成功構(gòu)建了一個集業(yè)務(wù)友好、技術(shù)先進(jìn)于一體的現(xiàn)代化數(shù)據(jù)處理框架，為海量數(shù)據(jù)時代的企業(yè)運(yùn)營提供了強(qiáng)有力的支持。

2. 智能加速

接下來通過實(shí)際案例來深度剖析邏輯表的實(shí)際應(yīng)用過程，揭示用戶如何配置邏輯表以及平臺內(nèi)部的工作原理。

（1）指標(biāo)配置化生產(chǎn)過程

用戶操作邏輯表分為三階段：基礎(chǔ)信息設(shè)置、邏輯層配置與加速策略定制。

• 基礎(chǔ)信息：綁定物理表

首先，用戶需指定邏輯表關(guān)聯(lián)的物理表，通常為 5W2H 認(rèn)證的資產(chǎn)物理表，如示例中的事實(shí)表與維表。事實(shí)表承載核心交易記錄，而維表則補(bǔ)充擴(kuò)展維度信息。通過定義關(guān)聯(lián)字段，實(shí)現(xiàn)兩表間的無縫鏈接。

• 邏輯層配置：映射業(yè)務(wù)語言

隨后，配置邏輯層，將物理字段轉(zhuǎn)化成業(yè)務(wù)術(shù)語。如 deptid 字段，標(biāo)記為部門維度；isDeal 字段代表是否成交，供后期過濾條件使用；基于 ordered 字段創(chuàng)建指標(biāo)，設(shè)定聚合方式（求和/去重），實(shí)現(xiàn)業(yè)務(wù)需求的精準(zhǔn)映射。

• 定制加速策略：性能優(yōu)化

最后，用戶需規(guī)劃加速策略，涉及加速類型、目標(biāo)數(shù)據(jù)源、庫表選擇與生命周期管理。此外，還需配置調(diào)度信息，如賬戶隊(duì)列及調(diào)度規(guī)則，確保數(shù)據(jù)服務(wù)的順暢運(yùn)行。

• 平臺解析：從用戶配置到技術(shù)執(zhí)行

用戶完成上述配置后，系統(tǒng)會進(jìn)行技術(shù)語言翻譯，將用戶配置的業(yè)務(wù)邏輯翻譯成技術(shù)指令。以指標(biāo)“通用域交易成交訂單數(shù)量”為例，系統(tǒng)捕捉其中的“成交”關(guān)鍵字，自動關(guān)聯(lián)此前綁定的成交修飾 isDeal 字段，實(shí)現(xiàn)場景特定的裁剪處理，確保數(shù)據(jù)生產(chǎn)準(zhǔn)確無誤。

接著，系統(tǒng)對事實(shí)表與維表執(zhí)行聯(lián)接操作，重構(gòu)數(shù)據(jù)流。這一過程將數(shù)據(jù)按需推送至預(yù)設(shè)引擎（Playhouse、HBase、Redis 或其他），由各自的數(shù)據(jù)服務(wù)組件負(fù)責(zé)后續(xù)查詢請求的處理，實(shí)現(xiàn)性能優(yōu)化與資源高效利用。

（2）智能物化&計(jì)算優(yōu)化

盡管用戶配置的邏輯表與加速策略足以應(yīng)對多數(shù)常規(guī)分析需求，但在特殊場景下，特別是面臨突發(fā)的大數(shù)據(jù)量沖擊時，傳統(tǒng)的手動配置顯得捉襟見肘。因此，“智能物化”應(yīng)運(yùn)而生，旨在進(jìn)一步降低使用門檻，通過自動化手段優(yōu)化數(shù)據(jù)處理效率。

傳統(tǒng)模式下，用戶需明確選擇加速類型（介質(zhì)加速或預(yù)計(jì)算）及匹配的引擎，這對數(shù)據(jù)研發(fā)人員提出了較高的專業(yè)要求，不僅要熟悉不同引擎特性，還需掌握復(fù)雜的生命周期管理。為了突破這一瓶頸，智能物化技術(shù)登場，依據(jù)歷史消費(fèi)行為與內(nèi)置規(guī)則，自動調(diào)整加速策略，從而將決策重點(diǎn)從“類型+引擎”轉(zhuǎn)移到更具意義的性能指標(biāo)（如 QPS、TP99）上。

設(shè)想一下，原本平穩(wěn)運(yùn)行的系統(tǒng)遭遇電商大促高峰，數(shù)據(jù)吞吐量激增，原本 500 毫秒響應(yīng)時間驟然延長至兩秒，嚴(yán)重影響用戶體驗(yàn)。若缺乏智能物化，用戶需自行診斷問題、詢問專家并手動調(diào)整預(yù)計(jì)算策略，耗時費(fèi)力。相反，智能物化機(jī)制能敏銳捕捉性能下降信號，基于消費(fèi)數(shù)據(jù)變化趨勢，自動觸發(fā)向 HBase 引擎遷移的加速措施，即時恢復(fù)高效服務(wù)，無需人工干預(yù)。

智能物化不僅簡化了用戶操作，更實(shí)現(xiàn)了系統(tǒng)自我修復(fù)與優(yōu)化升級，特別是在高負(fù)載環(huán)境下，其自主調(diào)節(jié)能力尤為突出，成為保障數(shù)據(jù)服務(wù)連續(xù)性與質(zhì)量的關(guān)鍵一環(huán)。

讓我們通過具體案例深入探討智能物化如何優(yōu)化數(shù)據(jù)處理流程。假設(shè)初始配置僅包含從 Hive 到 ClickHouse 的介質(zhì)加速任務(wù)，在理想情況下，此任務(wù)于凌晨 5 點(diǎn)啟動，僅需 8 分鐘即可完成，消耗 15C 的計(jì)算資源。然而，若同步發(fā)起 Hive 到 HBase 的預(yù)計(jì)算加速，考慮到早高峰期間 Hive 資源緊張及復(fù)雜計(jì)算需求，預(yù)計(jì)耗時長達(dá)兩小時，需投入 350C 資源方能于 7 點(diǎn)結(jié)束。

此時，智能物化展現(xiàn)出卓越的調(diào)度智慧。鑒于 ClickHouse 主要用于支撐在線查詢，且清晨時段用戶活躍度較低，系統(tǒng)充分利用 ClickHouse 空閑資源，于 5:08 分開始執(zhí)行額外計(jì)算，僅需 20 分鐘與 3C 資源便告完成。由此，原本單一的 Hive 至 HBase 加速路徑被智能優(yōu)化為 Hive 至 ClickHouse，繼而從 ClickHouse 至 HBase 的雙重路線。

如此一來，盡管用戶初衷僅為 Hive 至 ClickHouse 的加速，智能物化卻巧妙調(diào)整任務(wù)序列，最終形成了 Hive 至 ClickHouse，疊加 ClickHouse 至 HBase 的復(fù)合方案。結(jié)果是，系統(tǒng)在 CK 與 HBase 中各備一份數(shù)據(jù)副本，分別對應(yīng)兩種邏輯表實(shí)現(xiàn)——這一切對用戶完全透明，他們僅需關(guān)注業(yè)務(wù)層面的指標(biāo)、維度與修飾。

值得注意的是，智能物化過程中引入的物化類型（如明細(xì)或預(yù)計(jì)算）、支持時間范圍、引擎選擇（PlayCost/HBase 等）、分流策略與任務(wù)依賴等參數(shù)，雖不在原始邏輯表范疇之內(nèi)，卻是邏輯表實(shí)現(xiàn)不可或缺的部分。這些細(xì)化屬性，尤其是物化類型與時間范圍，對于確保數(shù)據(jù)時效性與準(zhǔn)確性至關(guān)重要，同時也是智能尋址算法的核心參考，使系統(tǒng)能在繁復(fù)的數(shù)據(jù)網(wǎng)中迅速定位所需信息，實(shí)現(xiàn)高效數(shù)據(jù)交付。

總之，智能物化通過動態(tài)任務(wù)調(diào)整與資源優(yōu)化，不僅提升了數(shù)據(jù)處理效率，更促進(jìn)了數(shù)據(jù)服務(wù)的整體智能化，讓系統(tǒng)能夠在用戶無感的狀態(tài)下，實(shí)現(xiàn)數(shù)據(jù)的精準(zhǔn)管理和高效利用。

（3）指標(biāo)消費(fèi)-尋址與編排

面對復(fù)雜的數(shù)據(jù)查詢需求，通過智能尋址與編排連接用戶需求與數(shù)據(jù)源，確保每一次數(shù)據(jù)訪問都能得到高效且精準(zhǔn)的響應(yīng)。

首先要提供統(tǒng)一 DSL 語義，這一語言規(guī)范了所有數(shù)據(jù)產(chǎn)品的查詢標(biāo)準(zhǔn)，涵蓋五個關(guān)鍵要素：

• 指標(biāo)：定義了查詢中所需的特定量化信息；
• 聚合條件：維度路徑，用于數(shù)據(jù)切片，以便按類別細(xì)分；
• 篩選條件：設(shè)定查詢限制，精確獲取符合條件的數(shù)據(jù)項(xiàng)；
• 維度屬性：附加于主維度之上，豐富數(shù)據(jù)描述，如商品顏色、尺碼等；
• 數(shù)據(jù)組織：指明結(jié)果排序與分頁方式。

以數(shù)據(jù)看板 A 為例，其請求包含部門等于“3C”維度下的數(shù)據(jù)，并涉及復(fù)合指標(biāo)（用戶成交貢獻(xiàn)率、貢獻(xiàn)率同比）與衍生指標(biāo)（有效用戶數(shù)、成交用戶數(shù)）。統(tǒng)一 DSL 層將復(fù)合指標(biāo)分解為基本單元，便于后續(xù)處理。

語義拆分后，就需要智能尋址與編排，由策略層、編排層與加速層共同構(gòu)成，旨在實(shí)現(xiàn)數(shù)據(jù)請求的最優(yōu)路徑規(guī)劃。

• 策略層：尋找最佳服務(wù)提供者

首要任務(wù)是確定哪項(xiàng)數(shù)據(jù)服務(wù)最適合響應(yīng)特定指標(biāo)查詢。鑒于各類數(shù)據(jù)服務(wù)覆蓋的指標(biāo)范圍各異，策略層需精確定位。

例如，用戶數(shù)據(jù)服務(wù)專攻用戶相關(guān)指標(biāo)，交易數(shù)據(jù)服務(wù)則聚焦于交易領(lǐng)域。有時，同一指標(biāo)會被多個數(shù)據(jù)服務(wù)覆蓋，區(qū)別在于預(yù)計(jì)算程度的不同，如 HBase 側(cè)重預(yù)計(jì)算，ClickHouse 則偏向明細(xì)數(shù)據(jù)，導(dǎo)致 QPS 表現(xiàn)差異明顯。

策略制定需兼顧多種考量，如離在線轉(zhuǎn)換策略、負(fù)載均衡等。以數(shù)據(jù)量大小為例，大量數(shù)據(jù)檢索傾向于離線服務(wù)，小額快速查詢則偏好在線實(shí)時服務(wù)。

• 編排層：優(yōu)化查詢執(zhí)行路徑

編排層專注于將請求細(xì)分為可并行執(zhí)行的小單位，同時探尋合并機(jī)會減少冗余操作。以貢獻(xiàn)率及其同比查詢?yōu)槔?，編排層評估是否可在同一時間段內(nèi)并行執(zhí)行，進(jìn)而提升效率。此外，當(dāng)期查詢與同期對比查詢也可探索并行可能性，避免多次往返數(shù)據(jù)庫。

• 加速層：挖掘引擎潛能

加速層致力于確保每次查詢獲得最優(yōu)化執(zhí)行。這包括但不限于引擎選擇、利用引擎特性（如謂詞上推、謂詞下拉等）進(jìn)行查詢優(yōu)化，以及緩存策略部署。通過精細(xì)調(diào)控，加速層最大限度地縮短響應(yīng)時間，提升查詢性能。

下面舉一個引擎優(yōu)選的實(shí)例。

用戶在 10 月 4 日 6 時提出了一個查詢成交金額的請求，最初僅有 ClickHouse 明細(xì)數(shù)據(jù)支持，隨著數(shù)據(jù)量激增導(dǎo)致查詢延遲增加，智能物化機(jī)制觸發(fā) Hive 至 HBase 的預(yù)計(jì)算任務(wù)，以緩解壓力。然而，預(yù)計(jì)算任務(wù) SLA 設(shè)為次日早晨 7 點(diǎn)，意味著當(dāng)日查詢?nèi)孕杌旌鲜褂妙A(yù)計(jì)算與明細(xì)數(shù)據(jù)。假設(shè)進(jìn)一步優(yōu)化至 ClickHouse 至 HBase 路徑，SLA 提前至 5 點(diǎn) 28 分，再次相同請求時，全部數(shù)據(jù)已預(yù)先計(jì)算完畢，查詢效率顯著提高。

（4）指標(biāo)消費(fèi)-服務(wù)優(yōu)化

指標(biāo)消費(fèi)加速的第二個場景是服務(wù)優(yōu)化，核心目標(biāo)是大幅提升指標(biāo)服務(wù)的效率與資源利用率，可實(shí)現(xiàn) 5 倍效能躍升，同時縮減列式存儲占用。

假定查詢需求為兩項(xiàng)指標(biāo)——3C 類別的訂單數(shù)量和訂單金額。在未優(yōu)化狀態(tài)下，通常做法是從同一基礎(chǔ)表格提取數(shù)據(jù)，生成兩個 SQL，各自計(jì)算后合并得出結(jié)果。

我們采取了一系列優(yōu)化措施。首先，同源模型合并，基于兩個指標(biāo)源于同一數(shù)據(jù)模型的事實(shí)，系統(tǒng)在構(gòu)建查詢語句時，將它們整合成一個 SQL，顯著降低了處理負(fù)擔(dān)。

第二個優(yōu)化是謂詞下推，即在 SELECT 語句中嵌入的條件被下沉至子查詢層面，促使子查詢先行執(zhí)行數(shù)據(jù)過濾，同時僅保留必需字段，而非加載整個數(shù)據(jù)集，極大地提升了數(shù)據(jù)檢索速度。

第三項(xiàng)優(yōu)化是屬性跟隨，旨在精簡查詢過程中的冗余步驟。具體而言，用戶真正需求往往是商品 ID（sku_id）與其對應(yīng)的中文名稱（sku_name）。傳統(tǒng)方法中，為呈現(xiàn) sku_name，查詢語句會連帶加載該屬性，無形中增加了計(jì)算成本。鑒于 sku_name 實(shí)為 sku_id 的一個屬性，系統(tǒng)引入了專門的維度屬性數(shù)據(jù)服務(wù)，負(fù)責(zé)補(bǔ)充缺失的 sku_name 信息，這意味著底層表格與 SQL 可以安全移除 sku_name 字段，既節(jié)省了存儲空間，又加速了查詢進(jìn)程。

最后是優(yōu)化復(fù)合維度。用戶往往期望獲取更細(xì)致的數(shù)據(jù)分類，如商品單價層級劃分——高于 100 元?dú)w為“high_price_level”，反之則為“l(fā)ow_price_level”。以往，此類需求需通過物理表預(yù)處理，即將價格層級標(biāo)簽物化存儲，再經(jīng) GROUP BY 操作篩選輸出。然而，借助復(fù)合維度技術(shù)，這一繁瑣過程得以簡化。復(fù)合維度允許直接在物理表的價格字段上應(yīng)用邏輯判斷，即時生成所需層級，無需額外的物化步驟。這種方法幾乎不影響查詢性能，因其邏輯處理開銷極低。這樣，系統(tǒng)能實(shí)時響應(yīng)用戶對多層次數(shù)據(jù)的需求，還能顯著降低存儲成本。

利用上述四點(diǎn)優(yōu)化，為數(shù)據(jù)生產(chǎn)鏈路和消費(fèi)鏈路都帶來了顯著的性能提升。

3. 主動元數(shù)據(jù)

Denodo 公司對主動元數(shù)據(jù)的定義為：使用歷史經(jīng)過適當(dāng)處理和總結(jié)，便可作為傳統(tǒng)元數(shù)據(jù)的自然延伸。在京東零售指標(biāo)服務(wù)體系中，這一理論具體為，依托于動態(tài)的消費(fèi)、生產(chǎn)元數(shù)據(jù)，自動物化、退化指標(biāo)生產(chǎn)和消費(fèi)鏈路，主動進(jìn)行元數(shù)據(jù)的動態(tài)迭代。

具體而言，即便在用戶無須介入的場景下，如促銷活動引發(fā)查詢響應(yīng)時間從 500 毫秒延長至兩秒，系統(tǒng)可通過主動元數(shù)據(jù)管理，智能分析并預(yù)測性能瓶頸，進(jìn)而自主優(yōu)化，例如通過增強(qiáng)預(yù)算分配、智能尋址等手段，將響應(yīng)時間壓縮回甚至優(yōu)于原先水平，達(dá)至 100 毫秒級別。此舉不僅顯著改善用戶體驗(yàn)，更在后臺無聲運(yùn)轉(zhuǎn)中，保持系統(tǒng)的活力與效率，體現(xiàn)主動元數(shù)據(jù)在維護(hù)數(shù)據(jù)健康生態(tài)方面的潛在價值。

主動元數(shù)據(jù)的技術(shù)架構(gòu)概覽揭示了其運(yùn)作機(jī)制的核心組件及流程。架構(gòu)設(shè)計(jì)中，元數(shù)據(jù)目錄有靜態(tài)與動態(tài)兩大類型，涵蓋了指標(biāo)、維度、邏輯表、實(shí)現(xiàn)集群配置等一系列關(guān)鍵元素，輔以修飾符、維表等輔助信息，構(gòu)成了豐富的元數(shù)據(jù)生態(tài)系統(tǒng)。這些數(shù)據(jù)首先在元數(shù)據(jù)中心接受自檢，而后由指標(biāo)服務(wù)平臺內(nèi)部各子系統(tǒng)匯總上傳。

動態(tài)元數(shù)據(jù)的生成依賴于決策引擎與消費(fèi)、生產(chǎn)鏈路的日志上報(bào)機(jī)制，詳盡記錄了生產(chǎn)活動的時間、實(shí)例選擇、運(yùn)行周期，以及消費(fèi)端的指標(biāo)調(diào)用頻次、目標(biāo)集群及時延情況。此外，集群資源的 CPU 和內(nèi)存消耗也成為監(jiān)測重點(diǎn)。這些動態(tài)反饋為決策引擎提供了智能物化、退化與編排決策的依據(jù)，同時消費(fèi)數(shù)據(jù)的 Hive 存儲促進(jìn)了系統(tǒng)自我學(xué)習(xí)與優(yōu)化循環(huán)。

為強(qiáng)化透明度與可用性，主動元數(shù)據(jù)方案還配備了消費(fèi)生產(chǎn)鏈路的可視化工具，直觀展現(xiàn)系統(tǒng)內(nèi)外交互詳情，助力數(shù)據(jù)分析人員洞察系統(tǒng)行為模式，優(yōu)化資源配置與策略調(diào)整，確保數(shù)據(jù)流暢通無阻，提升整體服務(wù)質(zhì)量和效率。

主動元數(shù)據(jù)治理巧妙運(yùn)用全局視野與動態(tài)調(diào)節(jié)，特別在復(fù)雜數(shù)據(jù)處理方面成效卓著。從數(shù)據(jù)源頭出發(fā)，即一張事實(shí)表加兩張維度表的基礎(chǔ)結(jié)構(gòu)，系統(tǒng)捕捉到多個用戶分別請求生產(chǎn)相似但實(shí)質(zhì)關(guān)聯(lián)的流量 PV 與 UV 指標(biāo)，隨即啟動任務(wù)整合計(jì)劃，消除冗余作業(yè)，大幅提升效率。

面對 27 個月歷史數(shù)據(jù)的海量生產(chǎn)需求，初試用一個任務(wù)全包攬的策略遇挫，表現(xiàn)為頻繁故障與資源緊繃。隨后，采用按月分解任務(wù)的方式，均衡分布壓力。期間，元數(shù)據(jù)管理系統(tǒng)擔(dān)當(dāng)重任，綜合考量各項(xiàng)參數(shù)，包括任務(wù)量級、集群碎片狀態(tài)和單碎片承載量，實(shí)現(xiàn)定制化優(yōu)化。

另一重要能力是算力感知，在涉及多集群協(xié)作時表現(xiàn)突出。遇到某個集群負(fù)荷過載，系統(tǒng)能迅速轉(zhuǎn)向輕載集群執(zhí)行數(shù)據(jù)生產(chǎn)，再通過集群同步分享成果，既避開擁堵瓶頸，又能挖掘集群間協(xié)同潛力，全面提升系統(tǒng)效能。算力感知遠(yuǎn)不止監(jiān)控集群概況，還精細(xì)至 CPU 和內(nèi)存使用狀況，確保資源分配準(zhǔn)確及時。

下圖是主動元數(shù)據(jù)生產(chǎn)消費(fèi)血緣的全景展示，可以看到指標(biāo)如何服務(wù)于哪些看板，還深度解析了指標(biāo)生成路徑，追溯至數(shù)據(jù)服務(wù)、ClickHouse 表、Hive 表，揭示了完整的血緣鏈路。

可視化工具有助于明確每個生產(chǎn)任務(wù)及其決策點(diǎn)在系統(tǒng)中的流動軌跡，便于快速定位故障原因，向用戶提供詳盡指引，確保數(shù)據(jù)流程透明可控。

四、當(dāng)前進(jìn)展與未來展望

1. 當(dāng)前進(jìn)展

當(dāng)前，服務(wù)平臺在定義即生產(chǎn)鏈路上已廣泛服務(wù)于五大業(yè)務(wù)群組，跨越十余個部門，需求覆蓋率超 50%，并成功支持如黃金衍生品等高級數(shù)據(jù)產(chǎn)品。經(jīng)受住了大促、跨晚、春晚等重大事件考驗(yàn)。

指標(biāo)調(diào)用量已達(dá)千萬級別，注冊指標(biāo)逾萬，維度登記數(shù)千，配置化生產(chǎn)鏈路數(shù)量龐大。

指標(biāo)復(fù)用率達(dá) 40%，效率提升 50%，自動化生產(chǎn)鏈路節(jié)省 20% 的離在線存儲、計(jì)算資源。

2. 未來規(guī)劃

首要任務(wù)在于拓展業(yè)務(wù)場景，探索離線在線一體化分析、A/B 測試、個性化分析等領(lǐng)域；

其次，優(yōu)化數(shù)據(jù)加速策略，深化 HBO、RBO 等能力；

第三，增強(qiáng)主動治理，引入智能生命周期管理，完善 CBO 能力，強(qiáng)化主動元數(shù)據(jù)治理；

最后，持續(xù)改進(jìn)用戶體驗(yàn)，打造更加友好高效的服務(wù)界面，利用大模型助力用戶智能數(shù)據(jù)分析。

以上就是本次分享的內(nèi)容，謝謝大家。

五、問答環(huán)節(jié)

Q1：在邏輯層，每次計(jì)算后的結(jié)果會被緩存嗎？緩存多久？

A1：邏輯表中主要是分為三個部分：1. 業(yè)務(wù)語義層，即代表該邏輯表支持的指標(biāo)、維度等信息；2. 物理模型層：如離線數(shù)倉場景下的 Hive 表，以及邏輯模型（比如 Hive 視圖）；3. 加速層，即可以配置針對于不同數(shù)分場景下的加速策略（如 tp99 要求高的和 tp99 要求低的，其可以配置不同的數(shù)據(jù)加速策略以使用不同的成本滿足不同的業(yè)務(wù)訴求）；我理解上述問題主要涉及到的是第三部分，先回答數(shù)據(jù)加速結(jié)果不是存儲到緩存中（這里的緩存主要指的是數(shù)據(jù)服務(wù)鏈路使用的緩存，比如 Redis、服務(wù)內(nèi)存等），而是實(shí)際沉淀到 OLAP 層（或者 KV 數(shù)據(jù)庫），以不同的生命周期將數(shù)據(jù)沉淀下來（當(dāng)然這部分?jǐn)?shù)據(jù)也可以配合數(shù)據(jù)服務(wù)的緩存一起使用）。這個生命周期在不同場景下的時間是不同的，但是核心的設(shè)計(jì)原則是：用空間去換時間時，不能存在無效的空間浪費(fèi)（計(jì)算和存儲）。比如在電商場景中，往往有大促周期的說法，對于數(shù)分場景而言，某個指標(biāo)（如成交金額），在非大促周期內(nèi)的 tp99 可以是 2s，但是在大促周期的 tp99 需要在 500ms 以內(nèi)，這種就可以通過在同一個邏輯表內(nèi)設(shè)置兩個加速策略去完成，大促時間段可以配置成預(yù)計(jì)算策略，且生命周期為大促時間段，其余非大促時間段的為明細(xì)數(shù)據(jù)。當(dāng)然實(shí)際場景肯定比該場景更加復(fù)雜，但是核心原則還是上述的原則。

Q2：如何保障在同一時間周期維度下的指標(biāo)數(shù)據(jù)，在業(yè)務(wù)方于不同時間點(diǎn)抽取時，數(shù)據(jù)仍保持穩(wěn)定，不受變動？平臺是否有相應(yīng)規(guī)則主動監(jiān)測此類型的問題？

A2：針對第一個問題，即如何保證數(shù)據(jù)一致性，在離線場景下，指標(biāo)服務(wù)平臺通過限定指標(biāo)定義必須源自單一邏輯資產(chǎn)表的方式，有效避免了數(shù)據(jù)變動問題。這意味著，只要上游數(shù)據(jù)未經(jīng)歷重刷，不論何時查詢，數(shù)據(jù)都將始終保持一致，因?yàn)樗兄笜?biāo)產(chǎn)出均直接關(guān)聯(lián)至這張核心表，確保了“定義即生產(chǎn)”的原則得到貫徹執(zhí)行。雖然數(shù)據(jù)加速措施可能會帶來性能表現(xiàn)上的差異，但在質(zhì)量層面則不存在問題。即便面對相同長期請求，系統(tǒng)響應(yīng)快慢有別，卻不會造成數(shù)據(jù)品質(zhì)的參差，歸功于始終依據(jù)同一張資產(chǎn)表進(jìn)行處理。

在上述原則下，我們還遇到了一些數(shù)據(jù)質(zhì)量的問題，主要遇到兩種情況：1. 數(shù)據(jù)不準(zhǔn)導(dǎo)致的歷史數(shù)據(jù)的回刷，主要集中在離線場景；2. 數(shù)據(jù)延遲導(dǎo)致的結(jié)果變化，只要體現(xiàn)在實(shí)時、準(zhǔn)實(shí)時場景。

針對上述第一種情況，其本質(zhì)上還是【數(shù)據(jù)不準(zhǔn)系統(tǒng)如何發(fā)現(xiàn)的問題】，目前指標(biāo)服務(wù)中采用的核心原則是：默認(rèn)用戶知道準(zhǔn)確的數(shù)據(jù)應(yīng)該長什么樣（即一個指標(biāo)的技術(shù)負(fù)責(zé)人，能知道指標(biāo)的數(shù)據(jù)在什么情況下是不對的），為此，指標(biāo)服務(wù)平臺目前提供了指標(biāo)巡檢的能力，可以讓用戶為不同的指標(biāo)*維度路徑*時間周期去配置預(yù)期值，并輔以一些規(guī)則，如不為 0、數(shù)據(jù)范圍、同比環(huán)比等。但是在這期間也發(fā)現(xiàn)了一些問題，如每年的京東促銷活動、天氣變化等都會影響到指標(biāo)的數(shù)據(jù)，這部分的內(nèi)容目前無法被監(jiān)測，就會導(dǎo)致巡檢的準(zhǔn)確率問題。所以目前指標(biāo)服務(wù)平臺也在積極建設(shè)這塊元數(shù)據(jù)能力。此外，指標(biāo)的定義與生產(chǎn)都在指標(biāo)服務(wù)平臺，那么平臺是否有能力識別其業(yè)務(wù)語義并進(jìn)行指標(biāo)的結(jié)果驗(yàn)證？（如預(yù)測能力，數(shù)理統(tǒng)計(jì)相關(guān)能力），目前指標(biāo)服平臺也在積極探索中。

針對上述第二種情況，這塊本質(zhì)上數(shù)據(jù)其實(shí)沒有問題，所以核心還是在于產(chǎn)品級的預(yù)期控制。指標(biāo)服務(wù)平臺與集團(tuán)內(nèi)的 BDP 系統(tǒng)有元信息層面的打通，具備離線、準(zhǔn)實(shí)時任務(wù)的 SLA 信息，將這部分內(nèi)容與端上用戶的產(chǎn)品體驗(yàn)結(jié)合，可以在一定程度上減少用戶的使用體驗(yàn)。

Q3：京東零售在數(shù)據(jù)服務(wù)領(lǐng)域的改造升級，對其他企業(yè)而言，學(xué)習(xí)門檻和實(shí)施成本如何評估？

A3：京東零售內(nèi)部正在經(jīng)歷的數(shù)據(jù)服務(wù)體系轉(zhuǎn)型，旨在克服以往煙囪式開發(fā)架構(gòu)帶來的挑戰(zhàn)。采取的是漸進(jìn)式遷移策略，借助自主研發(fā)的數(shù)據(jù)服務(wù)平臺，該平臺具備承載歷史版指標(biāo)的功能，允許新舊體系間的平穩(wěn)過渡。在遷移過程中，只需添加特定標(biāo)簽，即可無縫對接自動化生產(chǎn)流程，確保前后一致性，簡化了調(diào)用方式變更的驗(yàn)證過程，配合自動化映射工具，確保遷移順暢。

Q4：如何構(gòu)建高效的共享模型，實(shí)現(xiàn)指標(biāo)復(fù)用？如何監(jiān)控服務(wù)質(zhì)量？

A4：指標(biāo)服務(wù)平臺的宗旨之一就是：指標(biāo)復(fù)用。即相同業(yè)務(wù)口徑的數(shù)據(jù)應(yīng)該由統(tǒng)一的模型給出獨(dú)一份的計(jì)算口徑，不同的業(yè)務(wù)方共享相同的指標(biāo)口徑以解決【對數(shù)難】的問題。還是以離線數(shù)倉為例，成交 GMV 指標(biāo)的口徑定義只能被一張 Hive 物理表定義，但是服務(wù)的業(yè)務(wù)方可以是多個，比如集團(tuán)內(nèi)的不同數(shù)據(jù)產(chǎn)品、BI 工具等，這里面數(shù)據(jù)的開放與共享主要涉及到兩大問題：1. 權(quán)限；2. 資源。

1. 針對權(quán)限問題，主要集中于離線計(jì)算的庫表權(quán)限，以及在線分析場景的指標(biāo)權(quán)限。針對前者，京東在內(nèi)部的大數(shù)據(jù)平臺中已經(jīng)有一套針對 ERP、生產(chǎn)賬號、集市、庫表的權(quán)限管控機(jī)制，目前指標(biāo)服務(wù)是直接復(fù)用的。而對于后者，在指標(biāo)消費(fèi)時，指標(biāo)服務(wù)平臺有自己的一套數(shù)據(jù)權(quán)限管控機(jī)制。主要是調(diào)用方*指標(biāo)*服務(wù)方粒度，可以簡單理解為：調(diào)用方就是不同的頁面、菜單；服務(wù)方就是不同的 OLAP 集群。

2.資源：資源層面也主要包含離線的計(jì)算資源以及在線分析的數(shù)據(jù)服務(wù) OLAP 引擎資源。目前離線資源方面跟公司的大數(shù)據(jù)平臺也是打通的，復(fù)用生產(chǎn)賬號、隊(duì)列、調(diào)度節(jié)點(diǎn)等資源管控機(jī)制。而針對后者，指標(biāo)服務(wù)也提供調(diào)用方*指標(biāo)*服務(wù)方級別的限流、熔斷、緩存等措施，以保護(hù)服務(wù)方的資源使用。

關(guān)于如何監(jiān)督服務(wù)質(zhì)量：這塊我理解主要還是需要回答指標(biāo)的質(zhì)量問題以及后續(xù)的數(shù)據(jù)治理問題。指標(biāo)的質(zhì)量當(dāng)然也包含這個指標(biāo)的數(shù)據(jù)服務(wù)的質(zhì)量（比如 QPS 和 tp99），目前指標(biāo)的質(zhì)量主要集中在復(fù)用度以及服務(wù)質(zhì)量：調(diào)用方、調(diào)用頻次、tp99、QPS。如果我們發(fā)現(xiàn)某個指標(biāo)的質(zhì)量較差，那么就會觸發(fā)指標(biāo)下線的流程，在流程中會觸發(fā)指標(biāo)的全鏈路生產(chǎn)以及服務(wù)鏈路的資源釋放（當(dāng)然這么做的前提條件是指標(biāo)服務(wù)平臺的主動元數(shù)據(jù)的基礎(chǔ)設(shè)施能力）。打通指標(biāo)的生產(chǎn)和消費(fèi)全鏈路血緣。實(shí)現(xiàn)一站式得數(shù)據(jù)治理。

Q5：邏輯層數(shù)據(jù)存儲時間應(yīng)如何設(shè)定？

A5：邏輯層的存儲時間并非固定，而是根據(jù)數(shù)據(jù)的實(shí)際使用狀況動態(tài)調(diào)整。在數(shù)據(jù)加工鏈路中，預(yù)計(jì)算策略生成的中間表（智能物化）將在完成數(shù)據(jù)校驗(yàn)后自動清理，確保資源高效利用。存儲時長實(shí)質(zhì)反映的是數(shù)據(jù)的有效期，直至消費(fèi)完畢即按需清除，體現(xiàn)緩存性質(zhì)，既加速數(shù)據(jù)處理，又保護(hù)任務(wù)執(zhí)行連續(xù)性。

Q6：數(shù)據(jù)處理流程中，是否優(yōu)先抽提至數(shù)據(jù)倉庫再計(jì)算，若否，是否會干擾原有系統(tǒng)運(yùn)行？

A6：目前指標(biāo)服務(wù)的離線數(shù)倉場景都是會先抽取到數(shù)倉之后再計(jì)算的。實(shí)時鏈路目前指標(biāo)加速部分尚未接入到指標(biāo)服務(wù)平臺，不過從數(shù)據(jù)計(jì)算的角度，原則上肯定也不會因?yàn)橹笜?biāo)加速鏈路去影響到生產(chǎn)系統(tǒng)，可以通過 MQ+Flink 等技術(shù)架構(gòu)去實(shí)現(xiàn)。具體這塊的實(shí)現(xiàn)有些復(fù)雜，這里不做詳細(xì)描述。

Q7：京東零售的數(shù)據(jù)倉庫采用了何種框架結(jié)構(gòu)？

A7：目前尚未做到湖倉一體：主要還是解決離線數(shù)倉的場景。但是數(shù)據(jù)湖提供的是統(tǒng)一的數(shù)據(jù)訪問層，簡化數(shù)據(jù)管理和分析（支持結(jié)構(gòu)化與半結(jié)構(gòu)化方式），其數(shù)據(jù)的元信息與離線數(shù)倉的較為類似，目前我們正在打通 POC 數(shù)據(jù)鏈路，通過將邏輯表（業(yè)務(wù)元數(shù)據(jù)）與統(tǒng)一的湖倉一體的技術(shù)元數(shù)據(jù)打通，解決數(shù)倉集市中的數(shù)據(jù)孤島與數(shù)據(jù)整合問題。

是否是流批一體：目前在數(shù)據(jù)中臺中數(shù)據(jù)資產(chǎn)的沉淀中，技術(shù)上使用了 Flink 等技術(shù)，但是目前指標(biāo)服務(wù)平臺主要還是解決的離線場景，對于實(shí)時場景的資產(chǎn)沉淀以及邏輯層與物理層如何打通目前還在建設(shè)中?？梢灾赖氖悄壳跋?JMQ 這種消息隊(duì)列技術(shù)的非結(jié)構(gòu)化數(shù)據(jù)以及離線數(shù)倉中的庫表的結(jié)構(gòu)化數(shù)據(jù)，其與指標(biāo)服務(wù)平臺邏輯層打通的技術(shù)實(shí)現(xiàn)方式是不同的，這塊目前是否能借助上述湖倉一體以及引入更多 OLAP 引擎（如 Doris、StarRocks 等）還在進(jìn)行技術(shù)探索中。