在數字化轉型的今天，京東物流業務呈現出復雜多變的特性，涉及眾多場景、多元化渠道與日益增長的數據量。針對市場對于數據即時性和靈活性的迫切需求，京東物流推出了一站式敏捷 BI 解決方案，以應對分散且高并發的數據處理挑戰。本次分享的是京東物流如何通過其一站式敏捷 BI 產品，實現數據的快速集成、即時分析及自服務報告，從而在激烈的市場競爭中贏得優勢，進一步提升業務效率和決策質量。通過這些實踐，我們將見證數據驅動的力量如何在京東物流的業務流程中展現，以及如何幫助企業在數字化的道路上更快前進。

一、業務背景

1. 業務背景

• 數據來源多

數據來源極為多樣化，包括線上數據、線下數據，甚至是手工提報的數據。這種多元化的數據來源導致數據管理和分析過程十分復雜，尤其是在不同來源的數據需要被整合和分析時。由于來源的多樣性，確保數據質量和一致性成為了一個挑戰。

• 需求變化快

由于京東物流的業務覆蓋范圍廣，員工眾多，從總部到各個地區層級，每一個層級都可能產生獨特的數據需求。這些需求經常變化，且每個層級都可能定義自己的數據指標或分析某些特定的數據細節。這種快速變化的需求環境要求數據系統必須具備高度的靈活性和快速響應能力。

• 做數耗時長

傳統的數據處理方式，如員工手工在 Excel 中處理數據，導致數據處理時間長，效率低下。此外，數據處理的成本高，數據口徑不一致等問題也隨之產生。

2. 復雜的“中國式報表”

上圖中展示的是物流和傳統企業中常見的中國式復雜報表，其中有多層級嵌套表格、條件格式和迷你圖表達等特點。其帶來的挑戰如下：

• 受眾多樣性

各個層次、各種角色的成員都是報表的使用者，不同角色的用戶關心的信息內容不同，樣式不同，使用方式不同。

• 數據計算復雜

查詢、分析條件復雜，且報表中往往存在復雜的統計運算，如 Sumif 函數、匯總、同比、環比、達成狀態等。對于參數頁面布局、參數控件類型等都有較高要求。

• 報表樣式復雜

不追求圖表式的直觀可視化效果，而是體現信息的豐富度，因此在樣式上使用了較多的數據透視、多層表頭、不完全劃分、分欄等，樣式非常復雜。

• 多數據源

數據源分散，數據信息來自不同的業務系統，技術路線和數據結構都有很大差異。

• 治理難度大

需要從數據源、數據指標體系兩方面入手，且業務多層級聯動共同拉齊數據認知，為治理帶來很大困難。

• 研發資源消耗大

面向分析場景需求個性化程度高、不固化、不明確，研發側支持有資源瓶頸。

• 大數據技術挑戰大

大數據量、實時在線交互分析、系統執行復雜度不確定、響應時間和用戶體驗很難預判保證。

3. 建設平臺工具以解決實際業務問題

（1）業務場景的數據化挑戰

• 監控與預警的需求：質量改善、工單處理、異常處理崗位對 KPI 達成與工單量變化的敏感度。
• 數據時效性：在考核、復盤、經營運營及責任追究等方面的高標準要求。
• 人力資源局限：現有支持體系難以滿足眾多一線員工的復雜需求。

（2）數據處理的現狀與困境

• 繁瑣的數據獲取與處理：員工需從各自業務系統下載并處理數據，效率低下。
• 報表的生成與分享：數據分析后需制作報表，進而進行分享與下達，流程繁雜。

（3）UData：創新的解決方案

• 敏捷 BI 的引入：一個自助式、集成式的敏捷商業智能(BI)解決方案。
• 數據集成：集成各類指標與模型至數據地圖，簡化標準化數據源的獲取。
• 自助式內容分析：為非專業人士提供易于操作的數據分析工具，減少對技術的依賴。
• 數據準備：簡化數據之間的關聯、篩選與聚合操作，提高工作效率。
• 中國式報表與在線 Excel 插件 A. 數據與報表的融合：通過插件將數據語言與在線 Excel 結合，順應用戶線下習慣。
• 辦公協同系統的整合：報表生成后，通過推送、郵件、訂閱等方式實現辦公自動化，確保信息流暢傳遞。

