京東集團 2007 年開始自建物流，2017 年 4 月正式成立京東物流集團，2021 年 5 月，京東物流于香港聯交所主板上市。京東物流是中國領先的技術驅動的供應鏈解決方案及物流服務商，以“技術驅動，引領全球高效流通和可持續(xù)發(fā)展”為使命，致力于成為全球最值得信賴的供應鏈基礎設施服務商。

基于 5G、人工智能、大數據、云計算及物聯網等底層技術，京東物流已經構建了一套全面的智能物流系統(tǒng)，實現服務自動化、運營數字化及決策智能化。截至 2021 年 12 月 31 日，京東物流在全國共運營 43 座“亞洲一號”大型智能倉庫。到 2021 年，京東物流已經擁有及正在申請的技術專利和計算機軟件版權超過 5500 項。京東物流在運營數字化及決策智能化過程中，實時化運營分析的業(yè)務需求越來越多，原有平臺架構中的數據孤島、查詢性能低、運維難度大、開發(fā)效率低等問題日益凸顯。在此背景下，京東物流基于 StarRocks 的聯邦查詢方案打造了 Udata 統(tǒng)一查詢引擎，高效解決了數據服務與數據分析的眾多痛點，大大降低了開發(fā)運維成本，解決了查詢引擎不統(tǒng)一和數據孤島，讓分析和服務不再分割。#01原有數據應用的痛點—數據服務與數據分析場景是數據應用的兩個大方向，數據工作從業(yè)者可能會遇到以下問題：

除了以上問題，數據服務和數據分析系統(tǒng)也無法統(tǒng)一，分析產生的數據結果往往是離線的，需要額外開發(fā)數據服務，無法快速轉化為線上服務賦能外部系統(tǒng)，使得分析和服務之間難以快速形成閉環(huán)。

而且在以往數據加工過程中存儲往往只考慮了當時的需求，當后續(xù)需求場景擴展，最初的存儲引擎可能不適用，導致一份數據針對不同的場景要存儲到不同的存儲引擎，帶來數據一致性隱患和成本浪費問題。

#02基于 StarRocks 的數據服務分析一體化實踐—

基于以上業(yè)務痛點，京東物流運營數據產品團隊研發(fā)了服務分析一體化平臺——Udata。Udata 系統(tǒng)是以 StarRocks 引擎為技術基礎實現的。Udata 把數據指標生成的過程抽象出來，用配置的方式低代碼化生成數據服務，大大降低了開發(fā)復雜性和難度，讓非研發(fā)同學也可以根據自己的需求配置和發(fā)布數據服務。指標的開發(fā)時間由之前的一兩天縮短為 30 分鐘，大大解放了研發(fā)力。

平臺化的指標管理體系和數據地圖的功能，讓用戶更加直觀和方便地查找與維護指標，同時也讓指標復用變成可能。在數據分析方面，我們用基于 StarRocks 的聯邦查詢方案打造了 Udata 統(tǒng)一查詢引擎，解決了查詢引擎不統(tǒng)一和數據孤島問題。

同時 StarRocks 提供了強悍的數據查詢性能，無論是大寬表還是多表關聯查詢性能都十分出色。StarRocks 提供數據實時攝入的能力和多種實時數據模型，可以很好支持數據實時更新場景。Udata 系統(tǒng)把分析和服務結合在一起，讓分析和服務不再是分割的兩個過程，用戶分析出有價值的數據后可以立即生成對應的數據服務，讓服務分析快速閉環(huán)。

改造前的數據流程架構：

此架構中，在數據服務和數據分析是兩個分隔的部分，分析工具由于要跨多數據源和不同的查詢語言做數據分析比較困難的，數據服務也是煙囪式開發(fā)。

改造后的數據流程架構：

后面我們又以 StarRocks 為基礎打造統(tǒng)一查詢引擎。統(tǒng)一查詢引擎根據京東的業(yè)務特點增加了數據源和聚合下推等功能，Udata 在統(tǒng)一查詢引擎的基礎上，統(tǒng)一了數據分析和數據服務功能。

