一、數據分析與治理面臨的挑戰

1. 數據分析與治理面臨的挑戰

企業中不同角色在數據分析和治理上面臨著不同的挑戰。

【業務視角】

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

【研發視角】

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

【組織視角】

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

2. 數據分析與治理目標

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

解決“看數難”

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

應對“人力短缺”

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

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

管控“數據無序增長”

• 業務視角的數據治理：業務方有權停用無效看板或指標，借助平臺全鏈路元數據追蹤，一次性下線關聯實體，避免遺留問題。
• 智能運維與調度：依賴生產消費日志，實現系統級智能優化，動態調整資源分配，預防計算與存儲冗余，提升整體效能。

二、數據編織在指標平臺中的落地

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

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

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

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

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

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

三、數據分析與治理技術詳解與實戰案例

1. 數據虛擬化

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

（1）邏輯表

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

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

（2）邏輯資產

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

通過邏輯表與邏輯資產的創新運用，京東零售指標服務平臺成功構建了一個集業務友好、技術先進于一體的現代化數據處理框架，為海量數據時代的企業運營提供了強有力的支持。

2. 智能加速

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

（1）指標配置化生產過程

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

• 基礎信息：綁定物理表

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

• 邏輯層配置：映射業務語言

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

• 定制加速策略：性能優化

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

• 平臺解析：從用戶配置到技術執行

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

接著，系統對事實表與維表執行聯接操作，重構數據流。這一過程將數據按需推送至預設引擎（Playhouse、HBase、Redis 或其他），由各自的數據服務組件負責后續查詢請求的處理，實現性能優化與資源高效利用。

（2）智能物化&計算優化

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

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

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

智能物化不僅簡化了用戶操作，更實現了系統自我修復與優化升級，特別是在高負載環境下，其自主調節能力尤為突出，成為保障數據服務連續性與質量的關鍵一環。

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

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

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

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

總之，智能物化通過動態任務調整與資源優化，不僅提升了數據處理效率，更促進了數據服務的整體智能化，讓系統能夠在用戶無感的狀態下，實現數據的精準管理和高效利用。

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

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

首先要提供統一 DSL 語義，這一語言規范了所有數據產品的查詢標準，涵蓋五個關鍵要素：

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

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

語義拆分后，就需要智能尋址與編排，由策略層、編排層與加速層共同構成，旨在實現數據請求的最優路徑規劃。

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

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

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

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

• 編排層：優化查詢執行路徑

編排層專注于將請求細分為可并行執行的小單位，同時探尋合并機會減少冗余操作。以貢獻率及其同比查詢為例，編排層評估是否可在同一時間段內并行執行，進而提升效率。此外，當期查詢與同期對比查詢也可探索并行可能性，避免多次往返數據庫。

• 加速層：挖掘引擎潛能

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

下面舉一個引擎優選的實例。

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

（4）指標消費-服務優化

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

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

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

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

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

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

利用上述四點優化，為數據生產鏈路和消費鏈路都帶來了顯著的性能提升。

3. 主動元數據

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

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

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

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

為強化透明度與可用性，主動元數據方案還配備了消費生產鏈路的可視化工具，直觀展現系統內外交互詳情，助力數據分析人員洞察系統行為模式，優化資源配置與策略調整，確保數據流暢通無阻，提升整體服務質量和效率。

主動元數據治理巧妙運用全局視野與動態調節，特別在復雜數據處理方面成效卓著。從數據源頭出發，即一張事實表加兩張維度表的基礎結構，系統捕捉到多個用戶分別請求生產相似但實質關聯的流量 PV 與 UV 指標，隨即啟動任務整合計劃，消除冗余作業，大幅提升效率。

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

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

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

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

四、當前進展與未來展望

1. 當前進展

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

指標調用量已達千萬級別，注冊指標逾萬，維度登記數千，配置化生產鏈路數量龐大。

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

2. 未來規劃

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

其次，優化數據加速策略，深化 HBO、RBO 等能力；

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

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

以上就是本次分享的內容，謝謝大家。

五、問答環節

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

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

Q2：如何保障在同一時間周期維度下的指標數據，在業務方于不同時間點抽取時，數據仍保持穩定，不受變動？平臺是否有相應規則主動監測此類型的問題？

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

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

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

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

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

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

Q4：如何構建高效的共享模型，實現指標復用？如何監控服務質量？

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

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

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

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

Q5：邏輯層數據存儲時間應如何設定？

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

Q6：數據處理流程中，是否優先抽提至數據倉庫再計算，若否，是否會干擾原有系統運行？

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

Q7：京東零售的數據倉庫采用了何種框架結構？

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

是否是流批一體：目前在數據中臺中數據資產的沉淀中，技術上使用了 Flink 等技術，但是目前指標服務平臺主要還是解決的離線場景，對于實時場景的資產沉淀以及邏輯層與物理層如何打通目前還在建設中。可以知道的是目前像 JMQ 這種消息隊列技術的非結構化數據以及離線數倉中的庫表的結構化數據，其與指標服務平臺邏輯層打通的技術實現方式是不同的，這塊目前是否能借助上述湖倉一體以及引入更多 OLAP 引擎（如 Doris、StarRocks 等）還在進行技術探索中。