二、產品方法論與解決方案

1. 產品規劃第一步:產品價值主張

產品規劃的第一步為確定產品的價值主張：強調任何產品都需從其價值主張出發，這是產品成功的基石。

（1）三個邏輯的概述

• 價值發現：識別目標用戶群體，明確產品解決的具體場景及需求，并構建核心競爭力。
• 價值共創：探討如何與合作伙伴共同創造價值，包括共創方案和流程機制的構建。
• 價值獲取：確定價值落地的模式，包括衡量標準和方法。

（2）價值發現

• 用戶需求的深入分析：通過監控3萬多數據業務人員的日常行為，揭示其重復性使用 Excel 等工具的頻繁性和模式。
• 系統化建設的不足：指出目前數據體系化建設的不足，以及數據標準化沉淀的限制。

（3）價值共創的策略

• 建立多元異構查詢支持：強調需要支持多樣化的數據查詢和交互式數據獲取。
• 降低技術門檻：目標是打造一個低門檻、自助式、交互式的工具，特別強調點選式的操作和在線化的 Excel 功能。
• 業務層共建：與業務部門共建數據集，提高數據標準化程度，并通過重點項目共建和數據分析師培養專項計劃提升整體數據理解和應用能力。

（4）價值獲取與效果衡量

• 衡量指標的設定：通過覆蓋度、滲透率和工作時長節省等指標衡量產品上線后的效果。
• 實驗觀測：運用 AB 實驗等方法觀測業務數據分析的效率和效果。

2. UData 一站式敏捷 BI 產品架構

構筑商業智能產品架構的過程中，我們面臨的挑戰源自業務系統的多樣性及數據庫類型的復雜性。為了應對這一挑戰，聯邦查詢技術被引入以實現跨數據源的統一查詢，這不僅強化了數據處理的能力，而且增強了系統的靈活性和響應速度。在此基礎上，數據管理的角色顯得尤為重要，它要求我們能夠清晰地識別并定位標準化的數據集，確保數據的準確性和可靠性。

進一步地，數據的準備、分析和系統共享被強調為系統內特別核心的能力。這些能力不僅加強了數據的實用性，也為后續的決策提供了堅實的支持。

此外，利用商業智能工具和沉淀的標準化數據資產，通過開放 API 支持其他系統調用內部數據，這一策略極大地提高了整體架構的效率和靈活性。

總體而言，在構建商業智能產品時，必須認真考慮和實施跨數據源查詢、數據管理以及數據服務等關鍵功能，以確保系統的強大、可靠和高效。

3. Udata 1.0-產品特性

（1）快速集成多樣數據資源：該平臺能夠迅速融合各類數據資源，突破了傳統數據處理的局限性，為用戶提供了一個全面而綜合的數據視圖。

（2）簡化數據配置：轉變了常規的數據處理方式，用戶無需撰寫復雜的 SQL 語句，而是通過直觀的點選式界面進行數據配置，大幅降低了技術門檻，提高了操作的便捷性。

（3）數據加速與聯邦查詢支持：軟件底層采用了先進的查詢引擎，支持聯邦查詢，這意味著即使數據分散在不同的系統和平臺上，也能實現快速、高效的數據檢索和處理。

（4）類 Excel 的操作簡化

• 線上數據選擇與創建：用戶可以在線選擇并創建自己的數據集，簡化了數據處理步驟。
• 配置在線復雜報表：在數據集基礎上，用戶能夠配置類似于中國式的復雜報表，這些報表既輕量級又易于操作，適應了用戶對靈活性和復雜性的雙重需求。

（5）輕量級訪問與快速集成

工具提供了輕量級的訪問方式，使用戶能夠迅速而方便地處理和分析數據。

支持快速集成到包括辦公系統、業務應用系統和電子郵件等在內的各種平臺，增強了其實用性和廣泛的應用范圍。

4. 一些不足

