作者 | 達達快送大數據運維數據庫工程師 劉明

達達快送是達達集團旗下中國領先的本地即時配送平臺，與傳統物流相比，即時配送具有速度快、效率高、服務范圍廣等優勢。為了提高數據分析的效率，達達先后在 OLAP 層引進了 Apache Kylin、Elasticsearch、Apache Druid、ClickHouse 和 Apache Doris 等組件。在綜合考量查詢性能、系統穩定性以及社區活躍度等因素后，達達最終選擇了 StarRocks 作為統一的 OLAP 引擎。這一決策不僅使物理機器成本降低了 30%，還大幅提高了數據開發效率，在某些場景下查詢性能提升了 10 倍以上。在應用方面，達達基于 StarRocks 構建實時數倉和流批一體的計算，通過離線和實時數據處理鏈路整合訂單數據、庫存數據、配送時間、配送路線、配送員信息、客戶數據等，并且將業務分析響應時間時間從原本的分鐘級降低至秒級。接下來，達達也計劃將解鎖 StarRocks 存算分離架構以持續降本增效，并利用 StarRocks 的湖倉分離能力一同構建湖倉分離新范式完成數據分析的再進化！

達達集團是中國領先的本地即時零售與配送平臺（納斯達克股票代碼：DADA）。以“萬千好物，即時可得”為愿景，引領中國零售業步入新時代。旗下有達達快送和京東到家兩大核心業務平臺。

達達快送是達達集團旗下中國領先的本地即時配送平臺，以眾包為核心運力模式，搭建起由即時配、落地配、個人配構成的全場景服務體系，服務于各行業知名企業、中小企業與個人用戶，經過長期的模式創新和技術迭代，達達快送可為商家提供全渠道訂單一體化履約服務。

京東到家是達達集團旗下中國領先的本地即時零售平臺，依托達達快送和零售合作伙伴，為消費者提供超市便利、生鮮果蔬、醫藥健康、3C 家電、鮮花綠植、蛋糕美食、服飾運動、家居時尚、個護美妝等海量商品約1小時配送到家的即時消費服務體驗。目前，達達快送業務累計覆蓋全國 2700 多個縣區市，京東到家業務累計覆蓋全國超 2000 個縣區市。

一、OLAP 分析從“復雜多弱”走向“極速統一”

隨著國內大數據架構技術的不斷演進，達達快速構建了以 Apache Hive 和 Apache Spark 為核心的離線數據倉庫，以及以 Apache Flink 和 Apache Kafka 為核心的實時數據處理鏈路。在業務發展和整體架構的不斷迭代過程中，我們嘗試了不同時期出現的優秀 OLAP 產品來解決我們在數據分析中對查詢加速的需求。

在解決多維分析和 BI 報表場景時，我們嘗試了 Apache Kylin。然而，Kylin 過于依賴 Cube 預計算 ，導致在數據源變化時需要重新計算，無法自動同步更新。當統計維度發生變化時，必須耗費大量計算資源和人力成本來重建歷史數據。這種提前定義和預計算數據方案限制了靈活的數據建模能力，尤其在維度較多的情況下，數據膨脹問題嚴重。

為了彌補 Kylin 的不足，我們采用 Elasticsearch 作為維度數據存儲引擎，同時使用 Apache Druid 作為存儲和查詢大量事實數據的混合解決方案。然而，隨著數據量和業務需求的增加，查詢響應速度變慢的問題變得更加明顯。在這過程中，我們引入了 Clickhouse，它具備出色的數據壓縮能力、列式存儲和向量化引擎，在單機寬表的查詢性能很強悍，可惜多表 Join 的能力和分布式集群模式下的在線擴展能力表現差強人意。

圖片

隨著引入的組件逐漸增多，技術棧變得復雜，大數據整體架構變得龐大，導致運維成本居高不下，難以確保服務質量。開發人員還需要根據不同的場景選擇不同的組件，而 SQL 支持的差異性也增加了開發的難度。數據分散多份，無法有效的貫徹數倉 OneData 的建設要求。

雖然許多組件都有各自的優勢，但基本上都存在開發靈活性不足、查詢性能較低、查詢并發能力弱、服務不穩定、實時性不足等問題。在當前迫切需要降本增效的形勢下，StarRocks 的及時出現讓這些問題迎刃而解，也為后續的架構優化確定了方向。

