作者：任智紅，首汽約車大數據負責人
更多交流，聯繫我們:https://wx.focussend.com/weComLink/mobileQrCodeLink/334%201%2...

導讀：本文整理自汽首約車大數據負責人任智紅在 StarRocks 年度峯會上的演講，介紹了 StarRocks 在公司內部的應用。主要業務場景包括：
運效診斷與干預：實現秒級數據接入和計算，分鐘級生成和應用標籤，提高了數據處理效率。
供需平衡聯動：支持實時計算數百億數據，確保分鐘級聯動，提升供需匹配效率。
自助查詢與多維分析：查詢性能從分鐘級延遲提升到秒級，顯著降低了數據開發和維護成本。

引入StarRocks的背景

首汽約車公司及業務介紹

首汽約車成立於 2015 年，主營網約車業務，曾為冬奧會、冬殘奧會等國家級重點會議提供出行服務。公司最初僅在北京運營，隨後逐步擴展至全國。目前，我們的業務已覆蓋全國 200 多個城市。
首汽約車專注於特色化業務和差異化運營，服務用户涵蓋 To C 和 To B 兩大類。我們不僅面向普通消費者，也為商務人士提供高品質出行服務，滿足不同用户的需求，包括服務敏感型和價格敏感型羣體。

首汽約車數據架構變化

我們的數據架構經歷了多個重要發展階段，與大多數公司類似。最初，我們專注於滿足業務報表的數據需求，處於數據基礎建設期。隨後，我們引入更多組件，進入快速發展期，數據開始反哺業務，發揮賦能作用。
目前，我們通過引入 StarRocks，對底層數據進行了標準化與一致化，進入增效期，充分發揮數據的驅動價值，使其與業務產生更緊密的聯動。由於數據架構的發展路徑在業內較為相似，這裏不再展開詳細介紹。

精細化運營帶來的挑戰

隨着業務逐步拓展，開設的城市數量增加，需求來源和種類也變得更加多樣，運力來源和總量也在不斷擴大。我們進入了精細化運營階段，這為數據建設和使用帶來了許多挑戰。首先，更多的角色將參與數據分析過程。其次，數據的視角和維度將更加豐富和細化，這對數據處理和查詢提出了更高的要求。此外，數據的時效性要求也更為嚴格。業務需要更加實時的數據來感知變化並做出快速決策。這種實時聯動不僅僅是通過報表展示數據，業務在看到數據後做出相應的動作，更是通過系統化的自動聯動，實現智能化調控效果。

引入 StarRocks 的原因

在這樣的背景下，經過選型調研後，我們最終選擇了引入 StarRocks。選擇 StarRocks 不僅因為它的產品特性和優異性能，還因為它與我們首汽約車的數據特點有着完美的契合。例如，我們的數據存在明顯的高峯期和低谷期，尤其是在高峯期，相比低谷期，我們的數據量可能會增長十倍以上。與此同時，很多策略主要依賴於高峯期的流量暴增，因此我們對高峯期的性能要求非常高。

另外，我們的數據源和種類也非常豐富，涵蓋司機端數據、乘客端數據、第三方數據、通過埋點採集的端上操作數據、業務過程數據以及策略服務日誌類數據等。我們的數據處理複雜度也較高，涉及很多實時數據整合的場景，也有很多歷史數據的局部更新場景。這些特性完全依賴於 StarRocks 的產品特性和性能優勢，能夠很好地支撐我們的需求。

StarRocks的基建情況和應用創新

基於StarRocks的實時生態系統

我們按照標準的數據建設規範，依託 StarRocks 構建了一套完整的數據體系，包括明細數據、主題數據以及視圖類數據等。目前，這套體系已經廣泛應用於我們的多個業務場景中，涉及算法策略、報表工具、自助查詢工具以及實時預警工具等。現在，日查詢量已經突破百萬次，涵蓋系統性調用和人工探索性查詢，整體查詢性能能夠控制在秒級別。

除了數據建設本身，我們還藉助 StarRocks 強大的兼容性，建立了一系列配套工具。例如，在數據接入方面，我們基於 Flink 構建了分場景的數據接入工具，支持離線數據導入工具，並且具備數據接入效率監控工具。在數據處理過程中，我們有微批調度工具，當數據出現輕微延遲時，能夠自動補充數據或回刷。在應用方面，我們有統一查詢引擎、配置化預警工具以及數據導出工具等。這些數據建設和配套工具共同構成了一個完整的數據生態體系。

StarRocks 的業務場景

現在，StarRocks 在我們內部的應用貫穿了整個業務的運營生命週期。在我們公司，數據和業務是相互聯動、相輔相成的。一方面，業務場景的落地往往會對數據建設提出新的需求。例如，當業務需要實施新的策略時，可能需要相應的數據支持。另一方面，數據能力的提升和突破也會推動業務動作的細化和標準化。例如，最初我們在司機風險管理上主要依賴事後管控手段，但隨着實時處理能力的突破和增強，我們已經逐步從事後管控擴展到事前防護和事中攔截。當某些問題有跡象時，我們會通過預警和引導手段進行管理，豐富了對司機的管理手段。

