京東零售資料資產能力升級與實踐

開篇
京東自營和商家自運營模式，以及伴隨的多種運營視角、多種組合計算、多種銷售屬性等資料維度，相較於行業同等量級，資料處理的難度與複雜度都顯著增加。如何從海量的資料模型與資料指標中提升檢索資料的效率，降低資料存算的成本，提供更可信的資料內容和多種應用模式快速支撐業務的資料決策與分析，是資料團隊去年聚焦解決的核心課題。

過程中基於 RBO、HBO 等多級加速引擎、基於代價與場景消費的智慧物化策略、基於 One Metric 的異構融合服務、基於 One Logic 語義層的離近線上轉換以及基於圖形語法和多端一體的視覺化工具，聯合 GPT 技術的智慧問答系統 chatBI，顯著提升業務數字化決策效率，過程中也沉澱了多篇軟著與多項技術專利。對於多級加速引擎與智慧物化策略，行業普遍採用 cube 預計算 + 快取模式，京東創新性落地了基於主動後設資料的口徑定義以及基於資料消費場景與消費頻次的正負反饋動態決策，確保整個資料鏈路的存算分配 “當下最優”，同時相較於粗粒度的物化策略，模型生命週期參考儲存代價配置，資料查詢鏈路根據 RT 表現動態定址，這樣使得資料生產與資料消費形成互動反饋鏈路，決策依據更加豐富，決策粒度更加精準。

基於圖形語法和多端一體的視覺化能力打造層面，京東 JMT 資料視覺化能力可以依託底層指標中臺快速進行智慧診斷與歸因，相較於 tableau 等頭部解決方案，融入了更多圖形語法同時可靈活適配多端多場景。

結合 AIGC 技術的智慧問答系統 chatBI，基於業務知識與資料資產的 Prompt 工程，使用本地大模型 SFT 對實體進行 embedding，透過指標統一 DSL 取代了行業普遍 NL2SQL 的解決方案，很好解決了人為意識到資料語言的轉換難題，所消耗晶片規模也顯著優於行業水平，在資料智慧分析診斷系統裡準確率大幅領先。

以上核心技術透過 23 年的打磨與應用，資料指標開發與共享效率大幅提升，分析看板搭建時間從天級別縮短到小時級別，且業務使用者逐漸可以進行自交付，解決了集中式研發的人力瓶頸，日均指標消費頻次從 23 年初的百萬級增長到年末的數千萬；在 23 年基礎之上，我們未來還將在資料加速、智慧物化、智慧診斷、大模型應用等方面持續深耕，不斷最佳化資料存算成本，提升資料應用的效率、體驗。

依託於京東資料資產的完備性、資料能力的自動化與資料應用的智慧化，結合業務場景真實遇到的痛點問題，我們積累了一些經驗，
本文將透過如下幾個章節進行分享交流：
1、 資料資產篇 -- 資產認證與治理
2、 資料能力篇 -- 指標中臺實踐
3、 資料展現篇 -- 資料視覺化工具
4、 資料智慧篇-- 基於大模型的智慧化應用
1、資料資產篇 -- 資產認證與治理
背景與挑戰
零售資料模型有 80+ 萬張，其中有大量的臨時表、無效表等，零售資料資產使用者 (尤其是分析師角色) 一直存在找模型、理解模型、使用模型困難的情況，面對業務用數、分析需求，在找模型探資料的環節經常消耗較多的時間精力，使用者普遍希望可以節約找、用模型的時間，提升交付資料結果、分析結果的效率，而且有些錯誤的或重複的資產在公司部門內流通，重複資產一方面浪費成本，另一方面無法保證資料的一致性。

為解決使用者訴求，同時從產研角度希望最佳化資料資產的質量和標準化程度，從生產到消費均進行一定程度的最佳化改造，提升端到端的資產建立標準化程度，進而提升使用者使用體驗。

資料統一語言
目標：如下圖所示，拉齊資產建設者和資產消費者之間的溝通語言，提升找表效率、增強表的可解釋性。



透過資料維度建模的三個階段 (概念模型、邏輯模型、物理模型)，形成描述模型的標準定義。



總結為一句話：

業務域 & 主題 下，描述了 X1 業務過程 ， X2 業務過程 的 X 主體 表，每 更新頻率 更新 更新週期 資料的 儲存方式 表，表主鍵是 資料粒度

比如：adm_d04_trade_std_ord_det_snapshot 通用域 & 交易 下，描述了 取消,完成,成交,訂單出庫,下單 的 大盤訂單 表，每天更新近 1 日的增量快照 表，表主鍵是 ord_type+sale_ord_det_id

維度建模方法論
3 個階段：概念模型 > 邏輯模型 > 物理模型 (1:N:M )

概念模型
在一個分析領域內，描述實體以及實體之間的關係，等同於業務圖譜。一個主題下一個概念模型。

實體之間的關係包括引用關係和繼承關係，引用關係：一個實體是另外一個實體的屬性。繼承關係：實體比另外一個實體更細化具體，比如事件和瀏覽。

where [業務域]+ why[主題]+who[主體集合] + what [業務過程集合]

舉例：交易的業務流程圖：



將業務流程中的實體（包括業務活動和業務物件）之間的關係構建出來，變成交易主題下的概念模型：





邏輯模型
邏輯模型：是將概念模型轉化為具體的資料模型的過程。一個概念模型下會拆分成多個邏輯模型。拆分原則：根據主體或者業務過程進行拆分。

where [業務域] + why[主題] +who[主體] + what [業務過程]

這裡的業務過程可以是單個，也可以是多個。一般根據業務將業務相似度高，同粒度的業務過程放在一起。

舉例：

where [主站] + why[交易] +who[訂單] + what [下單、支付、出庫、完成] where [主站] + why[交易] +who[訂單] + what [下單、支付] where [主站] + why[交易] +who[移動訂單] + what [下單]

