一、背景介紹

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

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

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

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

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

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

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

1. 成本高

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

2. 用數(shù)難

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

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

3. 運(yùn)維煩

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

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

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

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

• 實(shí)時(shí)鏈路

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

• 離線鏈路

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

2. 挑戰(zhàn)

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

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

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

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

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

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

五、改造后的價(jià)值與效果

1. 解決成本高問題

（1）存儲(chǔ)成本

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

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

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

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

（2）計(jì)算成本

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

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

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

（1）提升查詢性能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 解決運(yùn)維煩問題

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

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

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

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

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

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

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

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