打造一款數據服務分析一體化系統(tǒng)對查詢引擎有比較高的要求，需要同時滿足：極速的查詢性能、支持聯邦查詢、實時與離線存儲統(tǒng)一。基于這三點要求，接下來，我們就StarRocks 的極速查詢性能、我們對聯邦查詢的改造、實時場景的實踐展開討論。極速查詢的單表查詢StarRocks 在極速查詢方面上做了很多，下面著重介紹四點：1）向量化執(zhí)行：StarRocks 實現了從存儲層到查詢層的全面向量化執(zhí)行，這是 StarRocks 速度優(yōu)勢的基礎。向量化執(zhí)行充分發(fā)揮了 CPU 的處理能力。全面向量化引擎按照列式的方式組織和處理數據。StarRocks 的數據存儲、內存中數據的組織方式，以及 SQL 算子的計算方式，都是列式實現的。按列的數據組織也會更加充分利用 CPU 的 Cache，按列計算會有更少的虛函數調用以及更少的分支判斷，從而獲得更加充分的 CPU 指令流水。另一方面，StarRocks 的全面向量化引擎通過向量化算法充分利用了 CPU 提供的 SIMD 指令。這樣 StarRocks 可以用更少的指令數目，完成更多的數據操作。經過標準測試集的驗證，StarRocks 的全面向量化引擎可以將執(zhí)行算子的性能，整體提升 3-10 倍。2）物化視圖加速查詢：在實際分析場景中，我們經常遇到分析百億級大表的情況。盡管 StarRocks 性能優(yōu)異，但數據量過大對查詢速度還是有影響，此時在用戶經常聚合的維度加上物化視圖，在不改變查詢語句的情況下查詢速度能提升 10 倍以上。StarRocks 智能化的物化視圖可以讓請求自動匹配視圖，無需手動查詢視圖。3）CBO：CBO 優(yōu)化器(Cost-based Optimizer ) 采用 Cascades 框架，使用多種統(tǒng)計信息來完善成本估算，同時補充邏輯轉換（Transformation Rule）和物理實現（Implementation Rule）規(guī)則，能夠在數萬級別執(zhí)行計劃的搜索空間中，選擇成本最低的最優(yōu)執(zhí)行計劃。

4）自適應低基數優(yōu)化：StarRocks 可以自適應地根據數據分布，對低基數的字符串類型的列構建一張全局字典，用 Int 類型做存儲和查詢，使得內存開銷更小，有利于 SIMD 指令執(zhí)行，加快了查詢速度。ClickHouse 也有低基數優(yōu)化，只是在建表時候需要聲明，使用起來會麻煩一些。

極速的多表關聯在實時數據分析場景中只滿足單表極速查詢是不夠的。為了加速查詢速度，業(yè)內習慣于把多張表打成一張大寬表，大寬表雖速度快，但是帶來的問題是極其不靈活，實時數據加工層是用 Flink 將多表? Join 成一張表寫入大寬表。當業(yè)務方想修改或增加分析維度時，往往數據開發(fā)周期過長，數據加工完成后發(fā)現已經錯過了分析最佳時機。因此就需要更靈活的數據模型，把大寬表模式退歸回星型模型或者雪花模型是比較理想的方法。在此場景下，查詢引擎對多表數據關聯查詢的性能成了關鍵，以往 ClickHouse 以大寬表為主，多表聯查情況下無法保證查詢相應時間，甚至有很大幾率出現 OOM。StarRocks 很好解決了這個問題，大表 Join 性能提升 3-5 倍以上，成為星型模型分析利器。CBO 是多表關聯極致性能關鍵，同時 StarRocks 支持 Broadcost Join、Shuffle Join、Bucket shuffle Join、Colocated Join、Replicated Join 等多種 Join 方式，CBO 可以智能地選擇 Join 順序和 Join 方式。

StarRocks 在聯邦查詢上支持了多種外表如 ElasticSearch、MySQL、Hive、數據湖等，已經有了很好的聯邦查詢基礎。不過在實際的業(yè)務場景中，一些聚合類查詢需要從外部數據源拉取數據再聚合，加上這些數據源自身的聚合性能也不錯，反而增加了查詢時間。