物理模型
用技術手段將邏輯模型透過不同的加工方式和週期頻率等物化形成多個不同的物理模型。一個邏輯模型對應一個或者多個物理模型。更新週期：每次更新多久的資料。更新頻率：多久更新一次。加工粒度：描述模型每一行的業務含義，也就是主鍵。

where [業務域] + why[主題] +who[主體] + what [業務過程]

• when [更新週期 + 更新頻率]

• how much [加工粒度]

• how [更新方式]

舉例：

[主站] + [交易] +[訂單] + [下單、支付、出庫、完成] + [未歸檔/日]+[訂單號] + 增量

[主站] + [交易] +[訂單] + [下單、支付、出庫、完成] +[未歸檔/日]+[銷售訂單明細編號] + 增量

[主站] + [交易] +[訂單] + [下單、支付、出庫、完成] +[近 1 日/日]+[銷售訂單明細編號] + 增量

[主站] + [交易] +[訂單] + [下單、支付、出庫、完成] +[近 180 日/日]+[銷售訂單明細編號] + 增量

[主站] + [交易] +[訂單] + [下單、支付] +[近 1 日/日]+[銷售訂單明細編號] + 增量

[主站] + [交易] +[移動訂單] + [下單] +[近 1 日/日]+[訂單號] + 增量

資產認證
基於資料標準，推進資產認證，透過資產完備性、唯一性治理，存量資產關停並轉，提升認證資產的需求覆蓋率，降本增效。目前，已認證模型近 3000 張，資產需求覆蓋率 84% 以上，覆蓋零售範圍內的交易、使用者、流量、營銷、財務等核心主題資料資產建設。



資產可感知
從全域性到區域性，端到端的全面瞭解資料資產，提升資產可感知的能力，包含：

1）推進資料資產圖譜的自動化構建能力，從資產全景上快速瞭解到業務流程及業務資料化的資產模型（資料孿生）；

2）豐富模型詳情頁，歸一所有資訊源，並增加對模型行高、資料範圍、常見問題等資訊，提升使用者理解模型的效率；

3）標準欄位庫，透過對欄位標準口徑、業務描述、特殊場景、常見問題等資訊的補充和完善，提升使用者理解模型、用模型的效率。

未來計劃
•以使用者反饋問題出發，完善和最佳化資料標準 5W2H，使其確保資料資產清晰易理解的目標達成；
•依據樣板間的效果反饋，完善樣板間的功能和內容，並推廣到其他主題資產；
•加強資料資產運營，擴充套件渠道，提升使用者找數用數體驗。


2、資料能力篇 -- 指標中臺實踐
背景與挑戰


❌1、口徑歧義與存算不受控：指標通常散落在 BI 報表工具、資料產品、ETL 過程與各種中間表中，看不清，改不動；如何系統化保障存算資源使用合理？

❌2、研發資源缺口：資料 BP 缺少 OLAP 資料研發、資料服務研發、前後端研發，在不擴招的情況下如何滿足各業務單元的用數訴求，降低指標加工門檻，使少量 BP 同學即可完成自交付？

❌3、指標開放共享難：如何讓原本鎖定在資料應用產品內部的指標無需重複加工即可對外開放共享，讓指標流通起來？

技術先進性
縱觀業界比較成熟的指標中臺相關建設，針對零售場景口徑變化快、使用者型別多且數量大、資料產品形態豐富等特點，我們打造了核心優勢項能力：

1.全量的指標明細資產管控能力【指標、維度資產】
2.系統原生的拓撲能力【指標市場】
3.業務公式統一沉澱能力【規則引擎】
4.指標異常主動預警能力【指標巡檢】
5.基於邏輯寬表的智慧加速和擴維能力【定義驅動生產】
結合以上我們特有的優勢項能力，在業界首次實現了生產與消費聯動互相促進，打造了資料收集、資料安全、指標計算、監控、分析以及決策支援的指標生態，提供一站式的中臺化、服務化的指標服務平臺，讓使用者可以高效地管理和分析各種業務指標，主要解決使用者在資料處理和分析過程中遇到的以下幾個問題：（1）資料孤島：不同的部門或業務線可能使用不同的系統來記錄資料，導致資料分散在不同的地方，集中分析變得困難。（2）資料標準一致性：保證整個組織內部使用統一的資料指標定義和計算邏輯。（3）實時性：業務決策往往需要實時或近實時的指標來支援，一站式指標中臺化解決方案可以提供實時監控和即時分析。（4）自助式分析：業務人員和分析師可以透過友好的介面進行自助式的資料探索和分析，而不需要依賴於專業的資料團隊。（5）資料治理：包括資料安全、質量管理、合規性監控等多方面確保資料的準確性和可靠性。

總體架構設計


在架構設計上我們參考了 MDA 和 DDD 的思想，希望透過口徑元件實現自動生成程式碼並統一查詢語言，支援全鏈路行為決策；透過 DRY 的原則抽象指標定義相關可積木化執行的原語，以便於基於資料應用的場景連線底層平臺能力；從圖中可以看到整體架構分為物化層，語義層，和查詢層。在整個過程中都會伴隨資料加速，透過統一接入層開放給各個產品端或視覺化工具來使用，物化層用來回答前面的存不存，存多久，存哪裡，怎麼存的問題；語義層用來透過系統將業務語言轉化為機器語言，查詢層用來回答資料去哪拿、怎麼拿、怎麼拿最快的問題，最上面藍色部分為各個消費指標產物的產品端，深綠色是視覺化工具，淺綠色是正在孵化階段的基於 GPT 的資料分析工具。

詳細設計展開
查詢層 ：統一查詢語言，最佳查詢策略、最優查詢效能


統一的 DSL
在查詢語言層面，需要將自然語言分析需求轉換為結構化的查詢語言從而達到書同文、車同軌的目的，使得指標資料所見即所得，開箱即用。我們透過如下案例來說明語言抽象的思路，例如一個常見的分析需求：

「23年12月21日'小米'品牌在各店鋪'成交金額'排名 top5 的情況」

如果將該需求進行結構化抽取，可以做如下解釋：