我們的數據理念是通過工具化方式提升數據使用的閉環性和時效性，從而提高數據與業務的協同效率。

場景舉例1——運效診斷與干預

第一個場景是運效的診斷與干預。運力是網約車業務的核心運營主體，通常我們對運力的運營目標是提升其運營效率，並管控服務風險。因此，我們需要精準、快速、高效地識別哪些是高效的，哪些是有風險的。

要全面感知和識別運力的各種問題，涉及到多個數據源和多種數據類型，這正是這個場景的主要難點。數據進來後，我們還需要進行復雜的計算，以統計出許多行為並進行標籤化。基於這些標籤，我們進一步在業務動作上進行聯動。整體的查詢分析複雜度高，且時效性要求強，這是該場景的另一個挑戰。依託 StarRocks 的分佈式執行框架、全面向量化的執行引擎等一系列處理能力，我們成功地支撐了這個場景的需求。

在具體的數據處理流程中，首先需要對各種與實際相關的數據進行接入和整合。例如，C端用户的操作行為日誌、行為軌跡、基礎信息、業務過程中的訂單數據以及派單日誌等。在這個過程中，依靠 StarRocks 的一些特性，確保了數據處理的效率、一致性和準確性。

在這個處理過程中，部分數據會臨時寫入 StarRocks，藉助其查詢能力，使得整體的實時計算更加輕量化。當涉及數據回放時，StarRocks 也能夠快速完成。在數據整合後，我們進一步加工生成靜態指標和動態指標。例如，司機當前的空閒時長、在冷區的停留時長、異常軌跡點數量以及被訂單異常過濾的次數。這些指標會進一步加工，形成各類司機標籤，例如冷區停留、挑單、推單等。這些標籤會實時聯動到相應的業務動作中，進行相應的管理。例如，對於冷區停留的司機，我們可能會通過系統調度將其引導到周圍的熱區接單，從而提高其運營效率。對於有風險或服務問題的司機，我們會實時聯動派單策略，對其派單進行限制或降權，以保障整體的服務質量。

這個場景的實現效果是使我們能夠對各種類型和來源的數據進行秒級數據接入和計算，並在分鐘級別生成和應用標籤。這一切都依賴於 StarRocks 底層優異的特性。此外，由於我們的數據和業務不斷擴展，若新增數據源或標籤，我們可以按照這套模式高效、靈活地進行開發和落地。

場景舉例2——供需平衡聯動

第二個場景是供需平衡聯動。網約車是一個雙邊業務，除了供需兩側各自的運營和增長，平衡供需之間的匹配效率和匹配關係也是一個非常重要的線上策略。與上一個場景相比，這個場景的數據來源可能沒有那麼多，但數據量和維度種類卻非常多。如果我們要精準識別供需情況，我們不僅需要當前時刻的實時數據，還需要與實時數據相關的歷史數據，因此整體的數據量會非常龐大。

此外，如果要進行精細化調控，隨着每個維度的擴展，數據量會暴增。例如，從城市級別的調控細化到商圈和蜂巢級別的調控，單一維度的數據量可能會擴展千倍之多。如果要進行更精細的調控，還需要依賴訂單的結構、來源、車型組合等綜合維度，這樣整體的數據量會大幅膨脹。

數據接入和初步處理後，我們還會關聯到相應的業務動作。例如，可能需要對某些區域進行局部調價、進行 PUSH 調度、區域獎勵或智能補貼等。這些動作的計算複雜度較高，並且時效性要求非常高，這也是該場景的主要難點之一。依靠 StarRocks 的實時存儲能力及其相關的實時處理能力，我們的場景性能得到了很好的保障。

在具體的數據處理過程中，首先我們會整合各類數據，然後將其直接寫入需求寬表和運力寬表，這兩個表是該場景中的核心基礎表。這些表採用主鍵模型表，確保數據更新計算的效率。
在這兩個表之上，我們會構建一系列視圖，通過這些視圖來簡化查詢並提升計算效率。在 StarRocks 中，數據的寫入和查詢是並行進行的。得益於 StarRocks 的高效性能，我們在數據寫入的同時還能確保較高的查詢性能，從而保障了該場景的正常運作。在需求寬表和視圖之上，我們會進行分維度的供需計算。計算結果會幫助我們確定調控範圍和對象，判斷是進行全程調控還是局部調控，確定是主要調控需求端還是運力端。

這些調控結果有的會作為算法模型的特徵輸入，直接調用算法模型；有的則會作為規則模型的輸入，直接聯動到相應的策略中。
最後，聯動效果會實時回寫到我們的分維度數據中，經過整合和打包，形成分級預警和聯動效果提醒。通過釘釘和我們的運營平台，這些結果會傳遞給業務方，使他們能夠感知到效果。整體實現效果是：

