京東物流基於 StarRocks 的數據分析平台建設

作者：京東物流 數據專家 劉敬斌

小編導讀：

京東集團 2007 年開始自建物流，2017 年 4 月正式成立京東物流集團，截至目前，京東物流已經構建了一套全面的智慧物流系統，實作服務自動化、營運數位化及決策智慧化。

京東物流在營運數位化及決策智慧化過程中，即時化營運分析的業務需求越來越多，原有平台架構中的數據孤島、查詢效能低、運維難度大、開發效率低等問題日益凸顯。2022 年，京東物流基於 StarRocks 打造了 Udata 統一查詢引擎，高效解決了數據服務與數據分析的眾多痛點。

近兩年來，京東物流在 StarRocks 的使用中不斷進行效能提升最佳化，取得了良好的效果。在 StarRocks Summit 2023 上，京東物流數據專家劉敬斌為大家介紹了 StarRocks 的套用經驗，並重點分享了湖倉查詢的最佳化經驗和效果。另外，據劉敬斌介紹，在 2023 年京東雙十一大促期間，京東物流 StarRocks 集群規模已經達到了 3 萬核以上。

京東物流的用數特征和痛點

一個企業的業務特征決定了使用者的用數習慣，而用數習慣往往會演變出一些用數痛點，在京東物流的數據分析服務場景中存在 4 大痛點。

01

在我們的業務場景中，當一個訂單從商城域進入物流域後，會經過很多環節，從倉儲到分揀，再到配送、拓投，鏈條非常長，中間系統特別多，數據也比較多，各個系統產生的數據被儲存到各種各樣的異構儲存裏，一線營運人員在找數據時存在一定困難。

02

京東物流劃分了很多省區，每個省區都有自己的營運策略，一線營運人員各自都有不同的做數方法論去適配自己的營運策略，而數據分析平台目前面對的使用者大部份都是一線營運人員，數據需求千人千面，此外我們還希望讓營運人員能像使用 Excel 一樣的去使用大數據，降低大數據使用門檻，這也是我們面臨的重要任務。

03

Hadoop 平台把數據算出來之後，一線營運人員透過內部的雲盤系統，將數據下載到本地，然後匯入到本地 Excel，這種用數模式存在一些問題：

04

報表生成之後，有時需要互相傳閱，在 Excel 非常多的情況下，大家互相傳輸，有時會用到一些線下的傳輸工具，導致數據來源不明晰，由於傳輸過程中有很多人工參與，協同比較困難，數據的時效性、安全性都得不到保障，並且存在大量重復性工作，效能體驗非常差。

基於 StarRocks 的解決方案

京東物流 Udata 裏面關於數據分析服務有兩個概念：

01

在數據分析場景中，我們要解決 4 個問題：

找數， 營運人員對業務非常了解，他們的需求和業務語意比較貼近，但是數據保存在大資料庫，和研發人員更加貼近，這中間不可避免存在割裂，如何讓營運人員用業務語意去找到對應的數據表？我們會把數據以指標表維度打上業務標簽，建立數據檢視，讓一線找數的人員可以按照業務視角，透過圖資料庫的數據血緣關系快速找到想要的數。

做數， 一線營運人員對於決策非常了解，但是如何生成 SQL？Udata 透過無程式碼點選式的方式來讓一線使用者只需線上拖拖拽拽，就能將業務意圖轉譯成 SQL 語句。 我們希望構建覆蓋京東生態全部資料來源的接入能力，讓使用者可以隨時隨地查詢各種各樣的數據，StarRocks 強大的聯邦查詢能力起到了非常關鍵的作用。

用數， 借助 Udata 的線上 Excel 能力，實作了將線下報表快速遷移到線上的方案，並且報表一次配置永久生效，透過 StarRocks 包括物化檢視在內的一些高級特性，可以高效地得到查詢結果。

協同， 當報表線上化之後，能夠透過連結、信件等方式實作 PC 和移動端隨時隨地看數的目標。

