作者：海博 理想汽車高級大數據工程師、賈天福 理想汽車高級大數據工程師

引言：智能汽車時代的數據挑戰

隨着電動車和智能汽車的快速普及，車聯網信號數據呈現爆發式增長。理想汽車作為國內領先的智能電動汽車企業，已擁有超過100萬輛在網車輛，每輛車每秒上報多達上萬個信號（如車速、胎壓、温度、電池狀態等），整體數據規模達到萬億級別。這些數據不僅體量巨大，而且對實時性要求極高——端到端延遲需控制在2秒以內，至少不超過5秒，以支撐數字孿生、智能診斷、車輛預警等關鍵業務場景。

理想汽車大數據團隊面臨的核心挑戰是如何在保障高實時性的同時，實現系統的高穩定性、高彈性與低成本。為此，團隊決定重構數據底座，引入阿里雲 Hologres + Flink 技術棧，打造新一代車聯網實時分析平台。本文將系統介紹這一實踐過程。

一、海量車聯網信號的挑戰

理想汽車當前擁有100萬輛以上存量汽車，每輛車約有1萬個信號進行實時的秒級甚至毫秒級上報。這些信號涵蓋制動系統、自動駕駛系統、動力系統、車身系統、座椅系統等多個維度，數據灌入實時數據庫後，存量數據達萬億行、PB級別，日增數據達數百億行。

業務對數據鏈路的實時性要求極高，端到端延遲需控制在2秒以內，至少不超過5秒。為滿足這一需求，理想汽車曾構建了一套離線與實時雙鏈路的整體保障方案。然而，隨着數據爆炸式增長，進入2025年後，舊有技術棧問題頻發，暴露出兩大核心挑戰：穩定性不足、彈性能力弱/成本高。

挑戰一：穩定性不足

數據的持續增長不斷觸發系統瓶頸，導致故障頻發。具體表現為：

• 寫入延遲：節假日等流量高峯期間，寫入RPS超過150萬，系統出現明顯延遲，無法滿足業務時效性要求；
• 冷查詢打滿資源：大量30天以上的冷數據查詢QPS峯值超1萬，佔用大量計算資源，影響熱數據服務；
• 容錯能力弱：系統故障時高度依賴人工處理，恢復效率低，最慢需12小時才能完全恢復；
• 流程不完善：業務接入缺乏准入評估，上線前測試不充分，導致資源錯配與線上Bug頻出；
• 缺乏兜底機制：升級需停服、難回滾，故障時無法快速止損。

這些問題疊加，使得系統SLA難以保障，嚴重影響用户體驗與業務發展。

挑戰二：彈性能力弱、成本高

理想汽車原有架構採用存算一體的非雲原生設計，部署在雲主機或裸金屬服務器上，存在顯著缺陷：

• 資源無法彈性擴縮：為應對節假日峯值，需長期按最高負載配置資源，造成大量閒置浪費；
• 存算耦合：存儲與計算綁定，無法獨立擴展，計算資源利用率低；
• 雙集羣雙鏈路冗餘：為保障穩定性，採用主備雙集羣 + 實時/離線雙鏈路方案，導致資源成本翻倍；
• 技術棧割裂：實時鏈路（明細表→物化視圖）與離線鏈路（ODS→DWD→DWS→APP）使用兩套技術棧、兩套存儲，開發運維成本高；
• 集羣拆分複雜：單集羣無法支撐未來200萬輛車規模，拆分帶來數據路由、一致性等新問題。

該架構不僅成本高昂，且難以適應立項汽車未來幾百萬車輛業務的高速增長。

二、基於阿里雲Hologres+Flink架構方案

為應對上述挑戰，理想汽車於2024年底啓動技術架構升級，全面引入阿里雲Hologres+ Flink，構建“彈性、高可用、低成本”的新一代車聯網數據平台。

新架構自下而上分為四層：

• 寫入層：通過阿里雲實時計算Flink版的Serverless實現高性能數據寫入，Hologres具備極強的寫入能力，寫入即可查。
• 存儲層：利用 Hologres的冷熱分層能力，部分數據放在OSS，將冷熱數據比例從2:1提升至5:1，顯著降低存儲成本；
• 計算層：通過 Hologres計算組實現讀寫分離 + 負載隔離，寫入、加工、查詢等分別屬於不同計算組，互相不受影像。存在OSS的歷史數據，對性能不敏感，搭配Hologres Serverless Computing 彈性資源可以直接進行冷查詢或者ETL加工大寬表，成本低，又不會影響其他計算組的穩定性。整體架構可以保障高優業務（如熱查詢、實時預警）的穩定性；
• 業務層：統一實時與離線鏈路，實現流批一體，ODS層數據統一存儲，存儲成本減半。

關鍵創新在於：不再需要雙集羣、雙鏈路兜底，Hologres 自身的高可用與彈性能力即可保障SLA。

性能壓測驗證

理想汽車對新架構進行了全鏈路壓測，驗證其支撐能力：

