一、背景介紹

“以前人們稱汽車為配備電子功能的機(jī)械產(chǎn)品，到今天演變?yōu)榫哂袡C(jī)械功能的智能電子產(chǎn)品，這是一個非常大的轉(zhuǎn)變。”—— 長安云器聯(lián)合項目組 石靜猛

轉(zhuǎn)變，源自產(chǎn)業(yè)的數(shù)字化轉(zhuǎn)型。新能源汽車廠商正在用數(shù)字化技術(shù)打造差異性的競爭優(yōu)勢，關(guān)注點由發(fā)動機(jī)的制造逐漸趨向于基于數(shù)字化技術(shù)打造豐富的用戶體驗。

中國的汽車產(chǎn)業(yè)正在高速發(fā)展的過程中完成數(shù)字化升級，我國汽車產(chǎn)銷總量連續(xù)15年穩(wěn)居全局全球第一。在產(chǎn)銷快速增長的同時，車企正在通過數(shù)字化提升乘用車產(chǎn)品的競爭力。

（圖1：汽車產(chǎn)銷總量及增長率）

數(shù)字化關(guān)系到車輛如何更好地應(yīng)用，如何更好地跟人互動，與人們的生活打通，包括更廣為人知的智能化自動駕駛、智能座艙等應(yīng)用場景，以及不為人所知的汽車設(shè)計、生產(chǎn)制造過程，數(shù)字化正在重構(gòu)汽車工業(yè)。

二、長安汽車面對的挑戰(zhàn)

面對超大規(guī)模數(shù)據(jù)量和業(yè)務(wù)的飛速發(fā)展，長安大數(shù)據(jù)平臺面臨的挑戰(zhàn)可以總結(jié)為三大方面，即成本高、用數(shù)難、運維煩。

1. 成本高

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

2. 用數(shù)難

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

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

3. 運維煩

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

三、改造前的架構(gòu)和挑戰(zhàn)

1. 改造前的架構(gòu)

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

• 實時鏈路

使用 Flink 對數(shù)據(jù)進(jìn)行一些簡單的加工，加工后的數(shù)據(jù)寫到 Doris、ClickHouse 或StarRocks 等分析型平臺上。中間也包括一些 HBase 的應(yīng)用。

• 離線鏈路

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

2. 挑戰(zhàn)

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

其次，很多 JSON 這種半結(jié)構(gòu)化數(shù)據(jù)，信號列非常多，隨著新能源車數(shù)據(jù)產(chǎn)品應(yīng)用的場景越來越多，信號列增長非常快。

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

四、改造后的架構(gòu)介紹

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

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

五、改造后的價值與效果

1. 解決成本高問題

（1）存儲成本

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

實現(xiàn)這一改進(jìn)的關(guān)鍵措施如下：

在Parquet存儲上自研了更多編碼優(yōu)化，對半結(jié)構(gòu)化數(shù)據(jù)自研map格式存儲，壓縮率比JSON更高，查詢效率也更高，在存儲上對數(shù)據(jù)進(jìn)行了行級+信號級的二級去重。

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

（2）計算成本

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

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

2. 解決用數(shù)難問題

（1）提升查詢性能

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

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

實現(xiàn)這一提升，歸功于查詢 plan 的優(yōu)化，ShareEverything 架構(gòu)下更高效的讀寫性能，以及算子優(yōu)化、向量執(zhí)行、shuffle 加速等一系列改進(jìn)。

（2）實現(xiàn)低成本下的 100% 數(shù)據(jù)實時

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

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

同時對延遲數(shù)據(jù)也能進(jìn)行加工，因為能夠識別出延遲數(shù)據(jù)落在哪個業(yè)務(wù)分區(qū)，增量計算只算那個分區(qū)相關(guān)的結(jié)果即可。整個數(shù)倉建成了一個實時的數(shù)倉，支撐車企的各項業(yè)務(wù)應(yīng)用。

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

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

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

（3）提升數(shù)據(jù)開發(fā)及協(xié)同效率

在解決用數(shù)難的問題方面，還實現(xiàn)了開發(fā)和協(xié)同效率的提升。比如以前的開發(fā)語言有很多種，包括 Java、Python，以及多種 SQL，開發(fā)門檻高，業(yè)務(wù)方使用難。新的平臺統(tǒng)一成了一種語言，同時支持實時和離線分析。

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

并且，以前一個新的開發(fā)，需要打通多組件、多鏈路、多份數(shù)據(jù)，效率很低。現(xiàn)在一份數(shù)據(jù)，一個平臺，不再需要導(dǎo)入導(dǎo)出。

最后，針對元數(shù)據(jù)割裂的問題，新的架構(gòu)下統(tǒng)一了元數(shù)據(jù)，可以很方便地找到結(jié)果表的上游是誰，在數(shù)據(jù)出問題時也可以進(jìn)行高效地排查。

3. 解決運維煩問題

（1）架構(gòu)升級，減輕運維負(fù)擔(dān)

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

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

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

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

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

六、總結(jié)及后續(xù)計劃

我們最終的期望是希望車聯(lián)網(wǎng)數(shù)據(jù)的應(yīng)用可以像使用自來水一樣簡單，這樣我們可以自由地利用數(shù)據(jù)做一些車輛上的創(chuàng)新，想用什么數(shù)據(jù)打開水龍頭即可用。為了實現(xiàn)這一目標(biāo)，還有很多方向的工作需要做，除了已經(jīng)規(guī)劃的更多業(yè)務(wù)場景的接入之外，未來還要與 AI 結(jié)合，讓業(yè)務(wù)方更自助地應(yīng)用。