聚合條件：【按 ‘店鋪’ 聚合】，篩選條件：【時間範圍 = '2023-12-21'、品牌 = '小米'（id 是 8557）】，要查的指標 =【成交金額】，排序 =【按 ‘成交金額’ 降序】， 返回維度屬性 =【店鋪】，分頁 =【第一頁-5 條】。

透過這樣的結構化思維的理解，則統一的指標查詢語言可以由五要素組成：指標、聚合條件、篩選條件、排序分頁、返回維度屬性。基於此五要素，設計出統一查詢 DSL。如下結構體所示，語法規則設計類似 Json 語法風格。

{
"indicators": [
"ge_deal_standard_deal_ord_amt"
],
"attributes": [
"shop"
],
"criteria": {
"criterions": [
{
"propertyName": "main_brand",
"values": "8557",
"type": "string",
"op": "="
},
{
"propertyName": "dt",
"value": "2023-12-21",
"type": "string",
"op": "="
},
...
],
"orders": [
{
"ascending": false,
"propertyName": "ge_deal_standard_deal_ord_amt"
}
],
"maxResults": 5,
"firstResult": 0,
"group": [
"shop"
]
}
}

智慧定址拆分
在實際應用情況中，在簡單的五要素基礎上，真實業務場景還存在一些同環比、複合指標計算類似的分析及提數場景，則一次取數任務並不是提交一次引擎查詢就可以滿足需求。所以按照實際場景，查詢引擎在處理一次取數任務時，會生成一個執行計劃 DAG，主要包含兩層拆分原則：

（1）語義拆分：按照查詢引擎提供的 DSL 語義進行第一層拆分，結合統一的包含 “指標、維度、資料服務” 的基礎後設資料中心，進行定址物料的歸堆分組，根據決策策略表進行拆分，包含取定址最大必要集、線上轉離線的策略以及可手動調配的權重等，一個 Job（對應使用者一次取數任務）會拆分為多個 Task，每個 Task 表示一批邏輯的指標/維度查詢。

（2）引擎拆分：按照指標維度所存在的資料服務（表引擎）進行第二層拆分，一個 Task 會拆分多個 Query，每個 Query 表示一次面向引擎的查詢，包括上圖裡當期查詢、同期查詢等並針對 Task 按照實際查詢場景進行主從/並行的 Query 決策。

查詢邏輯加速
包含根據執行計劃發起的主從/並行和點查/批查的查詢，透過這個邏輯加速可以減少 2/3（整體的統計，一批指標越多越明顯）的冗餘資料查詢，從而提升整體 TP99 表現，同時在查詢層透過動態獲取叢集 CPU 負載等情況可以用來進行自動切流、潮汐滾動等加速最佳化，比如在雙流情況下，當其中一條流叢集 CPU 負載超過預設的閾值時，啟動自動切一部分流量到另一個流從而來前置降低叢集負載避免影響查詢速度。又如在近線的查詢場景中（分頁邏輯非同步發起多次請求，使用者預期分鐘級響應內），透過獲取叢集 CPU、負載的使用情況來動態調節請求的流速，從而透過最大化利用叢集資源來實現查詢提速。當然在查詢加速上少不了快取的介入，透過 JIMDB+ 本地快取的方式進行多級快取的加速。

語義層：資料知識系統化，使資產放心好用、治理有依據


資料知識系統化：
在資料知識視覺化上要做的事兒是如何將業務語言轉化為機器語言，並根據設定的標準及規則進行執行，對此分別從指標維度體系化標準定義模型、指標維度的資料安全保障模型、指標消費應用管理模型三個層面進行了系統化設計，為自動化生產、消費及全鏈路血緣視覺化做資料治理打好基礎。

•指標、維度體系化標準定義模型：
透過定義 4w1h 構造原子指標並結合標準維度定義的裁剪口徑進行唯一的、標準的衍生指標定義。

複合指標指建立在衍生指標之上，透過一定運算規則形成的計算指標集合（二次邏輯計算），如 ARPU 值、滲透率等；包括比率型、比例型、變化量型、變化率型、統計行（均值、分位數），複合指標採用了 “積木化 + 服務化” 雙重解決方案，在既滿足業務靈活場景下，又做到了複合指標的資產沉澱。

又如以複合維度的模型為例在維度模型上結合較頻繁變動的維度（維度的定義會週期性變動）調整項如何統一，對需求進行了抽象，設計複合維度模型，進一步擴充"指標 - 維度 - 修飾"的概念體系，既保證了維度口徑定義的透明,又保證了邏輯一致且可被系統執行;一次定義,多處使用，結合上面提到的統一查詢的服務化能力做到了真正的開放（日均呼叫量 4000w）、共享（可複用，不用單獨開發）。

•指標、維度資料安全保障模型：
對人在資料應用產品上能看到什麼樣的資料範圍需要有安全保障，避免資料洩露風險。對此透過把看數視角【維度 + 維度值】定義到資料角色裡，可做到資料角色被多個人或者崗位所複用。在資料角色基礎上抽取崗位的模型把人與角色關聯起來，保證一個人可有多個身份切換不同視角進行靈活看數。在崗位下透過設計功能角色把資源（選單）的許可權進行管控，在資源下進行具體指標和維度組的關聯，從而達到在基礎的行列之外，提供了各種 “檢視” 級別的權控，而每一個 “檢視” 是展示的最小單元。而資源內的指標維度叉乘關係是資料許可權全集的真子集從而達到快速分配許可權的目的。

•指標消費應用管理模型：
當一個指標被申請消費時，需要知道被用在來什麼平臺、什麼端，應用場景是什麼樣的，從而來評估是否允許接入、是否需要重保、資源如何分配等。對此構建消費應用管理模型，從指標到資源、場景、應用端、應用平臺的關係把消費血緣需要體現出的具體消費情況都能涵蓋。

資產放心好用：
在資料知識系統化的前提下，需要大量對外開放，基於三道防線保障了日常和大促的資產放心好用，為系統穩定執行保駕護航：