• 系統穩定性問題

隨著 1.0 版本在更廣泛領域的應用，系統穩定性成為一個顯著的問題，影響了用戶體驗和操作的連貫性。

• 性能問題

數據處理的效率和速度是評估系統性能的關鍵指標，性能瓶頸會導致做數耗時長，進而影響決策速度和業務流程。

• 應用性問題

隨著需求的快速變化和數據來源的多樣化，系統需要靈活適應不斷變化的環境和需求，應用性的不足可能會限制系統的廣泛應用和擴展 Spark 完成歷史數據的回補。

5. 基于用戶價值公式思考產品優化空間

當前系統的挑戰主要為以下幾大方面：

• 系統穩定性：在廣泛應用過程中，系統穩定性常常受到挑戰，影響了用戶的連續使用體驗。
• 系統性能：頻繁出現的性能問題減緩了數據處理速度，影響了整體效率。
• 易用性問題：隨著用戶規模的提升，用戶需求多種多樣，系統的易用性和產品體驗暴露出一些問題，影響了其廣泛應用的可能性。

優化策略與方法論：

• 用戶價值公式：提出了一種評估產品價值的公式，即新體驗減去舊體驗和遷移成本后的剩余價值，以此作為優化的基礎。
• 舊體驗與新體驗的對比：分析用戶的舊體驗，如手工操作 Excel 的熟悉性與穩定性，以及新體驗所帶來的自助式分析和自動化更新的便利性。
• 新體驗中的挑戰：識別新體驗中存在的問題，如數據穩定性和同步的及時性問題，以及用戶面臨的遷移成本。

具體應對策略為：

• 改善數據穩定性：采取措施解決數據丟失和同步問題，提高數據穩定性。
• 降低遷移成本：通過簡化操作和提供培訓，降低用戶的學習成本，使遷移過程更加平滑。
• 增強系統性能和應用性：優化系統架構，提高性能，擴展應用范圍以適應不斷變化的用戶需求。

6. 產品邏輯梳理

（1）數據處理鏈路的核心組成

• 數據源的多樣性：強調了數據源包含實時與離線數據，以及明細層與匯總層數據，其中明細層數據量龐大，而匯總層數據經過聚合后較小。
• 數據集與數據源的區分：討論了數據集作為數據處理和管理的結果，它代表了加工處理后的數據結果集，這有助于提高可視化的效率。

（2）數據集的構建方式與分析能力

• 構建數據集的多樣方式：包括點選式操作生成 SQL，直接編寫 SQL，以及問答式的自然語言處理技術。
• 數據分析能力：探討了提供的分析能力，包括不同類型的數據報告和報告來源，以及系統易用性的考量。

（3）系統優化的邏輯與方法

• 產品和系統邏輯接入的標準：討論了優化新版本系統時考慮的產品與系統邏輯接入的標準和方式。
• 數據準備與校驗：強調了數據準備過程中的校驗工作的重要性。
• 架構梳理與模塊界定：強調了對系統架構、模塊邊界以及前后臺關系的重新梳理和界定，以確保 BI 產品的穩定性和高效性。

7. Udata 產品升級

（1）穩定性提升

①穩定性專項的實施

• 問題收集與記錄：系統地記錄和識別用戶報告的 bug 和問題，如系統打不開或數據不一致等，以便于后續分析。
• 高頻問題識別：通過持續記錄，識別頻繁出現的問題，然后進行分類，以了解哪些類型的問題是經常發生的及其影響范圍。

②分類與復盤

• 問題分類：將識別的問題進行分類，為進一步的分析和解決提供清晰的方向。
• 定期復盤：定期回顧問題，深入挖掘根本原因，并基于這些原因制定解決策略。

③監測指標的定義與優化措施

• 監測指標定義：定義關鍵的監測指標，如故障率和可用性，包括數據問題、共享問題和操作問題等，這有助于更準確地監控和評估系統穩定性。
• 性能優化：識別和解決導致查詢失敗的底層引擎問題，以及相關的性能問題，確保系統的穩定運行。

（2）性能提升

①性能問題及其對用戶體驗的影響