最開始我們使用的是 Apache Doris 0.14 版本，從整體查詢性能、系統穩定性、社區優秀的服務支持角度考慮，最終我們轉向使用 StarRocks。在進行整體集群遷移前，我們對 Apache Doris 0.14、StarRocks 2.4.1 在同等集群規模下，進行了一些基準測試驗證（ SSB、SSB-FLAT、SSB-低基數 Query、TPC-H 100G 的標準測試集）：

圖片

圖片

StarRocks 在標準 SQL 支持、MySQL 協議兼容性、離線/實時導入、聚合查詢、明細查詢、Adhoc 查詢、主鍵模型索引落盤以及部分列更新等方面表現符合達達快送對新一代數倉的期待，在開發成本、運維成本方面能取得良好的平衡。我們使用 StarRocks 取代了原有架構中的 Apache Kylin、Apache Druid 和 Clickhouse，同時調整了 Elasticsearch 的組件功能，有效解決了之前在 OLAP 分析層面臨的大部分問題。這一系列調整不僅降低了 30% 的物理機器成本，還顯著提升了數據開發效率。

我們一直堅持降低成本、提高效率的目標，對查詢性能和系統穩定性也提出了更高的要求。隨著 StarRocks 主鍵模型對主鍵索引落盤的全面支持，我們投入了一個季度的時間，成功將位于京東云上的所有業務遷移至 StarRocks 平臺，并已持續升級至 2.5.5 版本。在 OLAP 分析層，我們的技術棧已經基本實現了統一。

二、StarRocks 在達達快送的應用

1.基于 StarRocks MV 構建實時數倉

在構建實時數倉時，我們在離線數倉的基礎上，巧妙地將 StarRocks 與 Apache Hive 集群以及我們自研的任務調度平臺相結合。實時數倉的數據源涵蓋了離線數倉、MySQL、APP 埋點數據以及實時日志數據。我們充分利用了 StarRocks 異步多表物化視圖的特性，對數倉進行了分層處理，經過各層的數據加工和處理，最終為各個場景提供了統一的數據服務。

圖片

得益于 StarRocks 的單表實時 MV 和多表異步 MV 的 ETL 處理能力，不僅加速了整個數據鏈路的 ETL 過程， 而且以 StarRocks 為基座實現了與離線數倉對等分層的實時數倉。

在我們的架構中，ODS、DWD 和 DWM 層都充分運用了物化視圖。基于單表實時物化視圖，例如在“多級區域訂單”的實時看板場景中，我們根據不同的行政區域劃分層級進行物化視圖的創建。在 ETL 過程中，多表異步 MV 扮演關鍵角色，許多任務的刷新頻率達到每 5 分鐘一次。以“訂單退單”的場景為例，Flink 將數據匯入 ODS 層的數張基礎表，然后通過異步 MV 構建到 DWD 層，接著在 DWD 層中與其他所需的事實表和維度表再次構建 MV，最終落到 DWM 層。

借助物化視圖的構建，我們成功將業務查詢響應時間從分鐘級提升到秒級。對于那些需要風險控制和及時干預決策的場景，更快的查詢結果返回意味著更快地發現問題，從而迅速引發運營的及時介入與干預。

2.基于 StarRocks 的流批一體計算

隨著移動互聯網的廣泛普及、O2O 模式的爆發以及新零售的崛起，一個與傳統物流快送行業完全不同的新型配送模式正悄然興起，并逐步趨于成熟。即時配送是一種無中轉、點對點的快速準時送達服務。其服務場景主要包括外賣、B2C 零售、商超便利、生鮮宅配、快遞末端派送、C2C 配送等需求，配送距離通常在 5 公里以內，覆蓋范圍緊扣消費者的生活圈。

即時配送對時效性要求極高，通常以分鐘為單位來衡量，訂單的服務時長在 1 小時內完成，而在不同情境下，往往可以在半小時內完成送達。另一個角度來看，即時配送訂單呈現出的另一特點是服務需求的不連續性，或者說是非計劃性的消費需求，這導致訂單數量的波動性極大。以外賣訂單為例，全天訂單量分布呈現明顯的波峰和波谷，高峰值的訂單密集度較高。

通過充分利用 StarRocks 在多種數據源場景下的不同導入方式，我們能夠將實時數據與離線數據有機地結合在 StarRocks 中進行 ETL 處理與加工。

圖片

