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

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

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

【業(yè)務視角】

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

【研發(fā)視角】

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

【組織視角】

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

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

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

解決“看數(shù)難”

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

應對“人力短缺”

指標服務平臺賦能不同角色，緩解人力壓力：

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

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

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

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

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

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

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

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

三項關鍵技術(shù)相互支撐，共同構(gòu)建指標服務平臺的強大能力，以滿足多元化需求。在后文中將對其進行詳細介紹。

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

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

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

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

（1）邏輯表

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

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

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

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

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

2. 智能加速

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

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

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

• 基礎信息：綁定物理表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）指標消費-尋址與編排

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

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

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

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

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

• 策略層：尋找最佳服務提供者

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

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

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

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

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

• 加速層：挖掘引擎潛能

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

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

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

（4）指標消費-服務優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、當前進展與未來展望

1. 當前進展

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

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

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

2. 未來規(guī)劃

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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è)務元數(shù)據(jù)）與統(tǒng)一的湖倉一體的技術(shù)元數(shù)據(jù)打通，解決數(shù)倉集市中的數(shù)據(jù)孤島與數(shù)據(jù)整合問題。

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