02

物流的業務發展比較快，當角色發生變化後，業務管理者需要及時看到數據，這對於數據的交付要求越來越高。一方面，數據的效能要求很高，另一方面，數據的可復用性比較低，因此我們需要投入更多的研發資源來應付大量的數據需求。

基於 StarRocks，我們得以透過界面的方式快速地開發數據服務介面。目前已經在很多場景套用了數據服務快速開發能力，基本能達到當日交付的響應速度。與傳統方式相比，數據資產變現效率提升了 5 倍，開發成本降低了 80%，支持了我們很多的業務。

Udata 數據分析平台

01

圖中是 Udata 數據分析平台的產品設計，從下往上看分為 4 個部份：

資料來源 ， 現在可以相容的資料來源包括 MySQL、Elasticsearch、ClickHouse、Hive 等,還有一些 API，覆蓋了京東大部份資料來源，完成了京東生態對接；

底層引擎， 基於 StarRocks 打造，資料來源會以外表掛載形式接入到查詢引擎，底層的查詢引擎分為兩層：

產品功能， 從數據接入到數據管理、數據使用，以及數據介面編排、線上 Excel，涵蓋了數據的生命周期，解決了找數用數的問題。

數據賦能， 主要透過數據分析和數據服務來對外賦能，支持的業務場景包含報表分析、辦公協同、數據探索、指標監控、數據大屏等等。

02

圖中為湖倉新範式下數據全景圖，從下往上看分為 4 層：

為什麽選擇 StarRocks

每個公司選擇分析型資料庫產品時都有很多關註點，我們主要關註的是即時性、套用性、靈活性、效能、生態等 5 個方面，StarRocks 在這些方面的表現都非常優秀，聯邦查詢、湖倉一體查詢、即時更新等特性完全符合我們的需求，其中，湖倉一體查詢是我們現在的主打方向。

因為一些歷史原因，京東采用了很多 Elastics e arch ， Elastics e arch 在搜尋和倒排索引方面非常優秀，用來進行數據分析卻可能不太適合，我們曾經接到過一個業務需求，需要從 Elastics e arch 把數據和業務遷移到 StarRocks，當時的集群規模約 800 CPU 左右，數據量約 2.5 TB，查詢 QPS 大約 10， 在業務同等滿足的情況下， Elastics e arch 的 CPU 使用率高達70%，基本上無法再提供別的服務，StarRocks 的 CPU 使用率則在 30% 以下。 顯然，StarRocks 在主建模型和批次更新的加持之下，比 Elastics e arch 更適合這種數據分析。

StarRocks 的效能提升最佳化和效果

在 StarRocks 的使用中，我們進行了一些效能提升，其中對湖倉查詢的效能最佳化尤為重視。我們的湖主要是 Hive，關於 Hive 的查詢，首先 HDFS 需要快速的檔存取能力，其次後設資料的拉取也要足夠快，另外基於 CBO 的查詢最佳化也非常關鍵，尤其在進行 Join 查詢時，更加需要采用最優的執行計劃。

01

跨集群查詢時，需要從另外一個集群裏面拉取大量數據，網路開銷比較多，所以針對有計算能力的外表引擎，我們進行了計算下推，就是把類似於 group by、limit 的聚合計算盡可能推到外表引擎上去，直接從跨級群拿到的是外表引擎裏面已經計算後的結果，數據量會顯著下降。

02

數據分區分桶是 Hive 非常重要的特性，可以在查詢時盡可能掃描更少的數據。在實際使用中，有些使用者不太了解 Hive 裏的分區鍵和列有哪些關系，對此，我們透過檢查使用者的 SQL 語句，幫助使用者盡量將 Hive 的分區列套用到 SQL 裏，這是我們對於湖的一個最佳化。

