譯者 | 李睿

審校 | 重樓

車聯(lián)網(wǎng)(IoV)是汽車行業(yè)與物聯(lián)網(wǎng)相結(jié)合的產(chǎn)物。預(yù)計(jì)車聯(lián)網(wǎng)數(shù)據(jù)規(guī)模將越來越大，尤其是當(dāng)電動汽車成為汽車市場新的增長引擎。問題是：用戶的數(shù)據(jù)平臺準(zhǔn)備好了嗎?本文展示了車聯(lián)網(wǎng)的OLAP解決方案。

車聯(lián)網(wǎng)的數(shù)據(jù)有什么特別之處?

車聯(lián)網(wǎng)的理念很直觀：創(chuàng)建一個(gè)網(wǎng)絡(luò)，讓車輛之間或與城市交通基礎(chǔ)設(shè)施共享信息。通常沒有充分解釋的是每輛車的內(nèi)部網(wǎng)絡(luò)。車聯(lián)網(wǎng)連接的每輛汽車都有一個(gè)控制器區(qū)域網(wǎng)絡(luò)(CAN)，作為電子控制系統(tǒng)的通信中心。對于每輛行駛在道路上的汽車來說，CAN是其安全性和功能性的保證，因?yàn)樗?fù)責(zé)：

• 車輛系統(tǒng)監(jiān)測：CAN是車輛系統(tǒng)的中樞神經(jīng)。例如，傳感器將檢測到的溫度、壓力或位置發(fā)送到CAN；控制器通過CAN向執(zhí)行器發(fā)出命令(例如調(diào)整閥門或驅(qū)動電機(jī))。
• 實(shí)時(shí)反饋：傳感器通過CAN將車速、轉(zhuǎn)向角度、剎車狀態(tài)等信息發(fā)送給控制器，控制器及時(shí)對車輛進(jìn)行調(diào)整，以確保車輛安全。
• 數(shù)據(jù)共享和協(xié)調(diào)：CAN允許各種設(shè)備之間的數(shù)據(jù)交換(例如狀態(tài)和命令)，因此整個(gè)系統(tǒng)可以更加高性能和高效。
• 網(wǎng)絡(luò)管理和故障排除：CAN監(jiān)視系統(tǒng)中的設(shè)備和組件。它可以識別、配置和監(jiān)視設(shè)備，以便進(jìn)行維護(hù)和故障排除。

由于CAN如此繁忙，可以想象每天通過CAN傳輸?shù)臄?shù)據(jù)大小。本文討論的是一家汽車制造商將400萬輛汽車通過CAN連接在一起，每天必須處理1000億條CAN數(shù)據(jù)。

車聯(lián)網(wǎng)的數(shù)據(jù)處理

將這些龐大的數(shù)據(jù)轉(zhuǎn)化為指導(dǎo)產(chǎn)品開發(fā)、生產(chǎn)和銷售的具有價(jià)值的信息是有趣的部分。與大多數(shù)數(shù)據(jù)分析工作負(fù)載一樣，這歸結(jié)為數(shù)據(jù)寫入和計(jì)算，這也是存在挑戰(zhàn)的地方：

• 大規(guī)模數(shù)據(jù)寫入：傳感器無處不在：車門、座椅、剎車燈……此外，許多傳感器收集的信號不止一個(gè)。這400萬輛汽車加起來的數(shù)據(jù)吞吐量達(dá)到數(shù)百萬TPS，這意味著每天要處理幾十TB字節(jié)的數(shù)據(jù)。隨著汽車銷量的增長，這一數(shù)字仍在增長。
• 實(shí)時(shí)分析：這可能是“時(shí)間就是生命”的最佳體現(xiàn)。汽車制造商從他們的車輛上收集實(shí)時(shí)數(shù)據(jù)，以識別潛在的故障，并在任何損壞發(fā)生之前修復(fù)它們。
• 低成本的計(jì)算和存儲：談到龐大的數(shù)據(jù)規(guī)模，必然提到成本。而更低的成本使得大數(shù)據(jù)處理可持續(xù)發(fā)展。

