引言：智能汽車時代的數(shù)據(jù)挑戰(zhàn)

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

理想汽車大數(shù)據(jù)團隊面臨的核心挑戰(zhàn)是如何在保障高實時性的同時，實現(xiàn)系統(tǒng)的高穩(wěn)定性、高彈性與低成本。為此，團隊決定重構(gòu)數(shù)據(jù)底座，引入阿里云 Hologres + Flink 技術(shù)棧，打造新一代車聯(lián)網(wǎng)實時分析平臺。本文將系統(tǒng)介紹這一實踐過程。

一、海量車聯(lián)網(wǎng)信號的挑戰(zhàn)

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

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

挑戰(zhàn)一：穩(wěn)定性不足

數(shù)據(jù)的持續(xù)增長不斷觸發(fā)系統(tǒng)瓶頸，導(dǎo)致故障頻發(fā)。具體表現(xiàn)為：

寫入延遲：節(jié)假日等流量高峰期間，寫入RPS超過150萬，系統(tǒng)出現(xiàn)明顯延遲，無法滿足業(yè)務(wù)時效性要求；

• 冷查詢打滿資源：大量30天以上的冷數(shù)據(jù)查詢QPS峰值超1萬，占用大量計算資源，影響熱數(shù)據(jù)服務(wù)；
• 容錯能力弱：系統(tǒng)故障時高度依賴人工處理，恢復(fù)效率低，最慢需12小時才能完全恢復(fù)；
• 流程不完善：業(yè)務(wù)接入缺乏準(zhǔn)入評估，上線前測試不充分，導(dǎo)致資源錯配與線上Bug頻出；
• 缺乏兜底機制：升級需停服、難回滾，故障時無法快速止損。

這些問題疊加，使得系統(tǒng)SLA難以保障，嚴(yán)重影響用戶體驗與業(yè)務(wù)發(fā)展。

挑戰(zhàn)二：彈性能力弱、成本高

理想汽車原有架構(gòu)采用存算一體的非云原生設(shè)計，部署在云主機或裸金屬服務(wù)器上，存在顯著缺陷：

資源無法彈性擴縮：為應(yīng)對節(jié)假日峰值，需長期按最高負(fù)載配置資源，造成大量閑置浪費；

• 存算耦合：存儲與計算綁定，無法獨立擴展，計算資源利用率低；
• 雙集群雙鏈路冗余：為保障穩(wěn)定性，采用主備雙集群 + 實時/離線雙鏈路方案，導(dǎo)致資源成本翻倍；
• 技術(shù)棧割裂：實時鏈路（明細(xì)表→物化視圖）與離線鏈路（ODS→DWD→DWS→APP）使用兩套技術(shù)棧、兩套存儲，開發(fā)運維成本高；
• 集群拆分復(fù)雜：單集群無法支撐未來200萬輛車規(guī)模，拆分帶來數(shù)據(jù)路由、一致性等新問題。

該架構(gòu)不僅成本高昂，且難以適應(yīng)立項汽車未來幾百萬車輛業(yè)務(wù)的高速增長。

二、基于阿里云Hologres+Flink架構(gòu)方案

為應(yīng)對上述挑戰(zhàn)，理想汽車于2024年底啟動技術(shù)架構(gòu)升級，全面引入阿里云Hologres+ Flink，構(gòu)建“彈性、高可用、低成本”的新一代車聯(lián)網(wǎng)數(shù)據(jù)平臺。

新架構(gòu)自下而上分為四層：

寫入層：通過阿里云實時計算Flink版的Serverless實現(xiàn)高性能數(shù)據(jù)寫入，Hologres具備極強的寫入能力，寫入即可查。

• 存儲層：利用 Hologres的冷熱分層能力，部分?jǐn)?shù)據(jù)放在OSS，將冷熱數(shù)據(jù)比例從2:1提升至5:1，顯著降低存儲成本；
• 計算層：通過 Hologres計算組實現(xiàn)讀寫分離 + 負(fù)載隔離，寫入、加工、查詢等分別屬于不同計算組，互相不受影像。存在OSS的歷史數(shù)據(jù)，對性能不敏感，搭配Hologres Serverless Computing 彈性資源可以直接進行冷查詢或者ETL加工大寬表，成本低，又不會影響其他計算組的穩(wěn)定性。整體架構(gòu)可以保障高優(yōu)業(yè)務(wù)（如熱查詢、實時預(yù)警）的穩(wěn)定性；
• 業(yè)務(wù)層：統(tǒng)一實時與離線鏈路，實現(xiàn)流批一體，ODS層數(shù)據(jù)統(tǒng)一存儲，存儲成本減半。

關(guān)鍵創(chuàng)新在于：不再需要雙集群、雙鏈路兜底，Hologres 自身的高可用與彈性能力即可保障SLA。

性能壓測驗證

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

寫入壓測：

1. 真實100萬+輛車場景下，700CU資源支撐150萬+ RPS，寫入無延遲；
2. Mock 200萬輛車，寫入峰值達300萬+ RPS，依然穩(wěn)定。