•第一道防線：前置避免故障發生：
透過資源隔離來進行各平臺、端甚至看板級別的隔離保障，保障的是一些非重保看板查詢變慢或者阻塞不影響其他核心業務；壓測相關是在平臺層面上基於歷史呼叫採集分析對現實場景的高度還原，進行全鏈路節點高保真壓測，並且針對壓測期間透過動態別名切換技術，來實現業務無損壓測及資料產品無感知壓測；在混沌工程演練上將核心的資料鏈路注入問題點，自動識別潛在風險，防患於未然。



•第二道防線：巡檢與監控，主動發現




在態勢檢測及預警上，結合呼叫情況對預計算、預熱命中率等趨勢預警，防止有些預計算未命中或者預熱未覆蓋到的情況；在資料 SRE 的體系建設上，對呼叫情況透過全鏈路的 uuid 進行串聯，並進行視覺化展示，提升資料可觀測性，打破多系統監控資料孤島，提升監控效率；巡檢能力是透過日常的訪問日誌分析及梳理，以及各核心業務場景的輸入，如上圖所示，基於統一查詢服務的巡檢配置場景及對應告警規則，結合巡檢自動化任務，可在任意時間按任意頻次動態執行任務，防止資料空窗、跌 0、異常波動等情況。先於使用者無感的在系統層面發現問題；從發現、跟進、分析、解決、經驗沉澱做到全流程自動化。在實戰中巡檢的問題主要分以下幾類：

（1）對於實時資料異常的巡檢，第一時間發現後馬上進行資料流切換，使用者完全無感知；

（2）BP 的戰報、日報透過巡檢無需人工確認，自動將結果傳送給對應業務，可以及時介入；

（3）大促期間有很多指標資料有 “異常” 大波動（以 23 年 618 期間為例，巡檢發現 16 個線上異常情況），產品研發收到巡檢結果後第一時間進行業務分析，從經營狀態角度確保資料在預期之內。

•第三道防線：應急預案
對於一些已發生的問題，一定要有應急預案才能真正做到臨危不亂，服務化對於限流、熔斷實現了精準靶向，可做到針對某一個頁面的某個主題指標進行細粒度限流或者熔斷處理，也可做到整體的看板或者叢集粒度的處理，保證容災的靈活性。同時對降級策略有更友好的設計，在降級後預設返回兜底 0 的基礎上，透過快取機制，可返回最後一次請求成功的結果，增加了系統靈活性及減少業務的損失。在應急預案上由於壓力過大導致服務或容器出現異常時，會應急啟動熱備容器，讓子彈飛一會兒，爭取更多的修復及問題定位時間。

存算成本集約化治理：
指標體系開放，在生產、消費間進行系統化流轉，基於指標體系及指標消費應用管理模型首次解決消費鏈路可追蹤，結合指標的生產血緣，形成清晰的全鏈路血緣。

打通全鏈路血緣的必要性主要基於以下三大視角：

（1）使用者視角：讓使用者從指標展示入口（標準化產品、資料工具）到口徑與資產血緣清晰可見，知道資料從哪來、怎麼來、怎麼用。

（2）治理視角：透過資料標準消費端反向治理，可清晰的知道某些模型或者表在消費側的使用情況如何，訪問少或功能相似的看板做整合，關停並轉，實現了從消費價值來反推資產 ROI。

（3）監控視角：當大促期間發現某一資料任務延遲或者某一實時流積壓時，可透過血緣關係快速確定應用上的影響範圍，從而能快速介入進行分析並判斷是否公告使用者。

物化層：基於資料消費行為 (HBO)、系統內建規則 (RBO) 自動加速


中間結果物化
大資料量預計算有著耗資源、易失敗的特點，資料同步會因為網路抖動或叢集異常造成同步失敗，整個鏈路失敗率高、重試成本高。使用者在定義驅動生產只配置基於數倉做預計算，結果資料同步到目標資料來源，中間過程並沒有做配置。為提高任務穩定性，系統內建 RBO 判斷為預計算任務會自動最佳化生產路徑：首先生成預計算 SQL，之後透過 SQL 做讀時建模，在數倉中自動建立模型並將預計算結果資料寫入到模型中，模型會繼承邏輯表 5W2H 並寫到後設資料中，避免模型重複建立。最後基於模型生成資料同步任務。這樣任務失敗只需要重跑預計算或同步任務即可，無需全鏈路重跑，降低任務重試成本。更為關鍵的是，系統會給中間結果 (包含系統建立模型) 配置生命週期，讓資料合理生產與消亡，如果不被下游依賴則會全部清理直至下次使用再建立，避免人工開發場景只生產不治理的情況。

雙流場景，定義驅動生產內配置雙流策略則會預設生成一個計算任務，中間結果物化到臨時表並基於中間表資料生成兩個同步主備叢集的任務。

資料索引增強
多維分析場景中，經常使用 Groupings Sets 將多個維度組合進行計算，通常每個維度組合都對應唯一編碼 (命名為 LVL code) 供消費側查詢使用。之前人工開發大多資料研發和服務研發共同維護維度組合與 LVL code 對映表，在指令碼和服務中透過硬編碼方式實現雙方聯動，維護成本極高。定義驅動生產判斷預計算目標源是 ClickHouse 則自動使用 Groupings Sets 生成輕聚合資料，生產側透過呼叫生成 LVL code 函式獲取維度組合對應的 LVL code 值，並自動將二者寫入到"資料索引"表中，消費側查詢時同樣透過"資料索引"表獲取編碼值生成 SQL，生產、消費自動聯動。

自動加速與引擎優選
除使用者手動建立加速方式外，系統還支援基於代價與使用者消費行為智慧物化。使用者申請指標填寫 QPS、TP99 兩個資訊，使用者可在加速策略模組選擇高階功能"智慧物化"，並可配置儲存上限、構建頻率、構建結束時間等資訊。系統分析訪問日誌，會對指標 + 維度粒度 TP99 大於目標值進行自動生成加速策略，預設將數倉資料進行預計算並同步到 HBase 中，系統判斷邏輯表配置了介質加速 如 HIVE2ClickHouse，則會透過引擎優選功能判斷基於數倉和 ClickHouse 哪個計算更快、更省資源，一般會最佳化為 ClickHouse2HBase。

