作者 | 達(dá)達(dá)快送大數(shù)據(jù)運(yùn)維數(shù)據(jù)庫工程師 劉明

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

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

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

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

一、OLAP 分析從“復(fù)雜多弱”走向“極速統(tǒng)一”

隨著國內(nèi)大數(shù)據(jù)架構(gòu)技術(shù)的不斷演進(jìn)，達(dá)達(dá)快速構(gòu)建了以 Apache Hive 和 Apache Spark 為核心的離線數(shù)據(jù)倉庫，以及以 Apache Flink 和 Apache Kafka 為核心的實(shí)時數(shù)據(jù)處理鏈路。在業(yè)務(wù)發(fā)展和整體架構(gòu)的不斷迭代過程中，我們嘗試了不同時期出現(xiàn)的優(yōu)秀 OLAP 產(chǎn)品來解決我們在數(shù)據(jù)分析中對查詢加速的需求。

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

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

圖片

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

雖然許多組件都有各自的優(yōu)勢，但基本上都存在開發(fā)靈活性不足、查詢性能較低、查詢并發(fā)能力弱、服務(wù)不穩(wěn)定、實(shí)時性不足等問題。在當(dāng)前迫切需要降本增效的形勢下，StarRocks 的及時出現(xiàn)讓這些問題迎刃而解，也為后續(xù)的架構(gòu)優(yōu)化確定了方向。

最開始我們使用的是 Apache Doris 0.14 版本，從整體查詢性能、系統(tǒng)穩(wěn)定性、社區(qū)優(yōu)秀的服務(wù)支持角度考慮，最終我們轉(zhuǎn)向使用 StarRocks。在進(jìn)行整體集群遷移前，我們對 Apache Doris 0.14、StarRocks 2.4.1 在同等集群規(guī)模下，進(jìn)行了一些基準(zhǔn)測試驗(yàn)證（ SSB、SSB-FLAT、SSB-低基數(shù) Query、TPC-H 100G 的標(biāo)準(zhǔn)測試集）：

圖片

圖片

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

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

二、StarRocks 在達(dá)達(dá)快送的應(yīng)用

1.基于 StarRocks MV 構(gòu)建實(shí)時數(shù)倉

在構(gòu)建實(shí)時數(shù)倉時，我們在離線數(shù)倉的基礎(chǔ)上，巧妙地將 StarRocks 與 Apache Hive 集群以及我們自研的任務(wù)調(diào)度平臺相結(jié)合。實(shí)時數(shù)倉的數(shù)據(jù)源涵蓋了離線數(shù)倉、MySQL、APP 埋點(diǎn)數(shù)據(jù)以及實(shí)時日志數(shù)據(jù)。我們充分利用了 StarRocks 異步多表物化視圖的特性，對數(shù)倉進(jìn)行了分層處理，經(jīng)過各層的數(shù)據(jù)加工和處理，最終為各個場景提供了統(tǒng)一的數(shù)據(jù)服務(wù)。

圖片

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

在我們的架構(gòu)中，ODS、DWD 和 DWM 層都充分運(yùn)用了物化視圖?；趩伪韺?shí)時物化視圖，例如在“多級區(qū)域訂單”的實(shí)時看板場景中，我們根據(jù)不同的行政區(qū)域劃分層級進(jìn)行物化視圖的創(chuàng)建。在 ETL 過程中，多表異步 MV 扮演關(guān)鍵角色，許多任務(wù)的刷新頻率達(dá)到每 5 分鐘一次。以“訂單退單”的場景為例，F(xiàn)link 將數(shù)據(jù)匯入 ODS 層的數(shù)張基礎(chǔ)表，然后通過異步 MV 構(gòu)建到 DWD 層，接著在 DWD 層中與其他所需的事實(shí)表和維度表再次構(gòu)建 MV，最終落到 DWM 層。

借助物化視圖的構(gòu)建，我們成功將業(yè)務(wù)查詢響應(yīng)時間從分鐘級提升到秒級。對于那些需要風(fēng)險控制和及時干預(yù)決策的場景，更快的查詢結(jié)果返回意味著更快地發(fā)現(xiàn)問題，從而迅速引發(fā)運(yùn)營的及時介入與干預(yù)。

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

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

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

通過充分利用 StarRocks 在多種數(shù)據(jù)源場景下的不同導(dǎo)入方式，我們能夠?qū)?shí)時數(shù)據(jù)與離線數(shù)據(jù)有機(jī)地結(jié)合在 StarRocks 中進(jìn)行 ETL 處理與加工。

圖片

達(dá)達(dá)快送使用基于實(shí)時環(huán)境下的配送區(qū)域動態(tài)網(wǎng)格統(tǒng)計計算，整合訂單數(shù)據(jù)，對歷史軌跡數(shù)據(jù)、行駛區(qū)域數(shù)據(jù)、配送業(yè)務(wù)數(shù)據(jù)、實(shí)時訂單數(shù)據(jù)、騎手軌跡數(shù)據(jù)、庫存數(shù)據(jù)、配送時間、配送路線、配送員信息、客戶數(shù)據(jù)等以及與配送相關(guān)的特征和指標(biāo)數(shù)據(jù)等進(jìn)行精準(zhǔn)迅速的流批一體數(shù)據(jù)計算。

借助 StarRocks 的實(shí)時更新列式存儲引擎、全面向量化引擎、全新的基于代價的優(yōu)化器 （CBO）、實(shí)時物化視圖的能力，我們將實(shí)時運(yùn)單流與區(qū)域網(wǎng)格數(shù)據(jù)的關(guān)聯(lián)匹配，查詢計算從分鐘級別提升到了秒級別。在區(qū)域訂運(yùn)單狀態(tài)統(tǒng)計場景中，有效提升了分析效率和用戶體驗(yàn)。

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

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

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

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

三、后續(xù)發(fā)展與計劃

1.解鎖存算分離持續(xù)降本增效

在今年 4 月發(fā)布的 StarRocks 3.0 版本中，StarRocks 推出了新的存算分離架構(gòu)，且在這個月發(fā)布的 StarRocks 3.1 版本中，這一架構(gòu)得到了進(jìn)一步的加強(qiáng)，支持了主鍵模型表，并且引入了算子落盤的能力。

從 StarRocks 社區(qū)提供的數(shù)據(jù)看來，存算分離架構(gòu)保持了 StarRocks 存算一體模式下強(qiáng)悍的查詢性能。下圖展示了在 TPC-DS 1TB 數(shù)據(jù)集規(guī)模下存算分離和存算一體的性能測試結(jié)果：

圖片

圖片

標(biāo)準(zhǔn)數(shù)據(jù)集結(jié)果顯示：

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

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

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

2.從數(shù)倉到湖倉一體的進(jìn)化

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

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

圖片

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

圖片

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