• 性能問題的表現：用戶在嘗試打開報表時經常遭遇長時間的加載延遲，有時甚至無法加載完成，這種延時和不確定性嚴重影響了用戶的體驗。
• 問題的重要性：強調性能問題不僅是一個技術問題，而且對用戶體驗有顯著影響，需要被優先解決。

②性能優化策略

• 性能診斷：通過性能診斷，識別導致報表加載緩慢的原因，可能是數據接入問題、復雜的 SQL 查詢，或不必要的數據引入等。
• 數據物化策略：實施數據物化，將大表拆分為小表，減小查詢的數據量級，從而提高查詢效率。
• 緩存策略：引入主動和被動緩存，基于歷史訪問行為優化緩存命中率，進一步提升查詢效率。

③數據報表的分類與管理

• 分級和分類：對數據報表進行分類和分級，明確每個報表的服務場景和性能要求，實現精細化管理。
• 發布時的約束：在數據報表發布時增加邊界約束，確保每個報表在發布前都能滿足既定的性能標準。

④綜合優化視角

• 技術與運營結合：強調性能優化不僅涉及技術問題，也包括產品運營的思路及用戶的引導和約束。
• 用戶教育：提倡對用戶進行教育，使其更加理解如何有效地利用系統，編寫高效的 SQL，減輕系統負擔。

⑤數據集創建后的性能評估

• 評分機制：在數據集創建完成后，系統將基于性能和效率等關鍵指標對其進行評分，以確保每個數據集都符合既定的標準。
• 優化建議提供：對于評分不高或有改進空間的數據集，系統會提出具體的優化建議，指導用戶如何改進數據集的性能和效率。

基于 StarRocks 的引擎升級帶來極致查詢性能

①性能優化的核心引擎與合作

• 核心引擎選擇：采用基于 StarRocks 的核心引擎進行性能優化，并與社區進行戰略合作，為優化提供技術支持。
• StarRocks 的優化特性：介紹 StarRocks 支持的向量化執行，物化視圖加速查詢和 CBO 優化等特性，以及通過這些特性實現的性能提升。

②算子聚合下推優化

• 數據處理鏈路：描述數據從消息隊列到不同數據庫和引擎的處理鏈路，以及在StarRocks查詢時面臨的挑戰。
• 下推優化策略：實施算子聚合下推，將聚合和排序等操作下推到底層數據引擎（如CK、 MySQL）執行，減少 StarRocks 引擎的壓力和網絡帶寬消耗。

③性能提升的實際效果

• 查詢效率提升：通過優化，六張表的聚合關聯查詢時間從 30 秒降至 6 秒，顯著提升了查詢效率。
• 網絡帶寬優化：減少了數據在網絡上的傳輸量，從而降低了網絡帶寬消耗。

（3）易用性提升

①易用性提升的重要性

• 1.0 版本的問題：指出前一版本因快速迭代而存在的問題，如系統高耦合、操作鏈路不清晰、設計復雜，以及展示形式單一。
• 2.0 版本的目標：明確了新版本的目標是提升易用性，降低用戶的理解和操作門檻，讓數據分析任務像協同辦公文檔一樣簡單。

②ERRC 方法的應用

• 移除（E）：識別并移除多余的無效概念和步驟，以減少用戶學習成本和操作復雜性。
• 減少（R）：簡化頁面信息和操作步驟，去除冗余操作，使用戶的操作更加直觀和高效。
• 增加（R）：增強系統的性能診斷和校驗，建立清晰的系統邊界，提供駕駛艙功能等，以滿足不同用戶的場景需求。
• 創造（C）：創新數據探索能力，如引入問答式 DataGPT，以提供更高級的用戶體驗和分析能力。

③2.0 版本框架優化

• 低門檻目標：降低用戶的理解和操作門檻，清晰可理解的系統概念，簡潔的操作鏈路。
• 性能校驗與診斷：在系統中增加性能的校驗和診斷，確保系統穩定可靠。
• 場景區隔與功能增強：根據不同用戶的使用場景提供區隔化的服務，同時增加駕駛艙等功能以提升系統的實用性和靈活性。
• 創新性能力：通過創新問答式數據探索能力，提高數據分析的效率和準確性。