智慧物化是整個系統的核心，解決業務敏捷與無序增長的困境，使用者定義完虛擬資料模型的業務邏輯後，引擎不會直接將其物化，而是按消費端對模型欄位的產出時間和查詢速度的要求，分析全域性資料的查詢情況，選擇性按全域性最優的策略進行物化編排（透過物化檢視實現），並持續 HBO 最佳化。

業務貢獻和價值

覆蓋資料中臺內所有場景和資料團隊，零售內 4 個 C-1，及 4 個外部子集團產研（如 CHO、京東健康、京東工業、京東自由品牌）。日均 4000w+ 次資料呼叫，支援零售 8000+ 個指標，並支援了 22 個資料產品，覆蓋產研 300+ 人。做到了無 OLAP 資料和服務端研發資源使用指標服務平臺交付需求，資料整體交付效率由 3 天縮短到 0.8 天，提升需求交付效率 70%。

3、資料展現篇 -- 資料視覺化工具
背景與挑戰
從行業來看，未來所有成功的企業都將是數字化轉型中表現卓越的組織。在資料展現能力上，持續探索資料視覺化理論、豐富資料分析方法和視覺化表達，推動資料視覺化自動化、場景化、智慧化快速落地，助力京東各業務單元敏捷作戰，激發個體創造力，不斷適應市場和業務需求的變化。

技術先進性
透過持續建設系統能力，賦能看板、報告、大屏、分析、提數等多個業務場景，同時從 4 大方向縱向拉通系統質量保障建設，提升系統穩定性，最終實現在複雜多變的業務場景下，透過功能插拔、動態配置，構建一站式的解決方案，主要具備以下優勢能力：

1.分析視覺化元件：引用業界先進的圖形語法理論結合 SVG、D3 等技術沉澱，自研 9 類視覺化分析能力，如杜邦分析、異動分析、交叉分析等。相較於行業方案，更加貼合京東零售業務分析思路。
2.低程式碼編排：設計並實現了編排技術方案，包括狀態管理機制、視覺化編排系統、資料集編排系統、程式碼生成與注入系統，可將萬行程式碼的看板完全配置化實現。
3.PC、移動端雙端支援：基於移動端元件庫和低程式碼平臺高效支援移動分析訴求，支援多端、多網路、多裝置，互動體驗媲美原生 App。
4.報告、洞察等場景化能力：基於底層通用系統能力和能力基座打造。報告場景下業內首次支援複雜資料 PPT 報告的自動化輸出，大幅提升分析師效率。洞察場景下基於標準化協議實現洞察配置化，並支援快速橫向擴充套件分析能力，高效支援不同業務場景下的問題自動發現與診斷歸因。
以上資料視覺化技術方案目前在零售內得到充分應用，有效支撐日常迭代和大促期間複雜多變的業務場景，能夠實現降低研發成本，提升研發效率，完善使用者體驗。

整體架構介紹
在資料驅動業務運營的策略下，以高效靈活、場景化、智慧化為目標，整合資料資產和工具，以視覺化元件和低程式碼平臺為核心，打造黃金眼、商智等標杆的資料應用，實現對不同業務場景的快速賦能。我們透過持續建設系統能力，賦能看板、報告、大屏、分析、提數等多個業務場景，同時從 4 大方向縱向拉通系統質量保障建設，提升系統穩定性，最終實現在複雜多變的業務場景下，透過功能插拔、動態配置，構建一站式的解決方案。







整體來看，資料分析視覺化的能力建設，主要可以分為 PC 端能力建設和移動端能力建設兩個方向，接下來將從 PC 端的分析視覺化元件建設、低程式碼編排、資料推送，以及移動端能力建設和多端一體建設幾個方向，詳細介紹資料分析視覺化的核心技術方案以及在業務中的應用。

詳細設計展開
分析視覺化元件




圖形語法理論
分析視覺化元件底層均採用了業界先進的圖形語法理論。圖形語法是一種將抽象基本元素組合成圖表的規則。圖形語法深層次地反應出統計圖形的層次結構。在圖形語法學中，一般統計圖表的規格主要包含 6 個要素：

•DATA：一組從資料集建立變數的資料操作

•TRANS：變數轉換（如排序）

•SCALE：度量（如對數）

•COORD：一個座標系統（如極座標）

•ELEMENT：圖形及其藝術審美屬性（如顏色）

•GUIDE：一個或多個輔助物（如軸線、圖例）

和傳統列舉圖表相比，使用圖形語法生成每一個圖形的過程就是組合不同的基礎圖形語法。故而它的靈活和強大之處就在於，只需要改動其中某一步驟，就能得到完全不同的、全新的圖表。







基於靈活的圖形語法理論基礎，沉澱了大量視覺化分析能力，接下來將具體介紹幾種特色能力。

杜邦分析
杜邦分析法（DuPont Analysis）是一種綜合利用多個財務指標比率關係來拆解企業財務狀況的分析方法。其基本思想是將企業淨資產收益率逐級分解為多項財務比率乘積，這樣有助於深入分析、比較企業的經營業績。由於這種分析方法最早由美國杜邦公司使用，故名杜邦分析法。 使用杜邦分析法可以清晰描述指標體系內指標的層次和指標間的關係。如下圖所示，杜邦分析法透過樹形結構自頂向下的展示了指標間的構成和層級關係，同時透過指標之間的運算子號清晰展現出指標之間的計算關係，例如 “淨資產收益率=總資產淨利率 * 權益乘數”、“總資產淨利率=銷售淨利率 * 總資產週轉率”、“銷售淨利率=淨利潤 / 銷售收入”、“總資產週轉率=銷售收入 / 資產總額”。採用這一方法，可使財務比率分析的層次更清晰、條理更突出，為報表分析者全面仔細地瞭解企業的經營和盈利狀況提供方便。