存取 HDFS 會帶來遠端 I/O 消耗，我們透過 data cache 減少了這部份效能開銷。此外，第一次查詢時因為要拉取大量的後設資料，也會導致一些效能開銷，而我們有一些表特別大，有分時區達到上百萬，這也是我們在解決的一個問題，我們讓 Hive 後設資料的更新以事件通知到 FE，觸發 FE 主動更新緩存，從而使第一次查詢也能比較快。與此同時，我們還對 FE 裏的 hive meta cache size、ttl 等也進行了改造。另外，我們把 Hive 裏的一些大分區表盡也可能地進行了治理。

03

當 HDFS 集群有大量任務時，查詢效能會有一些抖動，對此我們進行了 Heged read 的最佳化，最佳化之後效果非常顯著。另外我們也希望在離線的湖上面的查詢進行一些物化檢視的加速。

04

Hive 上的數據都特別大，有時一次查詢會占上百 G 的數據，甚至可能把集群的資源全部占用，為了避免這種情況，我們進行了一些防護，比如限制 Hive 分區數目、限制掃描的 HDFS 檔大小，對查詢時間較長、CPU 占用較高的一些大查詢進行熔斷。

經過這些改造，目前京東物流已經落地的 Udata 產品做到了數據使用從線下到線上的轉變。現在數據使用實作了透明化、安全化，使用過程中沒有人為參與因素，查詢效能也比較高。

05

今年雙十一大促期間，我們的數據查詢 QPS 最高達到 150，相比平時呈幾倍增長，並且通常要從海量數據裏面進行查詢，在 QPS 150 的情況下，掃描數據的峰值高達 300G 每秒，每秒掃描的數據行數達 95 億行。對於數據寫入，RPS 基本上是 40，數據寫入峰值達 4.2G 每秒，每秒寫入 234 萬行。 大促期間，StarRocks 集群規模已經達到了 3 萬核以上。

未來規劃探索

01

我們目前采用的是混合架構，查詢引擎多而全，本地表和外表共存，未來希望從這種架構遷移到存算分離架構，使計算可以彈性擴充套件，數據儲存分而治之。

02

我們希望當 Hive 裏的數據、Hadoop 裏的數據發生變化之後，能夠快速查詢最新數據，現在也在考慮如何讓 Hive 的數據更新及時通知 FE 進行更新，同時盡量消除即時更新帶來的效能影響。

03

對於我們來說,數據湖的數據量都比較大，帶來的網路開銷非常大，另外後設資料的效能開銷也會影查詢體驗，現在我們在積極地嘗試包含 data cache 在內的方式來減少遠端 I/O，同時采用物化檢視加速查詢，此外我們還在探索包括 Paimon、Hudi 在內的多種異構湖儲存。

關於 StarRocks

Linux 基金會計畫 StarRocks 是數據分析新範式的開創者、新標準的領導者。面世三年來，StarRocks 一直專註打造世界頂級的新一代極速全場景 MPP 資料庫， 幫助企業構建極速統一的湖倉分析新範式，是實作數位化轉型和降本增效的關鍵基礎設施。

StarRocks 持續突破既有框架，以技術創新全面驅動使用者業務發展。當前全球超過 330 家市值 70 億元以上的頭部企業都在基於 StarRocks 構建新一代數據分析能力，包括騰訊、攜程、平安銀行、中原銀行、中信建投、招商證券、大潤發、百草味、順豐、京東物流、TCL、OPPO 等，並與全球雲端運算領導者亞馬遜雲、阿裏雲、騰訊雲等達成戰略合作夥伴。

擁抱開源，StarRocks 全球開源社群飛速成長。目前，已有超過 300 位貢獻者，社群使用者近萬人，吸引幾十家國內外行業頭部企業參與共建。計畫在 GitHub 星數已超 7200 個，成為年度開源熱力值增速第一的計畫，市場滲透率躋身中國前十名。

金融： ｜ | | |

互聯網： ｜

遊戲： |

新經濟： ｜ | ｜

StarRocks 技術內幕： ｜ ｜ ｜ ｜ ｜ ｜