譯者 | 李睿
審校 | 重樓
車聯網(IoV)是汽車行業與物聯網相結合的產物。預計車聯網數據規模將越來越大，尤其是當電動汽車成為汽車市場新的增長引擎。問題是：用戶的數據平臺準備好了嗎?本文展示了車聯網的OLAP解決方案。
車聯網的數據有什么特別之處?
車聯網的理念很直觀：創建一個網絡，讓車輛之間或與城市交通基礎設施共享信息。通常沒有充分解釋的是每輛車的內部網絡。車聯網連接的每輛汽車都有一個控制器區域網絡(CAN)，作為電子控制系統的通信中心。對于每輛行駛在道路上的汽車來說，CAN是其安全性和功能性的保證，因為它負責：
- 車輛系統監測：CAN是車輛系統的中樞神經。例如，傳感器將檢測到的溫度、壓力或位置發送到CAN；控制器通過CAN向執行器發出命令(例如調整閥門或驅動電機)。
- 實時反饋：傳感器通過CAN將車速、轉向角度、剎車狀態等信息發送給控制器，控制器及時對車輛進行調整，以確保車輛安全。
- 數據共享和協調：CAN允許各種設備之間的數據交換(例如狀態和命令)，因此整個系統可以更加高性能和高效。
- 網絡管理和故障排除：CAN監視系統中的設備和組件。它可以識別、配置和監視設備，以便進行維護和故障排除。
由于CAN如此繁忙，可以想象每天通過CAN傳輸的數據大小。本文討論的是一家汽車制造商將400萬輛汽車通過CAN連接在一起，每天必須處理1000億條CAN數據。
車聯網的數據處理
將這些龐大的數據轉化為指導產品開發、生產和銷售的具有價值的信息是有趣的部分。與大多數數據分析工作負載一樣，這歸結為數據寫入和計算，這也是存在挑戰的地方：
- 大規模數據寫入：傳感器無處不在：車門、座椅、剎車燈……此外，許多傳感器收集的信號不止一個。這400萬輛汽車加起來的數據吞吐量達到數百萬TPS，這意味著每天要處理幾十TB字節的數據。隨著汽車銷量的增長，這一數字仍在增長。
- 實時分析：這可能是“時間就是生命”的最佳體現。汽車制造商從他們的車輛上收集實時數據，以識別潛在的故障，并在任何損壞發生之前修復它們。
- 低成本的計算和存儲：談到龐大的數據規模，必然提到成本。而更低的成本使得大數據處理可持續發展。
從Apache Hive到Apache Doris：向實時分析的過渡
就像羅馬不是一天建成的那樣，實時數據處理平臺也不是一天建成的。一家汽車制造商過去依賴于批處理分析引擎(Apache Hive)和一些流框架和引擎(Apache Flink、Apache Kafka)的組合來獲得接近實時的數據分析性能。直到實時性成為一個問題，他們才意識到他們如此迫切地需要實時性。
近實時數據分析平臺
下圖是這家汽車制造商在過去的做法：
來自CAN和車輛傳感器的數據通過4G網絡上傳到云網關，云網關將數據寫入Kafka。然后，Flink處理這些數據并將其轉發給Hive。通過Hive中的幾個數據倉庫層，將聚合的數據導出到MySQL。最后，Hive和MySQL為應用層提供數據，用于數據分析、Dashboard等。
因為Hive主要是為批處理而不是實時分析而設計的，所以可以在這個用例中看出它的不匹配。
- 數據寫入：由于數據量如此之大，從Flink到Hive的數據攝取時間明顯很長。此外，Hive只支持分區粒度的數據更新，這在某些情況下是不夠的。
- 數據分析：基于Hive的分析解決方案提供了高查詢延遲，這是一個多因素問題。首先，Hive在處理擁有10億行的大型表時比預期的要慢。其次，在Hive內部，數據通過執行Spark SQL從一層提取到另一層，這可能需要一些時間。第三，由于Hive需要與MySQL合作來滿足應用端的所有需求，Hive和MySQL之間的數據傳輸也增加了查詢延遲。
實時數據分析平臺
這就是當他們添加實時分析引擎時所發生的事情:
與原有的基于Hive的平臺相比，這個新的平臺在以下三個方面更高效：
- 數據寫入：Apache Doris中的數據寫入既快捷又簡單，無需復雜的配置和引入額外的組件。它支持各種數據攝取方法。例如，在這種情況下，數據從Kafka通過Stream Load寫入Doris，從Hive通過Broker Load寫入Doris。
- 數據分析：通過示例展示Apache Doris的查詢速度，在跨表連接查詢中，它可以在幾秒鐘內返回1000萬行的結果集。此外，它可以作為一個統一的查詢網關，快速訪問外部數據（Hive、MySQL、Iceberg等），因此分析師不必在多個組件之間切換。
- 計算和存儲成本：Apache Doris提供的Z標準算法可以帶來3~5倍的數據壓縮率。這就是它如何幫助降低數據計算和存儲成本的原因。此外，壓縮可以單獨在Doris中完成，因此它不會消耗Flink的資源。
一個良好的實時分析解決方案不僅強調數據處理速度，它還考慮到數據管道的所有方式，并使它的每一步都變得平滑。以下是兩個示例：
（1）CAN數據的排列
在Kafka中，CAN數據是按照CAN ID的維度來排列的。然而，為了進行數據分析，分析人員必須比較來自不同車輛的信號，這意味著將不同CAN ID的數據連接到一個平面表中，并根據時間戳進行對齊。從這個平面表中，他們可以為不同的分析目的派生出不同的表。這種轉換是使用Spark SQL實現的，這在原有的基于Hive的體系結構中非常耗時，而且SQL語句的維護成本很高。此外，數據是每天批量更新的，這意味著他們只能獲得一天前的數據。
在Apache Doris中，他們所需要的只是用聚合密鑰模型構建表，指定車輛識別號 (VIN)和時間戳作為聚合密鑰，并通過REPLACE_IF_NOT_NULL定義其他數據字段。使用Doris，他們不必處理SQL語句或平面表，而是能夠從實時數據中提取實時見解。
（2）DTC數據查詢
在所有CAN數據中，故障診斷碼（DTC）值得高度關注和單獨存儲，因為它可以告訴汽車出了什么問題。每天，制造商收到大約10億個DTC。為了從DTC獲取拯救生命的信息，數據工程師需要將DTC數據與MySQL中的DTC配置表關聯起來。
他們以前做的是每天將DTC數據寫入Kafka，在Flink中進行處理，然后將結果存儲在Hive中。這樣，DTC數據和DTC配置表就存儲在兩個不同的組件中。這造成了一個困境：一個10億行的DTC表很難寫入MySQL，而從Hive進行查詢的速度很慢。由于DTC配置表也在不斷更新，工程師只能定期將其中的一個版本導入Hive。這意味著他們并不總是能夠將DTC數據與最新的DTC配置聯系起來。
如上所述，Apache Doris可以作為統一查詢網關工作。它的多目錄功能支持這一點。他們將他們的DTC數據從Hive導入到Doris中，然后在Doris中創建一個MySQL目錄來映射到MySQL中的DTC配置表。當所有這些都完成之后，他們可以簡單地連接Doris中的兩個表，并獲得實時查詢響應。
結論
這是一個實際的車聯網實時分析解決方案。它是為大規模數據而設計的，現在正在為一家每天接收100億行新數據的汽車制造商提供支持，以提高駕駛安全性和體驗。
構建一個適合自己的用例的數據平臺并不容易，希望本文能夠幫助用戶構建自己的分析解決方案。
原文標題：How Big Data Is Saving Lives in Real Time: IoV Data Analytics Helps Prevent Accidents，作者：Zaki Lu