•佈局策略：設計 12 種佈局方案，分為兩大類：垂直方向（自頂向下、自底向上）、水平方向（自左向右、自右向左），透過 d3-hierarchy 對層次結構資料進行佈局計算，實現 node 佈局。

•節點關係：node 節點關係繪製（父子、兄弟）、node 節點輔助資訊繪製（提示、預警等），實現關係 ICON 位置計算、輔助資訊位置計算。

•互動：設計了收縮展開、縮放能力，支援大數量圖表的互動，透過 viewBox 實現。

•異動分析

在實際的業務場景中，為實現對全鏈路監測部分的視覺化展示，沉澱了可複用的視覺化元件：網格指標卡。該元件適用於異常監控分析、全鏈路轉化分析等分析場景，主要包括以下幾部分：

•指標卡：整合指標卡全部功能，並透過對異常指標的特殊標識來達到預警能力
•流轉線：反映指標間的轉化關係
•標題：業務流程的標識
主要的實現流程如下：







在具體的技術實現上，針對點、線、卡片的位置計算和繪製，採用了類似杜邦分析的技術思路，前端動態計算節點、連結關係位置，並使用 svg 等前端技術進行渲染。除此之外由於圖表結構和邏輯比較複雜，如何設計該圖表的配置化方案，成為了另一個技術難點。為此，針對標題部分我們抽離行、列標題組，複用流程標籤元件的配置邏輯；針對卡片本身，複用了原先指標卡的配置邏輯；針對指標卡的位置和連線關係，使用者能夠透過行列座標的設定和關係繫結來進行細粒度配置，同時為了節省使用者的配置成本，元件會在初始化的時候進行預設編排。

最終在商家異常全鏈路監測需求中使用網格指標卡元件，針對 3 個環節、7 個模組、19 類的核心指標與異常型別商家數量，讓使用者能夠從商家經營整體環節透過預警功能進行風險監控和異常定位。





交叉分析
為解決複雜的資料分析場景，建立了一種基於 React 技術自研的交叉分析表格元件，將常見的表格操作與交叉資料分析的思路結合起來：在傳統可下鑽表格的基礎上，創新地抽取分析動作層，能夠類比資料分析中的切片、切塊和下鑽思路，進行資料分析，使用時允許使用者在多個合法維度中選擇，形成一條自定義下鑽路徑，成功地實現多種維度下，在表格中進行可下鑽的交叉資料分析，滿足了多元複雜的資料分析需求。



了 “在父級維度某個維值的過濾條件下，按子級維度聚合的” 資料，再整體將最新的資料拼接到的表格資料中，至此便實現了交叉資料分析的分析動作。





自動化分析
在沉澱分析視覺化元件的同時，也在自動化、智慧化的資料分析方面進行探索和建設。其核心思路是，透過貢獻度和基尼係數等演算法，計算出最需要關注的品牌、品類等，並基於增強分析技術，如洞察文案生成技術和圖表標註技術等，自動生成資料包告。

同時，基於自動分析結果，還可以進一步透過多因素分析等視覺化分析元件進行更深入的探查。基於表格元件，透過元件聯動能力，組合多個表格形成聯動下鑽分析。





低程式碼編排
資料產品頁面具有複雜的業務邏輯。一方面頁面佈局複雜，一個頁面可能包含數十種元件，涵蓋佈局、篩選、視覺化等多種元件；另一方面元件間存在大量聯動邏輯，如篩選元件間聯動、篩選元件和視覺化元件聯動、視覺化元件間的聯動以及和外部系統的聯動等；此外，業務場景靈活多變，例如在作戰單元模式下，Boss、採、銷、控等角色資料分析思路均不一致：這些都對編排能力提出了極大的挑戰。為解決這個問題，持續調研學習行業先進的低程式碼技術理論，同時結合資料產品的特性，設計並實現了一整套編排技術方案。

首先是自研了基於 MVC 模型的 JMT 狀態管理框架，在 redux 的基礎上，升級了狀態的更新和變化響應機制，支援複雜非同步狀態管理，以一種通用狀態模型支撐了資料產品邏輯的配置化。







其次是基於 JMT 元件庫自研了視覺化編排系統，一方面，透過多種靈活的佈局元件，支援複雜頁面佈局的編排。另一方面，提供了靈活的元件配置皮膚，除常規樣式的編排外，還充分發揮底層資料視覺化能力，支援如杜邦分析等指標關係的編排。此外，透過對底層 React 框架的靈活使用，創新元件巢狀機制，支援視覺化元件互相嵌入形成聯動分析，如在杜邦分析中既展示 GMV 的拆解，也展示 GMV 的達成進度等。





第三是構建資料產品特有的資料集編排系統，支援對資料資產、EasyData 等多種資料來源，透過編排維度、指標、過濾構建資料分析模型，並基於圖形語法技術將視覺化元件和資料服務的 olap 能力做充分打通，實現資料驅動視覺化。



第四是自研了一套程式碼生成和注入系統。視覺化編排和邏輯編排使用一套標準 Schema 進行驅動，在頁面釋出時，會基於 Schema，結合 React 和 JMT 狀態管理，自動生成程式碼。此外，對於頁面中的尚未被元件功能覆蓋的個性化邏輯，可以透過程式碼注入，配合 JMT 函式庫快速解決。在百億補貼等緊急需求中，程式碼注入功能解決了大量個性化邏輯，在時間緊任務重的情況下，保質保量交付需求。





資料推送
郵件作為現有工作模式下一種不可或缺的通訊方式，在郵件裡檢視看板資料（定時彙總為小時/日/周/月等不同時間粒度），成為諸多使用者的強烈訴求。

各業務服務呼叫統一的後端服務建立定時推送任務，任務透過前置配置項檢查後，被新增到消費佇列中依次處理，處理的產物包括圖片、Email HTML、附件等，最終按照使用者配置的觸發方式推送出去。