• 寫入壓測：

  • 真實100萬+輛車場景下，700CU資源支撐150萬+ RPS，寫入無延遲；
  • Mock 200萬輛車，寫入峯值達300萬+ RPS，依然穩定。

• 查詢壓測：

  • 500CU下，單Query與混合Query均滿足1萬+ QPS需求；
  • 冷熱查詢性能差異可控，熱查P99約10秒，冷查約27秒。

壓測結果證明，新架構具備支撐未來200萬輛車規模的能力，且冷熱查詢性能均衡，滿足業務需求。

車輛數字孿生View場景測試

“車輛數字孿生View”是理想汽車的核心業務場景：在雲端實時還原每一輛車在同一時刻的所有信號狀態，用於故障診斷、自動駕駛監控、售後維修支持及工況回放仿真。

該場景極具挑戰性：

• 信號數量多達1萬個以上；
• 100萬+輛車按秒/毫秒同時上報；
• 需要高併發（QPS超1萬）、高實時（秒級延遲）、高一致性。

初期方案採用 Hologres Binlog 實時同步，雖能實現高實時性，但由於我們數據量較大，Binlog體量是原始數據的數倍，需長期佔用熱存儲，成本高昂。

車輛數字孿生View場景升級

經與 Hologres 團隊聯合優化，從左側的Binlog方案，升級到10秒增量ETL框架，分為四步：

1. 根據Offset獲取明細：拉取過去10秒的增量數據；
2. 預聚合：對增量信號進行初步聚合；
3. 與View聚合：將預聚合結果與現有車輛View合併；
4. 記錄Offset：持久化最新處理位點，支持斷點續傳。

該方案優勢顯著：

• 時間換空間：複用已有數據，避免額外存儲成本；
• 高性能：基於底層文件行號過濾，性能極高；
• 強容錯：Offset機制保障系統異常時可快速恢復數據。

理想汽車通過這個方案實現了成本和效率的一個完美的平衡。既能滿足業務的需求，也可以複用現有的數據，避免了額外的成本。而且我們增量的數據獲取採用底層文件行號過濾性能非常高，並且有offset的記錄。當系統發生錯誤的時候，可以根據offset實時的追回我們的數據。，有非常好的容錯能力。

穩定性保障體系

穩定性不僅是產品的能力，更是流程機制的建立。理想汽車基於Hologres 存算分離、雲原生架構，系統容錯能力強，上線至今0故障，同時在內部構建了“事前預防、事中止損、事後保障”的全鏈路穩定性體系：

• 事前預防：

  • 制定《業務准入SOP》《變更管控SOP》《供應商准入SOP》；
  • 完善Hologres監控告警：查詢監控、資源監控、存儲IO監控全覆蓋；
  • 使用影子實例驗證變更，無誤後再上線。

• 事中止損：

  • 彈性擴縮：高峯期自動擴容，低峯期縮容；
  • 快速回滾：升級異常可秒級回退；
  • 服務降級：非核心查詢可臨時降級，保障核心鏈路。

• 事後保障：

  • SLA承諾99.9%，7×24小時專屬支持；
  • 審計日誌完善，支持自助分析瓶頸。

Hologres+Flink架構總結

使用了阿里雲Hologres+Flink這套技術棧以後，我覺得我們既有現在又有未來。如剛才所説，現在能支持理想汽車一百多萬輛車的一個場景，也可以通過擴容去支持未來200萬輛車甚至更多的一個場景，不需要做多種集羣的拆分。第二方面是效率高，成本低。Hologres具有極致的彈性能力，還有一些這種Serverless Computing這樣的彈性資源，大幅提高我們的資源利用率，避免資源浪費。而且Hologres是一個多模態的分析場景，未來還可以擴展到OLAP分析、點查服務、全文檢索、向量搜索以及AI推理等多種場景。

最後方面穩定應用。如剛才所説，理想汽車構建了非常完善的穩定性保障的機制，擁有完善的審計日誌，讓我們可以靈活的自助分析我們系統的瓶頸和風險。

三、理想汽車基於Hologres+Flink構建萬億級車聯網信號實時分析平台

以上是架構設計的思考，後續給大家介紹理想汽車基於Hologres+Flink這套架構在業務上線應用過程中一些情況。包括我們剛才提到了的工況還原、智能診斷、車輛預警等場景。

整體接入及上線時間線

理想汽車與 Hologres 的合作按以下時間線推進，我們通過大約6-9個月即完成從最初POC測試到正式上線，整個過程平穩有序，驗證了新架構的可靠性。

從最開始24年的12月份跟Hologres做初步對接，Hologres團隊其實很快的就完成了POC的這個測試，符合我們性能的訴求。過完年後我們開始在2-4月份去進行全面的壓測跟優化，又做了灰度的查詢的驗證，驗證了擴縮容對業務沒有影響。因為這次架構的升級要求對業務無感的，5越分開始我們進行了新老鏈路的雙跑，並在五一和端午兩個高峯的假期去驗證整體的能力，發現Hologres是完全滿足假期高峯出行的流量保障要求。端午之後，我們就把老的這個鏈路給下線了，整個五月期間，也沒有發生任何故障，於是我們在實時的鏈路上又接入了一些複雜的一些計算的場景。