查詢壓測：

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

壓測結(jié)果證明，新架構(gòu)具備支撐未來200萬輛車規(guī)模的能力，且冷熱查詢性能均衡，滿足業(yè)務(wù)需求。

車輛數(shù)字孿生View場景測試

“車輛數(shù)字孿生View”是理想汽車的核心業(yè)務(wù)場景：在云端實時還原每一輛車在同一時刻的所有信號狀態(tài)，用于故障診斷、自動駕駛監(jiān)控、售后維修支持及工況回放仿真。

該場景極具挑戰(zhàn)性：

信號數(shù)量多達1萬個以上；

• 100萬+輛車按秒/毫秒同時上報；
• 需要高并發(fā)（QPS超1萬）、高實時（秒級延遲）、高一致性。

初期方案采用 Hologres Binlog 實時同步，雖能實現(xiàn)高實時性，但由于我們數(shù)據(jù)量較大，Binlog體量是原始數(shù)據(jù)的數(shù)倍，需長期占用熱存儲，成本高昂。

車輛數(shù)字孿生View場景升級

經(jīng)與 Hologres 團隊聯(lián)合優(yōu)化，從左側(cè)的Binlog方案，升級到10秒增量ETL框架，分為四步：

1. 根據(jù)Offset獲取明細(xì)：拉取過去10秒的增量數(shù)據(jù)；
2. 預(yù)聚合：對增量信號進行初步聚合；
3. 與View聚合：將預(yù)聚合結(jié)果與現(xiàn)有車輛View合并；
4. 記錄Offset：持久化最新處理位點，支持?jǐn)帱c續(xù)傳。

該方案優(yōu)勢顯著：

時間換空間：復(fù)用已有數(shù)據(jù)，避免額外存儲成本；

• 高性能：基于底層文件行號過濾，性能極高；
• 強容錯：Offset機制保障系統(tǒng)異常時可快速恢復(fù)數(shù)據(jù)。

理想汽車通過這個方案實現(xiàn)了成本和效率的一個完美的平衡。既能滿足業(yè)務(wù)的需求，也可以復(fù)用現(xiàn)有的數(shù)據(jù)，避免了額外的成本。而且我們增量的數(shù)據(jù)獲取采用底層文件行號過濾性能非常高，并且有offset的記錄。當(dāng)系統(tǒng)發(fā)生錯誤的時候，可以根據(jù)offset實時的追回我們的數(shù)據(jù)，有非常好的容錯能力。

穩(wěn)定性保障體系

穩(wěn)定性不僅是產(chǎn)品的能力，更是流程機制的建立。理想汽車基于Hologres 存算分離、云原生架構(gòu)，系統(tǒng)容錯能力強，上線至今0故障，同時在內(nèi)部構(gòu)建了“事前預(yù)防、事中止損、事后保障”的全鏈路穩(wěn)定性體系：

事前預(yù)防：

1. 制定《業(yè)務(wù)準(zhǔn)入SOP》《變更管控SOP》《供應(yīng)商準(zhǔn)入SOP》；
2. 完善Hologres監(jiān)控告警：查詢監(jiān)控、資源監(jiān)控、存儲IO監(jiān)控全覆蓋；
3. 使用影子實例驗證變更，無誤后再上線。

事中止損：

1. 彈性擴縮：高峰期自動擴容，低峰期縮容；
2. 快速回滾：升級異?？擅爰壔赝耍?/span>
3. 服務(wù)降級：非核心查詢可臨時降級，保障核心鏈路。

事后保障：

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

Hologres+Flink架構(gòu)總結(jié)

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

最后方面穩(wěn)定應(yīng)用。如剛才所說，理想汽車構(gòu)建了非常完善的穩(wěn)定性保障的機制，擁有完善的審計日志，讓我們可以靈活的自助分析我們系統(tǒng)的瓶頸和風(fēng)險。

三、理想汽車基于Hologres+Flink構(gòu)建萬億級車聯(lián)網(wǎng)信號實時分析平臺

以上是架構(gòu)設(shè)計的思考，后續(xù)給大家介紹理想汽車基于Hologres+Flink這套架構(gòu)在業(yè)務(wù)上線應(yīng)用過程中一些情況。包括我們剛才提到了的工況還原、智能診斷、車輛預(yù)警等場景。

整體接入及上線時間線

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

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

整體業(yè)務(wù)實踐和收益

接入 Hologres 后，理想汽車資源利用率提升，實現(xiàn)性能與成本的完美平衡；響應(yīng)時間滿足SLA：歷史工況回溯等場景響應(yīng)時間達標(biāo)，SLA達標(biāo)率99.9%。

寫入性能提升200%：在成本持平前提下，寫入能力翻倍，達150萬RPS，零延遲；比方說網(wǎng)絡(luò)抖動，或者是消費的服務(wù)有所異常的情況，導(dǎo)致的信號積壓的場景下，我們能快速的恢復(fù)跟止損。