從Apache Hive到Apache Doris：向?qū)崟r(shí)分析的過渡

就像羅馬不是一天建成的那樣，實(shí)時(shí)數(shù)據(jù)處理平臺也不是一天建成的。一家汽車制造商過去依賴于批處理分析引擎(Apache Hive)和一些流框架和引擎(Apache Flink、Apache Kafka)的組合來獲得接近實(shí)時(shí)的數(shù)據(jù)分析性能。直到實(shí)時(shí)性成為一個(gè)問題，他們才意識到他們?nèi)绱似惹械匦枰獙?shí)時(shí)性。

近實(shí)時(shí)數(shù)據(jù)分析平臺

下圖是這家汽車制造商在過去的做法：

來自CAN和車輛傳感器的數(shù)據(jù)通過4G網(wǎng)絡(luò)上傳到云網(wǎng)關(guān)，云網(wǎng)關(guān)將數(shù)據(jù)寫入Kafka。然后，F(xiàn)link處理這些數(shù)據(jù)并將其轉(zhuǎn)發(fā)給Hive。通過Hive中的幾個(gè)數(shù)據(jù)倉庫層，將聚合的數(shù)據(jù)導(dǎo)出到MySQL。最后，Hive和MySQL為應(yīng)用層提供數(shù)據(jù)，用于數(shù)據(jù)分析、Dashboard等。

因?yàn)镠ive主要是為批處理而不是實(shí)時(shí)分析而設(shè)計(jì)的，所以可以在這個(gè)用例中看出它的不匹配。

• 數(shù)據(jù)寫入：由于數(shù)據(jù)量如此之大，從Flink到Hive的數(shù)據(jù)攝取時(shí)間明顯很長。此外，Hive只支持分區(qū)粒度的數(shù)據(jù)更新，這在某些情況下是不夠的。
• 數(shù)據(jù)分析：基于Hive的分析解決方案提供了高查詢延遲，這是一個(gè)多因素問題。首先，Hive在處理擁有10億行的大型表時(shí)比預(yù)期的要慢。其次，在Hive內(nèi)部，數(shù)據(jù)通過執(zhí)行Spark SQL從一層提取到另一層，這可能需要一些時(shí)間。第三，由于Hive需要與MySQL合作來滿足應(yīng)用端的所有需求，Hive和MySQL之間的數(shù)據(jù)傳輸也增加了查詢延遲。

實(shí)時(shí)數(shù)據(jù)分析平臺

這就是當(dāng)他們添加實(shí)時(shí)分析引擎時(shí)所發(fā)生的事情:

與原有的基于Hive的平臺相比，這個(gè)新的平臺在以下三個(gè)方面更高效：

• 數(shù)據(jù)寫入：Apache Doris中的數(shù)據(jù)寫入既快捷又簡單，無需復(fù)雜的配置和引入額外的組件。它支持各種數(shù)據(jù)攝取方法。例如，在這種情況下，數(shù)據(jù)從Kafka通過Stream Load寫入Doris，從Hive通過Broker Load寫入Doris。
• 數(shù)據(jù)分析：通過示例展示Apache Doris的查詢速度，在跨表連接查詢中，它可以在幾秒鐘內(nèi)返回1000萬行的結(jié)果集。此外，它可以作為一個(gè)統(tǒng)一的查詢網(wǎng)關(guān)，快速訪問外部數(shù)據(jù)（Hive、MySQL、Iceberg等），因此分析師不必在多個(gè)組件之間切換。
• 計(jì)算和存儲成本：Apache Doris提供的Z標(biāo)準(zhǔn)算法可以帶來3~5倍的數(shù)據(jù)壓縮率。這就是它如何幫助降低數(shù)據(jù)計(jì)算和存儲成本的原因。此外，壓縮可以單獨(dú)在Doris中完成，因此它不會消耗Flink的資源。