達達快送使用基于實時環境下的配送區域動態網格統計計算，整合訂單數據，對歷史軌跡數據、行駛區域數據、配送業務數據、實時訂單數據、騎手軌跡數據、庫存數據、配送時間、配送路線、配送員信息、客戶數據等以及與配送相關的特征和指標數據等進行精準迅速的流批一體數據計算。

借助 StarRocks 的實時更新列式存儲引擎、全面向量化引擎、全新的基于代價的優化器 （CBO）、實時物化視圖的能力，我們將實時運單流與區域網格數據的關聯匹配，查詢計算從分鐘級別提升到了秒級別。在區域訂運單狀態統計場景中，有效提升了分析效率和用戶體驗。

3.基于 StarRocks 外部表的“讀寫分離”

在當前的 2.5 版本中，StarRocks 采用資源組（Resource Group）的方式來實現資源隔離，限制了查詢對資源的消耗，從而實現了多租戶之間的資源隔離和合理利用。但這種資源組的方式是對內存的硬隔離，對 CPU 和 I/O 的軟隔離。對于我們的情況——離線數據通過 Hive+Spark 批處理后以 T+1 的方式通過 broker load 導入 StarRocks，實時數據通過 Flink 消費 Kafka，然后通過 routine load 導入 StarRocks。當實時數據導入任務較多時，會造成較大的資源消耗，在現有集群規模下可能會對業務查詢產生一定影響。

為了解決這個問題，我們借助了 StarRocks 外部表的能力，構建了“讀寫分離”模式的集群。舉例來說，我們多個業務功能的 StarRocks 集群主要負責各自數據的加工與寫入，在面向報表查詢的服務集群中會創建連接若干不同集群的 StarRocks 外表。這樣做帶來了多種好處，比如數據源保持一致，讀寫壓力在一定程度上分離，從而提升了業務的使用體驗。同時，我們也根據不同的業務功能群（包括業務等級）劃分并建設了多個 StarRocks 集群，這在一定程度上也間接解決了資源隔離和爭用的問題，當然，這也可能會帶來相對較高的資源成本。

在未來的 StarRocks 3.2 版本中將會支持存算一體架構下的主備集群能力，以及存算分離架構下的多倉庫（multi-warehouse）能力，這將完美解決讀寫分離的問題。

三、后續發展與計劃

1.解鎖存算分離持續降本增效

在今年 4 月發布的 StarRocks 3.0 版本中，StarRocks 推出了新的存算分離架構，且在這個月發布的 StarRocks 3.1 版本中，這一架構得到了進一步的加強，支持了主鍵模型表，并且引入了算子落盤的能力。

從 StarRocks 社區提供的數據看來，存算分離架構保持了 StarRocks 存算一體模式下強悍的查詢性能。下圖展示了在 TPC-DS 1TB 數據集規模下存算分離和存算一體的性能測試結果：

圖片

圖片

標準數據集結果顯示：

1.在 cache 全命中的條件下，存算分離性能與存算一體查詢性能幾乎保持一致

2.即使在 cache 完全 miss 情況下，查詢性能下降也在可接受的范圍內

在這個 SAAS 時代，達達也會積極的依托京東云，積極利用 StarRocks 的存算分離能力，不斷推動降本增效的進程。

2.從數倉到湖倉一體的進化

接下來，我們會逐步遷移我們在 OLTP 庫上的 OLAP 分析業務。同時也會積極推動 Presto 查詢場景向 StarRocks 遷移，完成數倉到湖倉一體的進化。

我們會基于 StarRocks 3.0 的另外一個重要能力——湖倉融合一體化的能力來簡化數據分析。數據可以直接入倉分析，也可以寫入數據湖后由 StarRocks 直接分析湖上數據，無需做數據遷移；通過物化視圖的能力，可以將湖上的數據寫入到數倉里加速查詢，數倉的計算結果可以再寫回數據湖，實現湖倉的無縫融合。

圖片

StarRocks 直接分析數據比 Trino 平均快 3-5 倍，大幅提升整體的性價比。為了能更方便的從 Trino 到 StarRocks 升級，降低其分析成本，StarRocks 提供了 Trino SQL 語法兼容的能力，將 Trino SQL 自動改寫成 StarRocks 的 AST，充分利用了 StarRocks 的高性能執行引擎。

圖片

最后，我們要感謝 StarRocks 社區在達達 OLAP 極速統一上所提供的支持。未來，我們也希望利用 StarRocks 不斷提升的能力完成湖倉一體的統一。祝福 StarRocks 開源社區繁榮發展，更上一層樓！