• QPS提升32%：熱查詢使用獨立Hologres Warehouse，專注熱數(shù)據(jù)處理，資源利用率比共享池高20%；
• 計算成本降低40%：冷查詢雖然頻率比較低，但是又有一定的實時要求，采用Hologres Serverless Comuting模式，按量付費，降低成本，也能保證SLA；

應(yīng)用一："自動列化+動態(tài)擴列"破解海量車機存儲難題

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

靈活性：支持信號動態(tài)增減，無需頻繁變更表結(jié)構(gòu)，適配業(yè)務(wù)快速迭代；

• 高效性：JSONB格式具備高效存儲與解析性能，結(jié)合A-Z列分類，大幅減少數(shù)據(jù)掃描范圍；
• 可維護性：信號按首字母分類存儲，數(shù)據(jù)歸屬清晰，便于后續(xù)分區(qū)管理與優(yōu)化。

應(yīng)用二：讀寫優(yōu)化，萬億數(shù)據(jù)秒級寫入和查詢

為滿足萬億級數(shù)據(jù)秒級寫入，理想汽車基于Hologres采用多項優(yōu)化：

Copy模式寫入：使用二進制協(xié)議，高效寫入，寫入即可查；

• 連接池 + Table Schema緩存：防止每次Copy創(chuàng)建新連接，減少服務(wù)端CPU消耗；
• 攢批Flush：減少close頻率，進一步提高性能；Flush與Checkpoint同步，保證消息不丟失；
• 零延遲快照：基于增量視圖Union明細(xì)表，實現(xiàn)信號最新快照的零延遲查詢。

這些優(yōu)化確保了高吞吐、低延遲、高可靠的數(shù)據(jù)寫入能力。

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

應(yīng)用三：高峰期穩(wěn)定性保障

在五一和端午假期期間，理想汽車通過節(jié)前擴容20%、節(jié)后縮容20%，成功應(yīng)對流量高峰，保證SLA，假期無故障，寫入無延遲，實現(xiàn)10000+ QPS的高性能響應(yīng)。

應(yīng)用四：離線場景降本提效

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

數(shù)據(jù)探查：數(shù)據(jù)分析師或者是數(shù)據(jù)產(chǎn)品在提數(shù)據(jù)需求時，他可能對數(shù)據(jù)本身的質(zhì)量和數(shù)據(jù)的分布情況其實沒有一個感知。需要數(shù)倉的同學(xué)先做探查，再反復(fù)地去溝通，這個時間其實比較耗時，可能會占用我們一半的研發(fā)的時間。我們希望把這個數(shù)據(jù)探查做成一個自助化的，通過Hologres用戶可以去自己探查數(shù)據(jù)后再來提數(shù)據(jù)的訴求。

• 數(shù)據(jù)加工：針對一些簡單的數(shù)據(jù)加工ETL，例如一些信號循環(huán)的加工，讓業(yè)務(wù)分析師能夠自主的去使用。
• 交叉分析：加工完循環(huán)數(shù)據(jù)表，包括一些簡單的信號的加工之后，業(yè)務(wù)可以做一些交叉分析。

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

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

四、未來展望

理想汽車與 Hologres 團隊將持續(xù)深化合作，探索更多創(chuàng)新方向：

1. Serverless Flink統(tǒng)一寫入：進一步簡化架構(gòu)，提升寫入彈性與性能；
2. Hologres能力增強：基于新發(fā)布能力，探索Time Travel等特性，實現(xiàn)更細(xì)粒度的數(shù)字孿生與冷存管理；
3. 接入更多場景：擴展至充電場站信號、臺架測試數(shù)據(jù)等新信號源，支持自動駕駛、AI訓(xùn)練等復(fù)雜OLAP與AI場景。

通過 Hologres + Flink 的深度整合，理想汽車成功構(gòu)建了穩(wěn)定、彈性、高效、低成本的萬億級車聯(lián)網(wǎng)實時分析平臺。該平臺不僅解決了當(dāng)前業(yè)務(wù)痛點，更具備面向未來的擴展能力——可平滑支撐200萬輛車甚至更大的業(yè)務(wù)規(guī)模，無需架構(gòu)重構(gòu)。理想汽車將與阿里云合作不斷深耕大數(shù)據(jù)+AI場景，為用戶提供卓越、穩(wěn)定、安全的汽車智能駕駛體驗。

繼續(xù)閱讀：

星空人工智能技術(shù)網(wǎng) 倡導(dǎo)尊重與保護知識產(chǎn)權(quán)。如發(fā)現(xiàn)本站文章存在版權(quán)等問題，煩請30天內(nèi)提供版權(quán)疑問、身份證明、版權(quán)證明、聯(lián)系方式等發(fā)郵件至1851688011@qq.com我們將及時溝通與處理。?。?a href="/">首頁 > 星空人工智能產(chǎn)業(yè) > 自動駕駛 » 理想汽車基于阿里云 Hologres + Flink 構(gòu)建萬億級車聯(lián)網(wǎng)信號實時分析平臺