我們的思路是，讓這部分擅長聚合的引擎自己做聚合，把聚合操作下推到外部引擎。目前符合這個優(yōu)化條件的引擎有：MySQL、ElasticSearch、ClickHouse。同時為了兼容更多的數據源，我們還增加了 JSF(京東內部 RPC 服務)/ HTTP 數據源，下面重點介紹下這兩部分：

MySQL、ElasticSearch 的聚合下推功能

現在 StarRocks 對于聚合外部數據源的方案是，拉取謂詞下推后的全量數據。雖然謂詞下推后已經過濾了一部分數據，但是把數據拉取到 StarRocks 再聚合是一個很重的操作，導致聚合時間不理想。我們選擇下推聚合操作，讓外部表引擎自己做聚合，節(jié)省數據拉取時間，同時本地化聚合效率更高。

首先看一個執(zhí)行計劃生成的過程：

我們在步驟 4 中對生成的物理執(zhí)行計劃再次優(yōu)化，當遇到 ElasticSearch 或者 MySQL 的聚合操作時，會把 ScanNode+AGGNode 的執(zhí)行計劃優(yōu)化為 QueryNode。QueryNode 為一種特殊的ScanNode，與普通 ScanNode 的區(qū)別在于， QueryNode 會把聚合查詢請求直接發(fā)送到對應外部引擎，而不是 Scan 數據后在本地執(zhí)行聚合。

其中，用到 ElasticSearch QueryNode 時，我們會在 FE 端就生成 ElasticSearch 查詢的 DSL 語句，直接下推到 BE 端查詢 。同時在 BE 端，我們實現了 ElasticSearch QueryNode 和 MySQL QueryNode 這兩種 QueryNode。我們也為這個 feature 設置了 agg_push_down 的開關，默認是關閉的。

參考下圖查詢語句，下方是來自 ElasticSearch 和 MySQL 的兩個數據源聚合后 Join 查詢的 SQL。原先的執(zhí)行計劃需要從數據源 Scan 大量數據后本地聚合，優(yōu)化后去掉了這部分 Scan 和聚合的過程，直接拿到聚合后的數據。

上述 SQL 在優(yōu)化后生成的執(zhí)行計劃變化如下：

增加 JSF(京東內部 RPC 服務)/ HTTP 數據源

數據服務中可能會涉及到整合外部數據服務和復用原先已開發(fā)指標的場景。我們的思路是，把JSF(京東內部 RPC 服務)/ HTTP 也抽象成 StarRocks 的外部表，用戶可以通過 SQL 像查詢數據庫一樣訪問數據服務。

這樣不僅可以復用老的指標，還可以結合其他數據源的數據，生成新的復合指標。我們在 FE 和 BE 端同時增加 JSF 和 HTTP 兩種 ScanNode。京東物流實時數據絕大多數屬于更新場景，運單類數據會根據業(yè)務狀態(tài)的改變而改變，下面介紹我們在生產中的三種實時更新方案：

基于 ElasticSearch 的實時更新方案

基于 ClickHouse 實現準實時的方案

基于 StarRocks 主鍵模型的實時更新方案實時更新場景總的來說有以下幾種方案：

1）Merge on read ：StarRocks 的聚合、Unique 模型和 ClickHouse 的ReplacingMergeTree、AggregatingMergeTree 都是用的此方案。此方案特點是 Append 方式寫入性能好，但是查詢時需要合并多版本數據，導致查詢性能不佳。適合數據查詢性能要求不高的實時分析場景。

2）Copy on write ：目前一些數據湖系統(tǒng)如 Apache Hudi、Apache Iceberg 都有 Copy on write 的方案。此方案原理是，當有更新數據后，會合并新老數據并重寫一份新的文件替換掉老文件，查詢時無需做 Merge 操作，所以查詢性能很好。帶來的問題是，寫入和合并數據的操作很重，所以此方案不適合實時性強的寫入場景。

