作者:京東零售 韓雷鈞
開篇
京東自營和商家自運營模式,以及伴隨的多種運營視角、多種組合計算、多種銷售屬性等數據維度,相較于行業同等量級,數據處理的難度與復雜度都顯著增加。如何從海量的數據模型與數據指標中提升檢索數據的效率,降低數據存算的成本,提供更可信的數據內容和多種應用模式快速支撐業務的數據決策與分析,是數據團隊去年聚焦解決的核心課題。
過程中基于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數據分析師,可以擴大數據消費用戶的規模,并且大幅提升數據消費的能力,支持業務應用數據驅動決策
審核編輯 黃宇
-
邏輯
+關注
關注
2文章
834瀏覽量
29523 -
數據模型
+關注
關注
0文章
51瀏覽量
10070 -
大模型
+關注
關注
2文章
2711瀏覽量
3318
發布評論請先 登錄
相關推薦
評論