• 能夠實時計算數百億的數據，這些數據不僅包括實時數據，還包含與實時數據相關聯的歷史數據。
• 能夠實現分鐘級別的監測和聯動。我們許多複雜策略已經能夠實現分鐘級別的聯動。例如，我們能夠在分鐘級別實現大單降價、小單漲價，熱區到冷區的需求漲價，以及冷區到熱區的需求漲價。可以調整冷區派單半徑的擴大，熱區派單半徑的縮小。整體目標是將高質量訂單最大化轉化，並將運力留在需求最熱的區域。
• 整體的數據處理鏈路簡潔，聯動過程不需要藉助額外的組件來實現，絕大多數數據直接從 StarRocks 中查詢，確保了執行效率和一致性。

場景舉例3——自助查詢&多維分析

自助多維分析是我們內部非常重要的一個場景，最初我們使用了兩種模式來進行數據查詢和分析：預計算模式和明細查詢模式。

預計算模式：主要通過 Spark 和 Hive 來進行數據的彙總和計算，然後將計算結果生成統計表。由於這種模式是通過空間換時間，能夠減少查詢時的計算負擔。然而，隨着業務的快速發展，維度數量的迅速增加，開發和維護成本也隨之激增。特別是當我們需要進行歷史數據的局部更新時，預計算模式帶來了巨大的壓力。如果業務進行了調整，比如城市或需求分類的重新調整，預計算模式就需要重新處理大量的數據，導致數據回刷的成本非常高。

明細查詢模式：為了應對預計算模式的限制，我們還使用了基於明細查詢的模式，這主要依賴 Presto 進行查詢。這種模式在維度擴展上更加靈活，能夠快速響應多維度查詢。但當數據量變得龐大時，查詢性能顯得有些不足，尤其是在查詢量和維度不斷增加的情況下，性能瓶頸變得越來越明顯。儘管我們嘗試通過預計算來優化性能，但隨着維度數量的擴展，整體查詢性能還是面臨了很大的挑戰。

依靠我們在 StarRocks 上建立的這些數據體系和相應的一些工具，我們形成了一個全新的自助多維分析模式。
一些數據通過我們的一些主題數據表直接進行查詢，一些數據則通過明細表和維度表進行實時校驗查詢，另外還有一些數據是基於視圖進行查詢。這種靈活高效的查詢方式，滿足了不同場景下的多維分析需求，最終實現了性能提升和成本降低的效果。

• 在性能方面，我們從最初的舊模式（分鐘級延遲）轉變為新模式（秒級查詢），查詢性能提升了數十倍。
• 在成本方面，數據開發和維護的成本也大幅降低，初步估算節省了至少一半。通過這種優化，數據開發團隊可以從低效和重複性的工作中抽離出來，專注於更有價值的探索。

隨着查詢性能瓶頸的突破，更多的人能夠參與到自助分析過程中，這不僅促進了精細化運營的開展，也增強了數據與業務之間的聯動，推動了公司數據驅動的業務發展。

成果總結

總結來説，基於我們引入 StarRocks 以及在底層建設上的努力，我們在性能統一、場景拓展和效率提升方面取得了顯著突破。特別感謝 StarRocks 的技術團隊，他們在模型設計指導、慢查詢分析等方面提供了大量專業支持。由於我們的許多業務都涉及線上應用，技術團隊在我們需要時能夠及時響應和支持，這對我們的項目非常關鍵。

另外，結合我們數據的特點，StarRocks 能夠按需快速迭代，滿足我們的一些定製化需求。總結起來，在 StarRocks 強大的產品特性、性能優勢以及技術團隊的大力支持下，我們在人力相對有限的情況下，實現了基礎建設的快速穩步發展，併成功驅動了業務需求的滿足。很多以前想做卻無法實現的場景現在得以實施，例如對風險司機的實時管控；之前難以做到的高成本場景現在也能以低成本執行，比如我們的自助多維分析工具。

未來規劃

首先，在業務層面，我們計劃進一步整合後台系統，充分發揮 StarRocks 的性能優勢。例如，針對我們對外提供的加盟商 SAAS 平台，以及 C 端和乘客端的數據展示或數據統計，未來這些都可能逐步切換到 StarRocks 平台。

其次，場景方面，我們將持續拓展現有場景，並結合業務發展的需求，構建新的應用場景。例如，目前我們正在與財務團隊合作，開發業務成本的實時管控功能。這些場景的擴展需要我們進一步加強數據基礎建設，同時對 StarRocks 資源進行投入和擴展。

在架構層面，我們將重點推進存算分離。我們的業務已經積累了大量的離線數據，如何高效地利用這些數據是我們接下來的關鍵任務。初步設想是在離線數據中引入數據湖組件，並利用 StarRocks 作為統一的查詢引擎來提高數據處理效率，同時減少數據在導入和導出過程中的流轉成本。存算分離之後，我們也計劃提升在高峯期的臨時擴容能力，進一步降低成本，提高效率。最終目標是朝着湖倉一體的方向發展。

最後，我們還計劃做資源隔離，確保不同業務應用場景的穩定性。由於我們目前的業務場景非常廣泛，包括線上應用、報表工具、自助查詢等不同場景，這些場景對系統的穩定性要求不同。通過資源隔離，我們可以確保關鍵應用場景的絕對穩定性。