下圖梳理出任務處理的關鍵流程：素材處理服務（Node）主要承擔推送任務消費及提供獲取素材的 HTTP 服務兩大功能。在任務消費過程中，素材處理服務會模擬使用者許可權開啟瀏覽器去做頁面 Canvas 影像轉換、看板截圖、PDF 生成等操作。如果觸達方式為郵件，則會將所有素材填充生成為 Email Html 文字檔案，透過回撥返回給後端，推送給使用者呈現的內容是資料看板。







在素材生產過程中，服務透過捕獲螢幕快照來實現這一目的。但是某些情況下，比如裝置效能較差或者頁面進行縮放而 Canvas 影像尺寸沒有隨之調整時，快照圖片會變得模糊。為了解決這個問題，我們直接獲取 Canvas 物件。透過 Chrome DevTools 協議，可以將 JS 程式碼傳送到瀏覽器並在上下文中執行，執行結果會被序列化為 JSON 格式返回給 Node.js 環境，從而達到 Node 服務與 chromium 上下文通訊的目的。

在處理階段，由於 Canvas 物件是 Web API 的一部分，只能在瀏覽器環境中使用。而常用的 Node 下操作 Canvas 的工具包幾乎都依賴底層的圖形庫，例如 Cairo 或 Skia 等。這對於開發環境（MacOS）和部署環境（CentOS）不一致的研發來說，除錯難度較大。為了解決這個問題，透過 Node.js 環境提供的 Buffer 物件承接 Canvas 物件的 Data URL，配合 JPEG 影像編解碼器處理。這樣就無需考慮底層圖形庫的相容性和安裝問題，實現素材圖片的順利生成。







依託於資料推送和低程式碼能力組合的建設，在 618 大促期間，已將其應用到業務小時報、作戰單元日報中，快速實現了基於看板的批次報告功能，幫助 3C、大商超等資料 BP 快速實現面向作戰單元的日報和小時報推送，為多場景報告做到了很好的支撐。

移動端能力
透過複用 PC 端的低程式碼編排能力，利用 jmtm 基礎元件庫和 jmtm-charts 圖表庫，能夠快速搭建起移動端的數智化分析功能。





針對移動端看數場景，使用自研的主題配置工具：將元件字號、顏色、圓角、尺寸等樣式變數化，從而可以根據具體需求進行靈活配置。其中色板變數的引入保證了元件庫的底色充足，而公共變數的使用則提高了配置效率。另外我們還引入元件變數，實現個性化的定製需求。支援線上預覽和一鍵釋出等功能：使用者可以透過線上預覽功能，在配置過程中即時檢視效果；一鍵釋出功能則可以快速將配置好的主題應用到移動端低程式碼平臺中。



針對移動端的效能最佳化，透過最佳化動效的執行時機，將動畫互動與耗時的 DOM 渲染分離開來，提高動效的流暢度，減少頁面載入時的卡頓感，確保使用者能夠得到良好的互動體驗。

針對移動端多頁面互動場景，創造性的採用類似原生多開 webview 的翻頁卡片機制並對多個頁面進行快取處理，使整個應用體驗更加接近原生化。基於多人協作及應用的可擴充套件性考慮，我們借鑑業內成熟的微應用方案，並結合自身需求場景，支援微應用巢狀微應用的方案，為較複雜應用的場景提供了可能。

多端一體建設
為了提高研發效率並滿足使用者在不同端的看數需求，我們在 PC 端邏輯編排的基礎上引入了 hybrid 概念，使編排引擎可以釋出到移動端的多個產品線。在頁面打包及部署過程中，使用 webpack 外掛 jmtbuild-hybird-plugin，釋出為能適配到多端的 js-sdk 資源。最後透過前端微服務平臺在對應的容器中載入並展示頁面。

透過低程式碼平臺生成的標準頁面需要在不同的業務端進行展示，在許可權方面，針對嵌入到客戶端的場景進行了 token 校驗，對於瀏覽器 H5，採用 cookie 解析的方式進行登入校驗和資料安全保護。標準頁面預設在公司內網進行訪問，使用 colorAdapter 介面卡函式可以使介面一鍵轉化，接入閘道器。閘道器統一接入了神盾、反扒、防刷等功能，保障外網訪問的資料和網路安全。

業務貢獻和價值
在研發提效方面：在大促期間 Boss 作戰單元的模式下，在戰報的應用場景上，透過低程式碼加資料推送能力的快速整合，在兩週內，支援多個部門的報告推送，累計推送戰報 7220 封；此外，在百億補貼重點專案中，面對緊急多變的業務場景，協同業務團隊透過低程式碼線上配置化 + 二次開發的方式，2 周內交付 5 個看板、2 個大屏，80% 的需求在 24 小時內交付。

在創新業務支援方面：業務對體系化看數需求強烈，期望使用移動端檢視業績達成情況。透過移動端低程式碼能力，僅用 1 個產品經理、4 個資料研發短時間內從 0 到 1 打造出一個基於低程式碼的黃金眼移動端應用，快速解決業務移動端看數的訴求。

此外，隨著零售架構扁平調整，Boss 單元需要更高效的數字化決策工具，自動化分析能力也得到了充分的應用：基於豐富的視覺化元件和低程式碼編排能力，結合後端的智慧化演算法，快速打造零售自動化分析看板，應用於每日的經營過程控制中，將診斷提前至每天的工作中，以提高發現問題和解決問題時效。

展望未來，我們會持續打磨現有能力，並不斷結合新的業務場景和行業調研，沉澱新的資料視覺化分析能力。首先在智慧化方向上，會基於圖形語法的視覺化理論，並整合 AI 等能力，建設增強分析能力，打造增強圖表和自動化報表，實現自動洞察資料關聯、異常及趨勢等，將資料分析從描述性分析躍升到預測性分析和決策性分析；同時在質量體系建設方面，會從監控預警、程式碼質量等方向持續建設，在不斷提升交付效率的同時持續提升交付質量：最終期望能夠透過資料分析技術能力的綜合運用，降低研發成本，提升研發效率，完善使用者體驗，高效推進人人都是分析師的戰略落地。