整體業務實踐和收益

接入 Hologres 後，理想汽車資源利用率提升，實現性能與成本的完美平衡；響應時間滿足SLA：歷史工況回溯等場景響應時間達標，SLA達標率99.9%。

• 寫入性能提升200%：在成本持平前提下，寫入能力翻倍，達150萬RPS，零延遲；比方説網絡抖動，或者是消費的服務有所異常的情況，導致的信號積壓的場景下，我們能快速的恢復跟止損。
• QPS提升32%：熱查詢使用獨立Hologres Warehouse，專注熱數據處理，資源利用率比共享池高20%；
• 計算成本降低40%：冷查詢雖然頻率比較低，但是又有一定的實時要求，採用Hologres Serverless Comuting模式，按量付費，降低成本，也能保證SLA；
  

應用一："自動列化+動態擴列"破解海量車機存儲難題

面對100萬輛車10000+動態信號，理想汽車設計了“A-Z固定列 + JSONB列式動態存儲”方案，Hologres 開啓JSONB列式存儲優化後，底層自動將JSONB轉換為強Schema列式存儲，查詢時可直接命中指定列，提升性能；同時存儲壓縮效率高，有效降本增效。

• 靈活性：支持信號動態增減，無需頻繁變更表結構，適配業務快速迭代；
• 高效性：JSONB格式具備高效存儲與解析性能，結合A-Z列分類，大幅減少數據掃描範圍；
• 可維護性：信號按首字母分類存儲，數據歸屬清晰，便於後續分區管理與優化。

應用二：讀寫優化，萬億數據秒級寫入和查詢

為滿足萬億級數據秒級寫入，理想汽車基於Hologres採用多項優化：

• Copy模式寫入：使用二進制協議，高效寫入，寫入即可查；
• 連接池 + Table Schema緩存：防止每次Copy創建新連接，減少服務端CPU消耗；
• 攢批Flush：減少close頻率，進一步提高性能；Flush與Checkpoint同步，保證消息不丟失；
• 零延遲快照：基於增量視圖Union明細表，實現信號最新快照的零延遲查詢。

這些優化確保了高吞吐、低延遲、高可靠的數據寫入能力。

在查詢層面，我們是做到了1萬+QPS的秒級返回。主要是基於Hologres的cache優化能力，保證熱點數據能覆蓋到95%以上。基於條件下推減少了scan的掃描，jsonb列存化減少scan時的io大小和cpu消耗。然後針對這一些大量的點查，vin作為distribution key 保證數據均勻分佈, ts作為clustering key幫助高效裁剪文件。

應用三：高峯期穩定性保障

在五一和端午假期期間，理想汽車通過節前擴容20%、節後縮容20%，成功應對流量高峯，保證SLA，假期無故障，寫入無延遲，實現10000+ QPS的高性能響應。

應用四：離線場景降本提效

理想汽車還有一些離線場景，我們也將他遷移到Hologres上，有幾個典型的場景：

• 數據探查：數據分析師或者是數據產品在提數據需求時，他可能對數據本身的質量和數據的分佈情況其實沒有一個感知。需要數倉的同學先做探查，再反覆地去溝通，這個時間其實比較耗時，可能會佔用我們一半的研發的時間。我們希望把這個數據探查做成一個自助化的，通過Hologres用户可以去自己探查數據後再來提數據的訴求。
• 數據加工：針對一些簡單的數據加工ETL，例如一些信號循環的加工，讓業務分析師能夠自主的去使用。
• 交叉分析：加工完循環數據表，包括一些簡單的信號的加工之後，業務可以做一些交叉分析。

這些場景以前都比較慢，我們通過Hologres的JsonB全量表+Dynamic Table增量加工+Serverless Computing彈性計算資源，實現了在降低成本的同時，提升了加工效率，並滿足了業務對性能的要求。

整體資源的利用率比原先離線的能提高60%，成本是離線場景能下降到35%，下降了35%，整體的這個交付的時間基本上從原來的3到5天能減少到4個小時之內，覆蓋了90%離線信號分析場景。

四、未來展望

理想汽車與 Hologres 團隊將持續深化合作，探索更多創新方向：

1. Serverless Flink統一寫入：進一步簡化架構，提升寫入彈性與性能；
2. Hologres能力增強：基於新發布能力，探索Time Travel等特性，實現更細粒度的數字孿生與冷存管理；
3. 接入更多場景：擴展至充電場站信號、台架測試數據等新信號源，支持自動駕駛、AI訓練等複雜OLAP與AI場景。
   

通過 Hologres + Flink 的深度整合，理想汽車成功構建了穩定、彈性、高效、低成本的萬億級車聯網實時分析平台。該平台不僅解決了當前業務痛點，更具備面向未來的擴展能力——可平滑支撐200萬輛車甚至更大的業務規模，無需架構重構。理想汽車將與阿里雲合作不斷深耕大數據+AI場景，為用户提供卓越、穩定、安全的汽車智能駕駛體驗。