一、背景介紹

“以前人們稱汽車為配備電子功能的機械產品，到今天演變為具有機械功能的智能電子產品，這是一個非常大的轉變。”—— 長安云器聯合項目組 石靜猛

轉變，源自產業的數字化轉型。新能源汽車廠商正在用數字化技術打造差異性的競爭優勢，關注點由發動機的制造逐漸趨向于基于數字化技術打造豐富的用戶體驗。

中國的汽車產業正在高速發展的過程中完成數字化升級，我國汽車產銷總量連續15年穩居全局全球第一。在產銷快速增長的同時，車企正在通過數字化提升乘用車產品的競爭力。

（圖1：汽車產銷總量及增長率）

數字化關系到車輛如何更好地應用，如何更好地跟人互動，與人們的生活打通，包括更廣為人知的智能化自動駕駛、智能座艙等應用場景，以及不為人所知的汽車設計、生產制造過程，數字化正在重構汽車工業。

二、長安汽車面對的挑戰

面對超大規模數據量和業務的飛速發展，長安大數據平臺面臨的挑戰可以總結為三大方面，即成本高、用數難、運維煩。

1. 成本高

每天有 20+TB 的新增數據，一年就會接近 9PB 的規模。隨著新能源車的比例越來越高，并且新能源車的數據要求全生命周期存儲，可能要存儲十年，整體下來，存儲成本是累加的。業務依然在快速增長，第二年數字可能就會翻倍。在這樣的數據量下，計算是超大規模的，即使是一個非常簡單的場景如一個簡單的 query，都可能會因為數據量龐大而計算困難。

2. 用數難

首先，查詢分析慢，因為數據量大，查一天的數據都很難，更何況在很多場景中需要查多天的數據，比如取一輛車在幾個月里的明細數據進行分析，將會是一個非常大的挑戰。

另外，實時數據加工比例非常低，因為數據量大，如果以傳統方式對全量數據進行實時加工，成本會非常高。因此只能采用 Lambda 架構，其中除了一套 t+1 的離線鏈路，還要有一套實時鏈路處理一些重要數據。這帶來的問題是，當業務新增需求時，或者做一個新的數據產品、處理一些新的信號時，需要從頭開發整個鏈路，在實時鏈路上重新加入這些數據，開發鏈路會非常復雜，要跨多個組件、多個平臺，除了Java，還需要 SQL 等等，開發門檻高，效率低。

3. 運維煩

Lambda 架構下，不同場景用不同的產品，這種多組件的架構非常復雜，運維困難。同時，性能瓶頸難以突破。另外，每年需要對平臺鏈路進行一次優化升級，運維成本持續高漲。還存在存儲空間報警，計算資源浪費的情況。

三、改造前的架構和挑戰

1. 改造前的架構

長安汽車大數據平臺改造前的整體架構是典型的 Lambda 架構，分為實時和離線兩部分。

• 實時鏈路

使用 Flink 對數據進行一些簡單的加工，加工后的數據寫到 Doris、ClickHouse 或StarRocks 等分析型平臺上。中間也包括一些 HBase 的應用。

• 離線鏈路

車上的數據實時接入 Kafka，再通過 Flink 實時消費寫到 HDFS 的某個文件，寫完之后，天級別的定時任務將這個文本文件加載成 Parquet 文件，再建成表，后面做 t+1 的分析處理，這就是整個離線的鏈路。

2. 挑戰

首先，長安汽車面臨著高 TPS+大吞吐的挑戰，除了每天會有 22TB 以上的增長，實時吞吐的峰值也超過了每秒 500 萬條，這一數字非常可觀，并且數據量仍在快速增長。

其次，很多 JSON 這種半結構化數據，信號列非常多，隨著新能源車數據產品應用的場景越來越多，信號列增長非常快。

另一方面，Lambda 架構下的實時化比例非常小，不到 10%，主要是離線加工。

四、改造后的架構介紹

針對上述挑戰，我們對大數據平臺進行了改造，將數據平臺升級到一個更簡潔高效的架構。如下圖所示，整體上從之前的 Lambda 架構升級為了一體化的 Kappa 架構，并且從 t+1 加工變成了百分百全域數據實時加工。

平臺的各種組件變成了一個組件，最終是一份資源、一個引擎，一種開發語言 SQL，支持不同的 workload，包括實時的加工、離線的加工、實時分析、ad-hoc 查詢等等。

五、改造后的價值與效果

1. 解決成本高問題

（1）存儲成本

以某張表一天的數據量為例，將同一份數據（數據條數和內容完全一致）導到兩個平臺上來進行對比。在舊的平臺上，HDFS存儲，單副本大約為2.8T，而新平臺，COS存儲只有831G。等價換算后，每百億條在舊平臺上為373G，而新平臺是130G。存儲節省了65%。這還只是單副本的對比，如果是兩副本，降低的比例就更高了。

實現這一改進的關鍵措施如下：

在Parquet存儲上自研了更多編碼優化，對半結構化數據自研map格式存儲，壓縮率比JSON更高，查詢效率也更高，在存儲上對數據進行了行級+信號級的二級去重。

車聯網信號數據常存在信號跳變的情況，而去重的基本原則就是不丟失任何跳變信息。乘用車進行行級去重之后，存儲降低 60% 左右。新能源車， 采用行級+信號級去重，存儲降低 38% 左右。在存儲降低之后，下游的計算性能也可以得到極大提升，從而節省計算資源。去重前的原始數據可以歸檔，進一步降低成本。

（2）計算成本