4、資料智慧篇-- 基於大模型的智慧化應用
背景與挑戰
目前，資料分析服務主要透過資料產品、BI 工具和配備資料分析師等方式來支援，在資料響應效率、分析能力應用的廣度、深度和頻率等方面各有不足，但業務時常需要透過資料驅動決策，就出現了資料獲取難、資料分析難等使用者痛點。大模型在資料消費領域的應用，為使用者痛點的解決帶來了新的思路。

基於 LLM 的解決方案
對於京東複雜的業務和資料體系，大模型在資料服務領域的應用很有價值，同時也面臨著挑戰。當前的架構設計充分考慮了已具備的底層資料服務能力，結合 LLM 實體識別、上下文推理、決策輔助能力將使用者查詢與複雜資料集的相關指標匹配，實現快速準確的資料查詢。透過 NER 識別將使用者的篩選條件、查詢指標、聚合方式抽取出來，利用 Norm(歸一化) 把實體轉換成標準資料服務的呼叫引數，並且構建索引將歸一化依賴的資料資產進行儲存，來實現自然語言查詢準確資料的全鏈路，與此同時，建立完善的評估體系、利用本地模型最佳化等機制，不斷提升應答準確率，為使用者帶來更優質的使用體驗。



基於業務知識和資料知識的 Prompt 工程


Prompt 工程建設
•目標確認：針對使用者對資料的訴求，整理使用者問題確定輸入資料，基於不同任務目標確認不同輸出格式，如實體識別輸出標準格式的{實體類別：實體名稱}，指令生成輸出標準格式的{分析能力：分析指令}等。
•工程建設：確認目標後，從環境預設、指令描述、輸出規範等角度生成規範 Prompt，不斷微調輸入結合業務知識的個性化案例。並透過中英互譯、預設負樣本、增設輸出校驗和邊際檢驗、動態 Prompt 生成等方案最佳化，兼顧時效性的同時，提高輸出結果的穩定性和準確性。
準確率提升
模組歸一化模組會把實體轉成資料服務支援的引數值，難點在於區分出相同名稱或者相似名稱， 為使用者匹配出最符合使用者需求的結果，包括指標、篩選條件、聚合維度等實體的轉化，具體思路可以拆解成以下步驟：

•精確匹配：入參型別、指標名稱或 id、使用者許可權多維度疊加判斷得到精準結果；
•相似性匹配，在精準匹配沒有結果之後，使用大模型對實體進行 embedding 操作，從庫裡查詢出相似度最高的結果；
•建立索引：對實體建立別名層，滿足使用者個人習慣，如部門的簡稱、指標的別名，來提升識別準確率；
•使用者行為資料輔助：透過使用者在資料產品、資料工具等系統的行為資料，生成使用者對指標、篩選條件、聚合維度的偏好資料，輔助提升準確率。
評測體系
資料服務場景對準確率要求較高，同時資料指標相似度、資料口徑複雜等實際情況對大模型的準確率有較高挑戰，如何保障回答的準確性是產品設計之初就重點考慮的問題。目前透過週期性大樣本量評測集生成、檢驗，以及線上監控的組合方式來保障。

•樣本設定：採用人工樣本和大模型生成樣本結合的方式，快速、多頻次對不同句式、不同場景的問答（1000+）做評測，來保障樣本的多樣性和豐富度。
•準確率測評：透過批次呼叫介面返回大模型結果，離線程式碼支援批次結果自動化比對，從而高效輸出任務的準確率、時效性等指標，同時同一批樣本會多次呼叫來評估任務的穩定性。
•構建產品功能：使用者可以在答案上點贊或點踩來反饋滿意度，產品側持續針對使用者反饋問題進行階段性最佳化。
本地大模型 SFT
基於 LLM 對 prompt 工程輸入 token 數量的限制及資料隱私安全的考量，我們也選用本地大模型進行 Fine-tuning。它涉及在一個預訓練模型的基礎上進行額外訓練，以使其更好地適應特定的任務場景，實現準確率提升和影響時長降低，具有很好的效果。



指標查詢場景
在指標查詢場景中，使用者的提問方式具有高度多樣性，同時，影響查詢結果的關鍵因素也呈現出複雜的組合形態。為了提升查詢效率和準確性，建立京東專屬的業務域知識庫來支援樣本的批次生成

•按場景構建多樣化問題庫，如單/多指標查詢、分維度查詢、維度 id 和 name 查詢、排序查詢等
•按查詢因素構建變數知識庫，建立時間、指標、維度、篩選條件知識庫，方便後續新增場景的快速擴充
模型訓練前後準確率對比提升明顯





資料分析場景
本地大模型可支援資料互動，解決資料在傳輸過程中可能遭遇的安全風險和隱私洩露問題。透過問題引導，降低使用者的使用成本，使使用者能夠智慧化分析。透過使用者資料查詢的當前表現，由大模型提供"分析線索"引導使用者進一步分析下探，線索包括：

•描述性分析，如銷量達成情況、趨勢分析、摘要總結
•探索性分析，如維度拆解、相關性指標推薦、異常值識別等
業務價值評估
•資料查詢提效：透過自然語言對話，完成快速資料指標查詢，單次查詢時效降至 7.8 秒，大大降低使用者資料獲取的時間，並且很好的支援了使用者個性化需求的滿足；
•資料分析賦能：依託豐富指標維度資料，透過思維鏈實現自動化資料分析，並依據使用者的習慣喜好等選擇更貼合的資料路徑，非 “分析師” 角色使用者輕鬆實現多場景的快速智慧分析
•資料消費擴充：透過產品賦能，為每一個使用者配置一個專屬的 AI 資料分析師，可以擴大資料消費使用者的規模，並且大幅提升資料消費的能力，支援業務應用資料驅動決策

掃一掃，與作者技術交流一下吧！