④舊版菜單的問題

• 繁雜性：描述舊版菜單內容繁雜，各種功能雜陳在一起，導致用戶難以快速找到所需功能。
• 用戶體驗：由于菜單的復雜性，用戶在系統中的導航和任務完成過程變得不直觀，影響了用戶體驗。

⑤新版本的導航優化

• 二級導航引入：提出在新版本中引入二級導航的方式，使結構更為清晰和直觀。
• 內容合并與精簡：對導航內容進行合并和精簡，清楚地定義每部分的功能和定位，以便用戶更容易理解和使用。
• 信息架構清晰：通過優化信息架構，確保用戶在進入系統后能迅速、清晰地了解如何完成任務。

⑥基于席克定律的改造

• 席克定律（Hick's Law）：引入席克定律，說明面對過多選擇時，用戶做出決策的時間增長。
• 菜單優化：根據用戶的使用習慣和流程對菜單進行重新排列，減少或隱藏非常用功能，以減少用戶的選擇負擔和干擾，加快反應時間。

⑦數據準備的操作優化

• 舊版本的操作復雜性：指出舊版本在數據準備環節存在許多步驟和冗余概念，導致用戶理解和操作門檻高。
• 新版本的簡化流程：新版本將數據準備的操作從 11 步精簡至 6 步，大幅提升了用戶理解和處理數據的效率。

⑧應用菲茨定律（Fitts’ Law）優化用戶操作

• 菲茨定律概念：引入菲茨定律，解釋目標越大且越近，用戶到達的速度越快，出錯幾率越低。
• 改造點：基于菲茨定律，縮短用戶到達路徑，提供更合理的引導流程，減少用戶的操作步驟，提高用戶轉化和操作效率。

⑨提升用戶體驗的綜合策略

• 精簡操作步驟：通過減少操作步驟和去除冗余概念，簡化用戶的操作流程，降低理解門檻。
• 優化引導流程：改進用戶的引導流程，確保用戶可以更直觀、更快速地完成任務，提升整體用戶體驗。

⑩舊版本數據準備界面的問題

• 集成度過高：指出舊版本的數據準備頁面集成了選擇數據集、管理和創建操作，導致頁面復雜且難以理解。
• 缺乏用戶引導：操作過程中缺少必要的引導，使用戶在完成任務時感到困惑和不便。

?新版本交互體驗優化

• 操作與反饋分離：新版本中，數據集的操作與結果反饋被清晰地分離，確保用戶可以立即得到操作反饋。
• 明確的操作指示：在界面上清楚地列出可進行的操作，增加用戶在操作過程中的清晰度和方向性。

?泰斯勒定律的應用

• 復雜度守恒概念：引入泰斯勒定律，解釋系統中固有復雜性的存在，并強調其無法被完全消除，只能通過設計進行轉移和平衡。
• 復雜度轉移改造：為了提升用戶體驗，將系統的固有復雜度從用戶側轉移到研發側，通過后端復雜的處理來為前端用戶提供簡潔明了的操作體驗。

三、應用實踐案例

1. 實現業務報表的線上化、數據更新自動化

（1）應用效果概述

• 系統線上化：介紹了通過 UData 系統實現報表線上化，替代了以前頻繁且耗時的手工制作過程。
• 實時更新：強調了一次性設置后的長期效益，報表可以實時更新，顯著提升數據處理效率。

（2）《618 大促小時戰報》效率提升案例

• 優化前狀況：每天手工制作報表 10 次，每次需耗時 30 分鐘，僅能提供整點數據。
• 優化后成果：通過 UData 線上制作一次，耗時 1 小時，報表永久有效且實時更新。
• 效率對比：通過線上化和自動化處理，實現了 80% 的工作效率提升。

（3）省區日常運營監控效率提升案例

• 優化前狀況：每天手工制作報表 1 次，每次需耗時 2 小時。
• 優化后成果：通過 UData 線上制作一次，耗時 2 小時，但報表永久有效，無需重復制作。
• 效率對比：通過自動化和長期有效性，實現了 96% 的工作效率提升。