一個(gè)良好的實(shí)時(shí)分析解決方案不僅強(qiáng)調(diào)數(shù)據(jù)處理速度，它還考慮到數(shù)據(jù)管道的所有方式，并使它的每一步都變得平滑。以下是兩個(gè)示例：

（1）CAN數(shù)據(jù)的排列

在Kafka中，CAN數(shù)據(jù)是按照CAN ID的維度來排列的。然而，為了進(jìn)行數(shù)據(jù)分析，分析人員必須比較來自不同車輛的信號，這意味著將不同CAN ID的數(shù)據(jù)連接到一個(gè)平面表中，并根據(jù)時(shí)間戳進(jìn)行對齊。從這個(gè)平面表中，他們可以為不同的分析目的派生出不同的表。這種轉(zhuǎn)換是使用Spark SQL實(shí)現(xiàn)的，這在原有的基于Hive的體系結(jié)構(gòu)中非常耗時(shí)，而且SQL語句的維護(hù)成本很高。此外，數(shù)據(jù)是每天批量更新的，這意味著他們只能獲得一天前的數(shù)據(jù)。

在Apache Doris中，他們所需要的只是用聚合密鑰模型構(gòu)建表，指定車輛識別號 (VIN)和時(shí)間戳作為聚合密鑰，并通過REPLACE_IF_NOT_NULL定義其他數(shù)據(jù)字段。使用Doris，他們不必處理SQL語句或平面表，而是能夠從實(shí)時(shí)數(shù)據(jù)中提取實(shí)時(shí)見解。

（2）DTC數(shù)據(jù)查詢

在所有CAN數(shù)據(jù)中，故障診斷碼（DTC）值得高度關(guān)注和單獨(dú)存儲，因?yàn)樗梢愿嬖V汽車出了什么問題。每天，制造商收到大約10億個(gè)DTC。為了從DTC獲取拯救生命的信息，數(shù)據(jù)工程師需要將DTC數(shù)據(jù)與MySQL中的DTC配置表關(guān)聯(lián)起來。

他們以前做的是每天將DTC數(shù)據(jù)寫入Kafka，在Flink中進(jìn)行處理，然后將結(jié)果存儲在Hive中。這樣，DTC數(shù)據(jù)和DTC配置表就存儲在兩個(gè)不同的組件中。這造成了一個(gè)困境：一個(gè)10億行的DTC表很難寫入MySQL，而從Hive進(jìn)行查詢的速度很慢。由于DTC配置表也在不斷更新，工程師只能定期將其中的一個(gè)版本導(dǎo)入Hive。這意味著他們并不總是能夠?qū)TC數(shù)據(jù)與最新的DTC配置聯(lián)系起來。

如上所述，Apache Doris可以作為統(tǒng)一查詢網(wǎng)關(guān)工作。它的多目錄功能支持這一點(diǎn)。他們將他們的DTC數(shù)據(jù)從Hive導(dǎo)入到Doris中，然后在Doris中創(chuàng)建一個(gè)MySQL目錄來映射到MySQL中的DTC配置表。當(dāng)所有這些都完成之后，他們可以簡單地連接Doris中的兩個(gè)表，并獲得實(shí)時(shí)查詢響應(yīng)。

結(jié)論

這是一個(gè)實(shí)際的車聯(lián)網(wǎng)實(shí)時(shí)分析解決方案。它是為大規(guī)模數(shù)據(jù)而設(shè)計(jì)的，現(xiàn)在正在為一家每天接收100億行新數(shù)據(jù)的汽車制造商提供支持，以提高駕駛安全性和體驗(yàn)。

構(gòu)建一個(gè)適合自己的用例的數(shù)據(jù)平臺并不容易，希望本文能夠幫助用戶構(gòu)建自己的分析解決方案。

原文標(biāo)題：How Big Data Is Saving Lives in Real Time: IoV Data Analytics Helps Prevent Accidents，作者：Zaki Lu