計算成本方面，在同樣的數據量、同樣的加工邏輯、得到同樣的結果，并保證結果正確的前提下，從T+1集中時間計算，分攤成近實時增量計算，比如5分鐘加工一次，一天共 288 次，將全天的資源累加起來，與之前天級的計算資源相比較，計算口徑為CU時=8core*1hr。可以看到，Spark用了14個CU時，而新平臺僅用了3.5個CU時。我們將Spark的資源再增加一倍，把系統負載因子乘以50%，之后與新平臺對比，仍然會有50% 左右的計算成本降低。說明同樣的數據，得到同樣的結果，一樣的加工邏輯，將離線計算變成實時計算的基礎之上，仍可以獲得大幅的計算成本降低。

這里需要說明的是，以上對比都是基于真實生產的 ETL 加工任務，這其中用到的核心技術就是增量計算。

2. 解決用數難問題

（1）提升查詢性能

先從查詢性能上來說，之前查詢數據非常慢。這里提取了 8 個子場景，分別代表了不同的業務價值，比如某些簽到信號分析的查詢、智慧能耗的分析、云云診斷儀、智能診斷等等。還包括一個創新場景，即跨天查詢的場景。

從上圖中可以看到，平均性能有三倍的提升。規模越大，表現越好。尤其是跨天場景，以前跑不出來，而現在 5 分鐘左右就可以跑出來。查詢數據量達到每天 700 億條，其中跨天查詢，三天 2000 億條數據。

實現這一提升，歸功于查詢 plan 的優化，ShareEverything 架構下更高效的讀寫性能，以及算子優化、向量執行、shuffle 加速等一系列改進。

（2）實現低成本下的 100% 數據實時

用數難中第二個問題是實時的比例低，之前業務想開發一個有實時要求的數據產品，整個過程是非常痛苦的。而現在變成了百分百數據實時，之后要做一個數據產品，只要從這個數倉平臺上拿數據、拿結果，直接做開發即可，效率大幅提升。

要做到百分百數據實時，低成本是關鍵，雖然用 Flink 也可以但成本高昂難以接受。上圖展示了全鏈路實時加工的流程。其中有一個 IGS：Ingestion Service，是讀寫分離的一個獨立的服務，能夠支持結構化/半結構化的數據實時寫入，數據會落到業務庫中對應的分區表里，然后對數據做去重，基于去重后的數據做加工，每條鏈路都是實時加工，并通過增量計算技術來實現，因此成本比較低。

同時對延遲數據也能進行加工，因為能夠識別出延遲數據落在哪個業務分區，增量計算只算那個分區相關的結果即可。整個數倉建成了一個實時的數倉，支撐車企的各項業務應用。

這里以一個典型的業務場景為例，即車聯網數據質量分析。以前的平臺實現困難，因為要接入一天上千億條數據，對里面的信號進行分析，一條數據里面可能有幾十上百個信號，要把信號 explode 出來，等于要面對上千億條數據再乘以幾十倍的一個數據量來進行分析。傳統的方式是根本算不出來的，現在變成了近實時的方案，用增量的方案即可實現。

上圖是增量計算的示意圖。每次處理 Delta 數據，有兩種模式，一個是增量計算 MV，另一個是 table stream 的方式。Table stream 方式也支持多分支，可以在一個表上創建多個，然后做 ETL 加工、監控等等，并且不會增加存儲成本，因為底層都是 Meta 支持的，只需要做好應用即可。

增量計算 MV，指的是可以用全量的語義寫邏輯，系統內部自動地以增量的方式計算，而且會自動刷新，不需要配置調度系統自動觸發，所以整個開發過程非常簡單。

（3）提升數據開發及協同效率

在解決用數難的問題方面，還實現了開發和協同效率的提升。比如以前的開發語言有很多種，包括 Java、Python，以及多種 SQL，開發門檻高，業務方使用難。新的平臺統一成了一種語言，同時支持實時和離線分析。

另外，在 Lambda 架構下，業務邏輯要維護多套代碼，基本上所有的廠商都會有面臨這樣的問題，還可能帶來數據不一致的問題。而新的 Kappa 架構下則只需一套代碼。

并且，以前一個新的開發，需要打通多組件、多鏈路、多份數據，效率很低。現在一份數據，一個平臺，不再需要導入導出。

最后，針對元數據割裂的問題，新的架構下統一了元數據，可以很方便地找到結果表的上游是誰，在數據出問題時也可以進行高效地排查。

3. 解決運維煩問題

（1）架構升級，減輕運維負擔

針對運維煩的問題，由原來的 10+ 組件，變成了現在的一套 SaaS 化服務，并且是企業化托管的一套服務，無需投入很大精力，即可輕松完成運維工作。

（2）具備線性能力，避免每年一次升級

另一個非常關鍵的問題是平臺要具備線性能力，避免每年一次升級。隨著業務的增長，處理能力也線性增長，資源成本也以一個可控的方式增長。從上圖中可以看出，在新一代數倉中，隨著數據量的翻倍，資源成本也只是接近翻倍。

觀察真實的生產環境，包括一天中的高峰期、低谷期，可以看到，吞吐與資源的增長基本上也是接近 1:1 的。

ETL 加工上，我們也對實時的數據吞吐和資源消耗進行了對比，基本上也是接近 1: 1 的關系，證明了其線性的能力。

六、總結及后續計劃

我們最終的期望是希望車聯網數據的應用可以像使用自來水一樣簡單，這樣我們可以自由地利用數據做一些車輛上的創新，想用什么數據打開水龍頭即可用。為了實現這一目標，還有很多方向的工作需要做，除了已經規劃的更多業務場景的接入之外，未來還要與 AI 結合，讓業務方更自助地應用。