2. 典型案例

（1）項目概述與目標

• 項目持續期：介紹了項目實施了半年多時間，目標是通過數據處理優化分揀員的工作效率。
• 優化目標：明確項目旨在降低分揀員在數據處理上的時長，并提升其有效工作時間。

（2）成效展示

• 數據處理時長的降低：報告在半年的時間里，分揀員在數據處理上的時長下降了 37%，顯示出數據產品優化的顯著效果。
• 有效工作時長的提升：同時，分揀員的有效工作時間實現了持續上升，其中在半年期間有效工作時長上升了 10%，反映出工作效率的整體提升。

（3）分析與結論

• 效率提升分析：分析發現數據產品優化導致分揀員數據處理時間減少，使他們能夠更多地投入到實際工作中，從而提升了整體工作效率。
• 綜合效益：強調了通過精細化的數據管理和流程優化，項目不僅提升了個體工作效率，也為整體操作流程帶來了效率提升。

3. 升級規劃：ABI 能力進階

（1）數據資產平臺與 ABI 能力進階

• 問答式報表能力：介紹了未來 ABI（問答式商業智能）能力的進階，即通過問答式交互返回報表和數據趨勢，簡化數據獲取過程。
• 移動端應用：強調了在數據資產平臺上結合 DataGPT 和 AIGC 技術，使用戶能夠在移動端輕松獲取所需數據。

（2）數據資產集約管理

• 管理組成：描述數據資產集約管理包含知識庫、標準指標體系和實時數倉模型，形成一個全面的數據管理體系。
• DataGPT 作為釋放窗口：將 DataGPT 作為數據資產價值釋放的輕量化窗口，使用自然語言作為查詢門檻，使所有員工都能輕松進行數據查詢。

（3）大模型 AIGC 的作用

• 業務與技術語言轉化：大模型 AIGC 為業務語言和技術語言的相互轉化提供能力支持，使非技術人員也能通過自然語言獲取復雜數。
• 助力數據普惠化：通過這種能力加持，推進數據的普惠化，使數據查詢和分析不再局限于數據科學家或技術人員。

四、Q&A

Q1：我想詳細了解您提到的基于問答形式獲取數據源碼的方法，以及您正在開發的 data GPT 是如何運作的。

A1：我們所提的是通過問答方式創建數據集，而非直接獲取數據源。傳統上，構建數據集主要有兩種方法：一是基于配置的拖拉拽方式，二是編寫 SQL 語句。我們現在正嘗試通過問答形式來構建數據集。具體而言，用戶可以用自然語言告訴系統他們需要哪種類型的數據集，以及數據集應包含哪些信息。系統將根據用戶的描述生成所需的數據集。這一過程的核心是 NLP（自然語言處理）技術，它能夠將自然語言指令轉換為 SQL 語句，從而建立相應的數據集。

Q2：如果我想查詢特定年份的某項指標或數據情況，系統是否能自動生成相關報告和結果展示？具體實現方式是怎樣的？

A2：目前，我們正在探索兩種方案。第一種方案是結合大模型來實現。在這種方法中，我們將數據資產指標的定義以及一些語義信息輸入模型，以幫助模型更好地理解例如京東物流的數據資產，包括表格的元數據等。當你提出問題時，它可以通過 SQL 返回結果。但是，這個方法的問題在于，有時候回答的準確率可能不高，特別是在數據底層質量不高的情況下，對數據的理解可能會有誤差，導致生成的 SQL 可能不太準確。這需要一個持續優化和調整的過程。我們目前正在嘗試優化這種方法，但只限于小范圍的數據資產。

第二種方案是采用配置化的方法。這種方法不依賴于大模型，而是依賴于一個后臺的數據模型配置策略。你只需要指定相關表格，只要查詢范圍在這個表格或其支持范圍內，系統就能順利地將查詢轉換成 SQL 并返回結果。這種方法比較直接和穩定，但如果基于大模型，則需要持續的運維和調整，因為大模型需要不斷地接收相關領域的數據以提高其準確性。最重要的是，系統能否理解用戶用業務語言提出的問題，并將其轉換成數據語言的過程。

