12 月 3 日、4日，2022 Apache IoTDB 物聯網生態大會在線上圓滿落幕。大會上發布 Apache IoTDB 的分布式 1.0 版本，并分享 Apache IoTDB 實現的數據管理技術與物聯網場景實踐案例，深入探討了 Apache IoTDB 與物聯網企業如何共建活躍生態，企業如何與開源社區緊密配合，實現共贏。
我們邀請到長安汽車智能化研究院車云高可用技術主管黃立參加此次大會，并做主題演講——《Apache IoTDB 在長安智能汽車數據平臺的實踐》。以下為內容全文。
各位小伙伴大家好，我叫黃立，來自重慶長安汽車。我今天分享的主題是《Apache IoTDB 在長安智能汽車數據平臺的實踐》。
本次分享一共包含四個部分，第一部分是長安智能汽車數據業務的介紹，第二部分是長安智能汽車大數據處理的架構，第三部分是 IoTDB 在長安大規模時序車況場景的實踐，最后一個部分是長安智能汽車數據平臺的架構展望。
01 長安智能汽車云數據業務概覽
首先介紹一下長安智能汽車數據的一個業務。數字化技術對于汽車進行了深度的重構，汽車從一個配備電子功能的機械產品，逐漸演變為一個配備機械功能的電子產品。云數據及 AI 技術的一個融合逐漸地將汽車變為了一個大型的智能移動終端、數據采集載體、能源儲能單元和一個移動的多功能空間。總的來說，現在的智能汽車已經逐漸轉變為一個具備多功能空間的輪式移動機器人。
消費者他就需要更加的智能，能持續進化的一個汽車。大的來看有兩個場景，第一個是智能座艙的場景，第二個是自動駕駛的場景。智能座艙的場景要求現代智能汽車去適應一個復雜的人機交互，這塊包含語音、手勢和表情的交互。自動駕駛這塊要求智能汽車它能夠去適應復雜的一個路況交通，去應對這種強行加塞、近距跟車和非標車位的場景。
長安汽車在汽車數字化改造的實施路徑上，選擇了一個分階段的數字化改造。大的來看有三個部分：上云、治數和啟智。上云階段主要包含數字汽車 1.0 和 2.0，實現車輛的功能上云、數據上云和應用上云。在治數階段，主要是構建一套適合智能汽車的一個大數據處理平臺，去實現車輛數據賦能、研發與經營，數據和 AI 功能的一個閉環進化。在最后的啟智階段，實際上做的是數字汽車的 4.0，這塊跟國家在推行的智能汽車的云控平臺思路是一致的，通過邊緣云、區域云和中心云的一個架構，去實現整體 V2X 的一個智慧交通的一個融合，全場景數據和先進 AI 的閉環進化。
上云階段，海量接入、功能上云、業務上云和數據上云，長安是打造了自主車企的一個千萬級的智能網聯汽車混合云平臺去賦能研發、產品和服務。大的來看平臺有三個，就是我們的控制平臺、數據平臺和服務平臺。控制平臺主要去實現車端、云端、消費端的一個一體化架構，去滿足多事業部對智能汽車不同的云服務要求，目前是已經支撐了 400 萬網聯車的連接能力，然后預計在 2025 年去提供一個千萬級的接入能力。數據平臺是將傳感數據和車載計算合理地遷移到云端，去構建大數據平臺及分析服務，為服務和產品創新去提供數據的支持。服務平臺在我們內部是做了一個開放平臺，去整合互聯網生態的優勢資源，構建智能網聯生態圈。
云上的業務應用其實跟之前的那種 TSP 平臺是類似的，主要是為用戶去提供一個穩定高效的智能網聯功能，為智能網聯汽車提供全新的一個功能體現與持續更新。功能分兩塊，第一塊其實就是 TSP 平臺主要做的那種數字鑰匙、遠程泊車、遠程控車和診斷，包括那種在線 OTA 升級的一個遠程管車的功能。第二塊就是為用戶去提供一些在線的電臺、音樂、智能推薦、家居聯動、在線的主題、壁紙等互聯娛樂的功能。
在治數階段，主要是要做到車輛控制器的數據上云的改造及標準化，因為我們單個那種車聯網設備，它是少則有差不多五百項，多的有差不多兩千項的信號數據，需要去做采集管理的。這塊我們就可以統一的去做一個數據的采集管理平臺，然后再構建云上的一個海量數據的存儲與處理能力，去確保高質量的數據。第二部分就是去統一車輛的數據資產管理，從“采、治、管、用”四個階段進行車聯網數據的全生命周期的一個跟蹤管理，去確保數據的隱私安全。
車聯網的數據主要是分為四塊，也就是我們的車況大數據，主要包含那種高速看和內線上的那種電車信號、速度和四門兩蓋的信號，交互大數據主要就是包含智能座艙的信號，然后駕駛和環境大數據主要是感知數據和高精地圖相關的一些數據。
最后一個階段啟智，就是通過端云結合的方式，去構建自動駕駛的數據閉環，構建從數據采集、數據處理、模型訓練、控制標定、模型與軟件升級的這樣的一個閉環機制。
然后在長安內部是也做了一些相應的出行習慣特征挖掘、故障預測、能耗分析的場景，我們有月度和年度的用戶的出行的報告，和分析的目的地預測這樣一個報告，然后也會為用戶提供一些配置分析與建議，還有一個就是支持我們內部做動力分析的這樣一個能耗分析，和車輛的故障的預測和診斷的參數。
02 長安智能汽車云大數據處理架構
第二部分介紹的是長安智能汽車云的一個大數據處理架構。
其實車聯網在長安這邊的應用全景圖主要包含四個部分，剛才已經提到了，就是我們的車控、座艙、IoT 的數據接入和 IoT 的車況管理。車況這塊其實主要集中于遠程控制的分析；然后座艙主要是車機埋點和車機的用戶行為。IoT 數據接入這塊包含準入檢測和一些實名的，或者是我們車機的一些激活監控。最后是 IoT 的車況，IoT 的車況其實這一點是面向內部的研發場景，主要做的第一個就是車況的監控，這一塊是直接可以 To C 的，去做到比如說用戶的胎壓異常或者是車門異常。然后在動力研究這塊是做內部的一些油耗分析，或者是我們新能源車的一些電池的三電分析。最后就是剛才看到的那一塊車聯網的大屏。
下面介紹一下長安智能汽車數據平臺的架構，我們內部也是基于 Hadoop 生態去構建的整個車聯網的一個大數據處理平臺，一共分為五層。在數據接入層上，離線的運行主要采用的是 Sqoop，實時的引擎主要采用的是 Flink，然后目前正在驗證 Apache SeaTunnel，希望可以完成 Sqoop 引擎的一個效率的提升和任務穩定性的一個提升。Flink 這塊的話，我們之前是用的 Flume，目前已經用 Flink 完成了整體的實時數據集成的一個任務替代。
然后第二個是數據存儲層，除了常見的 HDFS、Hive、和 Hbase 之外，我們引入了 Doris、IoTDB 和 Redis 去應對車聯網的這種海量的時序數據的一個管理。Doris 主要用做實時數據結果的一個承接；IoTDB 的話，目前我們做了內部驗證，是正在做車況數據的一個 last 點查詢和歷史車況存儲這樣的一個查詢的場景；然后 Redis 是目前我們投產的做實時車況的一個組件。
在資源調度層上，除了 Yarn 之外，在離線任務編排上我們是引入了 Dolphin Scheduler，然后長安內部是從一點一點開始做適用，一直跟到了目前的生產環境上跑的是 1.3.9，然后正在做 3.X 版本的一個驗證。在流應用管理上，我們在 Flink 之上構建了一套 CA-Stream，就是比較簡單的一個流計算管理引擎，它主要實現的這樣的功能就是對 Flink 任務做一些狀態的監控、任務的提交以及配置文件參數的修改，還有 Flink SQL 任務的一個管理。
在計算引擎層上，除了那種 Hive 和 Impala 之外，我們引入了 Kyuubi 這個組件，這個也是今年做的，然后已經是完成了我們 50%-60% 的離線任務，從 Hive 往 kyuubi 上做遷移，去做整體的一個計算穩定性和效率的提升。實時計算引擎上我們主要就是采用 Flink。
然后業務展現層上，就是之前的業務應用介紹到的，我們做內部的研發的 BI 系統、慧眼系統，然后做車輛遠程診斷和遠程預警的系統，還有做遠程調試的系統。最后就是我們用到的一個 BI 組件了，目前是基于 Tableau 做的。
然后整個右側的這種大數據平臺本身的管理，我們是 Cloudera 的一個客戶，然后是用到了 Cloudera 的 Hadoop 發行版。
車聯網的數據集成這塊，長安是一個比較典型的一個混合云的架構，公有云采用的是騰訊云，私有云是在自建的 IDC 里面。我們的車載設備通過自己的 Tbox 或者是 Thu，它會把數據先發到騰訊云的那種 java 后端的應用里面，java應用里面會去完成我們報文的解析。然后通過不同的一個分發引擎，根據不同的業務分發到 Kafka 里，群發到我們公有云上的 Kafka。然后再通過 Flink 引擎，會把公有云的 Kafka 數據同步到私有云的 Kafka。
然后到了私有云的Kafka之后，這個時候就會分為兩條鏈路了。第一條是通過 Flume 直接往私有云的數據平臺落，這一塊的話我們基本上已經完成了改造了，已經用 Flink 統一引擎來完成這種離線的數據寫入和實時的計算了。針對 MySQL 的場景，針對我們部分核心數據庫的 CDC 的場景，我們還是利用了 Canal 去把這些變化的數據攝取到 Kafka 里，然后也是通過兩條鏈路，一條實時走 Flink，一條離線走 Flume 下去的。
整個長安的數據處理架構是一個典型的 Lambda 架構，也就是流批混跑的，然后我們的這個智能車云它主要是基于這個 Lambda 架構，去構建的整個的實時計算和離線計算的 PipeLine，然后去實現整個車聯網、大數據的有序處理和應用。
在樹倉分層這塊，其實也是業界比較主流的方案吧，就是 ODS、DWD、DWS 和 DM。DWD 做一些輕度聚合的明細數據，DWS 做中度聚合，DM 直接生成結構表。DM 這塊其實我們目前正在往 Doris 里面做遷移。
實時計算的鏈路上，主要就是通過 Kafka 作為實時的數據倉庫，然后通過 Flink 也是兩條鏈路。有一條的話是通過原始數據經過 Flink 直接落到 Doris 里面去，然后通過后端的 Doris 上的那些物化視圖或者 RollUp 表，去完成這種實時數倉的計算。第二個就是做大屏的場景，做大屏的場景我們其實會直接通過 Flink 算結果，把它算到 Redis 里面，然后直接用后端的應用來查 Redis。
03 IoTDB 在長安大規模時序車況場景的實踐
第三部分就是介紹一下 IoTDB 在長安的一個大規模時序車況場景的實踐。
車聯網其實是一個非常典型的這種物聯網的場景，那么物聯網的場景它的數據一定是時序數據。整個時序數據的生命周期，其實分為采集、緩存、處理、存儲、查詢/分析和可視化應用這六個大的一個階段。
在采集這一塊，其實主要就是我們的設備和傳感器，對應到車聯網上就是我們的 Tbox 和 Thu。緩存的時候通過邊緣的網關，當然我們不是每一類的數據都需要做到那種實時的上傳，有的數據它會在本地先做一個比如說五秒或者十秒的緩存，然后再批量的去往云端做發送，這個就是緩存。到了云上之后，就會通過應用攝取到這個報文，做一定的解析，發到消息隊列里面，然后再通過一個消息分發這樣的一個組件，把不同業務所需要的時序消息分發到不同的存儲端上。最后就是可以利用我們的這個計算平臺，也就是其實一般已經到了 java 應用的部分了，就是我們的后端引擎會直接對到存儲引擎上，去做可視化的一些應用。
車聯網的這個海量時序車況管理的挑戰，其實主要還是一個體量的問題，因為長安目前它是一個以量產車為主的這樣一個場景，目前的話我們整個平臺接入了近三百萬的網聯車。然后大的挑戰主要就有三個，第一個是百萬級車輛的一個海量車況的高效傳輸和處理。
第二是我們的信號，它是分為這種高速信號，它是毫秒級采集的，常規信號是 30 秒一采的，平均下來的話，它的那個數據量每秒的話基本上是百萬條。
然后單車的一個多時間序列的一個高效查詢和單車全時間序列的最新點的查詢，其實這個就是車聯網里面很經典的實時車況和離線車況，也就是我們歷史車況的一個查詢場景。當然有的平臺架構上也叫做設備影子這樣一個功能。大的來看的話就是三個挑戰，體量大、高速性和數據的一個多樣性。
目前長安內部的一個大規模時序數據管理的架構，分為 1.0 和 2.0 的版本。其實剛才已經提到了，我們車上的這個 Tbox、Thu，去基于長安私有的 TCP 協議，然后我們自己基于 Netty，去寫了一套網關接報文的，通過 CLB 進到 K8s 的 TU-GW 應用里面之后，就會去對報文做解析。解析完之后再通過后面的那些業務的應用和分發引擎，將這些車況的數據和報文的數據分發到不同的 Kafka 集群里面。
然后我們針對車況這個場景，主要的時序存儲引擎是 HBase，也就是我們的歷史車況會往 HBase 里面寫。然后 2.0 的架構，我們就是采用了 Flink 接 Kafka 的數據寫入 IoTDB。整個架構升級上，我們目前做測試的體量是差不多一秒 150 萬條數據，然后一條數據的話差不多是有 15 到 20 個測點的樣子，平均的話可能也就 16、17 個測點。
然后在差不多千萬級的寫入體量下的話，我們之前的 HBase 集群是有 10 個Region Server，并且 HBase 它的存儲架構的話，因為我們沒有使用 OpenTSDB 那樣的引擎，它是不支持這種最新車況的查詢的，我們之前的那一版最新車況是基于 Redis 實現的。
目前我們做的 2.0 的版本，就可以通過統一的引擎 IoTDB，來完成一秒 150 萬車況數據的一個寫入。然后現在我們測的這個場景是采用了一個單機高 IO 的機型，也就是我們的大內存+全 SSD 這樣的一個集群。內存差不多是 384G，然后應該是有接近 50 個 T 的 SSD，然后是單機，采用的是 0.12.3 的一個版本。寫入到存儲引擎之后，后面就是我們的 TSP 業務系統和 APP 針對我這輛車的一個最新數據和歷史車況，這兩個場景來做一個查詢了。
整個時序模型設計這塊的話，我們采用了 IoTDB 一套引擎，去實現了單車時間范圍的查詢和單車全時間序列最新點的查詢，然后測出來目前都是毫秒級返回，準備是用這一套方案去替換掉 HBase+Redis 方案的一個復雜度。
那針對查詢來看的話，單設備的時間范圍的查詢就采用了這種 select，然后前面加上了 CANID、加信號名稱，然后 from 這樣的一個存儲結構。這個存儲結構當時為什么那么設計呢？就是根和業務名稱就不說了，在設備層我們采用的是 Tbox 的 TUID，也就是設備 ID，作為它的一個第三級節點。最后其實就是在測點層，測點層除了信號名之外，我們在前面給它拼上了 CANID，這個也是想利用 IoTDB 的那種 select，然后下滑線帶 * 這樣的查詢，可以查出來這一輛車在某一個 CANID 下面的所有的信號，去做這樣的一個查詢場景。
基于這樣的一個模型設計，我們就可以采用這種單設備的時間范圍掃描，就是帶 TS 和不帶 TS 的這種 last * 的場景，去完成我們之前要采用兩套引擎實現的這個車聯網場景下的一個實時車況和歷史車況組合查詢這樣一個場景。
IoTDB 在長安的查詢的一個性能上來看的話，我們目前就是單機接入了差不多 57 萬的設備，托管了時間序列是 1.5 億，然后單車的一個時間范圍掃描和單車 last 點的查詢，均可以實現毫秒級的返回。下一步的話，我們是計劃去引入 IoTDB 的分布式版本，去保證時序引擎的一個穩定性，進一步去擴大車系的一個接入體量。
這一塊為什么還沒有把 IoTDB 投產到我們的生產環境里面，去做 To C 的一些業務呢？是因為我們在測 12 版本的分布式引擎的時候，發現之前那版的分布式版本的實現，它并不能解決大的元數據的問題。因為長安目前是量產車，現在接了 57 萬、托管的時間序列差不多有 1.5 億，單機的內存管理上，我們針對元數據這塊，內存分配是做過了多次調整的，才能保證這個單機目前運行了差不多有一年的樣子。當時測出來的那個時序版本，它的穩定性還有待進一步提升，然后在本次就是 IoTDB 發布的這個 1.0 版本，新的分布式引擎的場景下的話，我們是會去做進一步測試的。
04 長安智能汽車數據平臺架構展望
最后分享一下長安智能汽車數據平臺的一個架構展望。
總的來說目前長安基于 Cloudera 的 Hadoop 發行版，和 Apache 提供的一些開源的組件，像 Doris、Kyuubi、IoTDB 去補齊了相關的智能汽車特定場景下的這種大規模時序管理、實時數倉和離線加速的一些場景。但是我們仍然有三個地方需要去做增強和改進的。
那么第一點就是，整個的關系庫的近實時化和離線數倉的近實時化，這塊是亟待解決的。因為目前來說，我們仍然是采用 Sqoop 或者是 SeaTunnel，然后在每天的凌晨去大量的拖關系庫的表，去做離線數倉的數據攝取。然后這塊我們是希望可以引入這種現在比較熱的一些數據庫框架，像 Hudi 或 Iceberg 這樣的框架，去解決我們的一個數倉近實時化，和關系庫的一個數據增量攝取的問題。
第二點就是 Kyuubi 這個引擎。我們目前僅僅是用來做離線數倉的一個任務加速，但是并沒有把它作為一個統一的這個 SQL 網關層或者 SQL 路由層，給對接到我們所有的存儲引擎上，像可以把 Hive 和 Doris，包括我們后續引入的數據庫框架對接上，那么它就可以統一的作為一個 SQL 網關來使用。然后做了統一的 SQL 網關之后，我們的數據血緣就不再需要去使用到這個 Apache Atlas 這樣的組件了，我們可以在 SQL 網關層去加一些插件做血緣解析。只要把入口管住了，其實我們很多東西，包括血緣和權限這兩塊，實現起來都會更加的輕量和容易。
然后第三點就是剛才提到的我們的 IoTDB，目前還是用的一個單機的版本，去面向企業內部研發工程師做故障排查的場景，去查這個離線和實時的車況。然后這塊的話，我們是希望就是應用到最近 IoTDB 發布的這個 V1.0 版本的新的分布式引擎，去能夠實現一個大規模網聯車的接入。最好是能夠直接去替換掉我們現在現有的 Redis 和 HBase 這兩套基于車況的實時和離線的這種歷史車況的實現，去減輕整個架構的復雜度。
最后也感謝 IoTDB 社區和清華大學帶來的這么優秀的一個時序數據引擎。以上就是我分享的全部內容，謝謝大家。
更多內容推薦：
? 了解更多 IoTDB 應用案例
? 回顧 IoTDB 2022 大會全內容