3）Delete and insert：此方案是 Upsert 方案，通過內存中的主鍵索引定位要更新的行，標記刪除然后插入。在犧牲了部分寫入性能的情況下，帶來數倍于 Merge on read 的查詢性能提升，同時也提升了并發(fā)性能。

實時更新在 OLAP 領域一直是一個技術難點，以往的解決方案很難同時具備寫入性能好、讀取性能好、使用簡單這幾個特性。StarRocks 的 Delete and insert 方式目前更接近于理想的方案，在讀寫方面都有很優(yōu)秀的性能，在支持 MySQL 協(xié)議方面非常簡單友好。同時 Udata 的離線分析也是用 StarRocks 完成，讓京東物流實現了實時離線分析一體化的目標。

#03后續(xù)方向與展望—數據湖探索批流一體已經成為今后發(fā)展的大趨勢，數據湖作為批流一體的存儲載體已經成為標準，我們以后大方向也必然是批流一體。目前批流一體中一個大痛點問題是沒有一種查詢引擎可以在數據湖上做極速查詢，后期我們會借助SR打造在湖上的極速分析能力，讓批流一體不只停留在計算階段。

架構圖如下：

實時數據存儲統(tǒng)一

目前系統(tǒng)中有多套實時存儲方案，運維成本還是相當高，我們會逐步把 ElasticSearch、ClickHouse 替換為 StarRocks，在實時層做到存儲統(tǒng)一。我們也很期待 StarRocks 后期關于主鍵模型支持 Detele 語句方式刪除數據的功能，從而可以解決目前的數據清除問題。

支持更多的數據源

今后我們還會支持更多的數據源，如 Redis、Apache HBase 等 KV 類型的 NoSQL 數據庫，增強 StarRocks 的點查能力。

StarRocks 集群間的聯邦查詢在實際生產中很難做到只用一個大集群，特別是當有大量實時寫入的情況，比較安全的做法是拆分不同的小集群，當一個集群出問題時不會影響其他業(yè)務。但是帶來的問題是，集群間可能又會變?yōu)閿祿聧u，即便把 StarRocks 偽裝成 MySQL 創(chuàng)建外表，但也需要工具去同步各個集群的表結構等信息，管理起來費時費力。

后續(xù)我們也會和社區(qū)討論如何實現集群間的聯邦功能，如果有對此感興趣的社區(qū)小伙伴也可以一起來參與共建。

資源隔離

StarRocks 在 2.2 版本開始推出資源組的功能，可以有效隔離大小查詢負荷，后續(xù)還會在大查詢熔斷、導入和查詢負荷資源隔離方面推出更多功能。因此，一些體量較小的業(yè)務混合在同一集群上通過資源隔離的形式運行，將成為可能。

StarRocks 是一款十分優(yōu)秀的 OLAP 數據庫產品，在社區(qū)小伙伴的幫助下，我們解決了很多技術難題。在這里感謝 StarRocks 社區(qū)，我們后續(xù)也會大力參與社區(qū)建設，并希望能有更多的小伙伴參與到 StarRocks 社區(qū)共建中來！

在文末分享、點贊、在看，給個3連擊唄~

01/關于StarRocks

關于 StarRocks

StarRocks 創(chuàng)立兩年多來，一直專注打造世界頂級的新一代極速全場景 MPP 數據庫，幫助企業(yè)建立“極速統(tǒng)一”的數據分析新范式，助力企業(yè)全面數字化經營。

當前已經幫助騰訊、攜程、順豐、Airbnb 、滴滴、京東、眾安保險等超過 110 家大型用戶構建了全新的數據分析能力，生產環(huán)境中穩(wěn)定運行的 StarRocks 服務器數目達數千臺。

2021 年 9 月，StarRocks 源代碼開放，在 Github 上的星數已超過 3000 個。StarRocks 的全球社區(qū)飛速成長，至今已有超百位貢獻者，社群用戶突破 5000 人，吸引幾十家國內外行業(yè)頭部企業(yè)參與共建。