Q3：我希望未來的 BI（商業智能）工具可以更加敏捷，用戶無需編寫腳本或 SQL，只需要輸入一段話，系統就能理解并生成報表或圖表。這是否可行？

A3：這確實是一個很好的想法，目前行業內已有多方探索這一方向。一些產品已經初步實現了這一功能，它們通過部署大型 AI 模型并向其提供相關的指標數據來進行訓練，使其能夠根據用戶輸入生成基本的報表。此外，許多第三方創業公司也在嘗試相關技術。然而，大部分尚未利用大模型，因為完全依賴大模型來解決這一問題是相當困難的。雖然當前有一定的進展，但實現用戶簡單輸入即可生成復雜報表和圖表的目標，還需要更多的技術突破和創新。

Q4：我想了解一下異構數據源融合的問題。我目前所在的公司使用的互聯互通工具并不好用，我想知道如何在一個腳本中實現異構數據源的簡單融合？

A4：確實，技術上是有可能實現異構數據源融合的，但實際業務場景中很少需要在一個 SQL 中同時關聯例如 ES（Elasticsearch）表和 MySQL 表。雖然理論上這種技術是存在的，但成本相對較高。我之前提到的 Starrocks 引擎可以查詢 Hive 數據，甚至直接連接 HDFS，其查詢速度比許多其他工具更快。它也可以查詢 MySQL 和 ES。但它并不支持同一次查詢中同時跨庫關聯查詢這些數據源。實際上，這種需求并不常見，也不需要花費太多時間去優化或實現。如果你們公司確實有大量異構數據源的融合需求，可能需要先從數據治理方面入手，找到更有效的方法和工具來解決這個問題。

Q5：您好，老師。我注意到您將報表制作成在線 Excel 格式。我想了解制作這種 Excel 功能的研發成本是否很高？因為它包含了許多復雜的功能和函數。同時，實際制作這個在線 Excel 的成本控制如何？

A5：是的，我們確實將報表制作成了在線 Excel 格式。不過，我們并沒有自己從頭開始研發這些復雜的功能和函數，而是主要通過集成一些第三方插件來實現的。因此，實際投入是可控的，成本并不會特別高。我們購買了第三方的插件，并在此基礎上將其與我們的前端鏈路相結合。這樣做的主要目的是模仿 Excel 的效果，同時確保工具的使用門檻對用戶來說更低，讓他們能夠更容易地操作和理解。

Q6：在數據產品領域，我們面臨哪些常見問題和挑戰？特別是關于 BI 工具和數據跨庫問題。

A6：這里主要有兩個問題。首先，關于 BI 工具，我們的定位是針對兩種不同的場景。京東內部已經有一些類似于 Tableau 的 BI 工具，它們適合總部的分析師和 BI 工程師使用，但對于一線工作人員來說，這些工具過于復雜，因為至少需要一定的數據庫操作和 SQL 知識。因此，我們針對兩種不同的用戶群體有不同的解決方案。

其次，關于數據跨庫的問題，我認為在數據建設上應該采用體系化的方法。所有業務系統都是分散和多樣化的。我們需要從業務系統中集中數據，建立一個數據部門或數據中心。首先是數據融合：將 OLTP（在線事務處理）轉換為 OLAP（在線分析處理），在數倉中集成數據后進行分析應用。理論上，我們應該將所有數據統一入倉，在數倉里分層建模，然后有標準化的口徑沉淀，再接入 BI 系統。這是最合理的鏈路。

我有兩個建議：第一個是標準化數據。從數倉定義好，盡可能全面地接入 BI 工具，以便它可以靈活地支持業務需求和變化。第二個建議是讓 BI 工具支持更多類似于低代碼可視化的組件，這樣業務方可以更靈活、豐富地搭建頁面，提高可視化能力。這樣的整體解決方案，包括嵌入式組件，可以嵌入到他們自己的業務系統中，減少將數據接過去處理后再定制頁面的成本。