倪峻




以智能網聯大數據在高并發場景下的應用為基礎,分析了目前汽車行業主流數據平臺技術的優勢與劣勢。以實際業務需求出發,制定了融合離線數據平臺和實時數據平臺的車聯網大數據平臺架構,以及基于部分開源產品組件,結合自主開發組件的解決方案。通過平臺的開發交付、迭代優化,以及業務應用過程中的案例分析,梳理出該數據平臺的技術特點,并提出了后續改進和擴展的技術思路。
智能網聯;數據平臺;實時數據;離線數據;數據化
0 前言
隨著車聯網和物聯網功能在汽車行業逐步成為標配,通過智能網聯的應用提升產品整體競爭力和用戶體驗,已成為所有汽車整車企業、零部件企業,甚至汽車服務企業需要重點關注的領域之一。為了在滿足國家法律法規要求,以及全國各地甚至國外地區車輛準入條件的前提下,同時盡可能地滿足用戶的個性化、整車智能化等需求,與車聯網相關的數據采集、傳輸、接收、轉發、保存、分析、應用等,已成為智能網聯板塊非常關鍵的環節[1]。
根據車輛動力不同,車輛可分為燃油車、純電動車、燃料電池車等;根據使用場景的不同,車輛可以分為偏個人客戶的乘用車、偏商務用戶的商用車,以及工程機械與房車等。在不同動力和應用場景下,車輛行駛數據、駕駛行為數據、車載設備數據、車輛周邊環境數據,以及采集范圍、頻率、數據包大小、數據格式、加密解密、數據響應時效(實時/準實時/非實時)等各項因素,都需要在架構方案設計時進行綜合考慮和統籌平衡。
本文以實現商乘并舉、多車型、多公司、多場景復用的智能網聯數據平臺為目標,對比分析了目前幾種主要的數據平臺技術,綜合考慮實際應用需求、投入產出、預留擴展性等因素,制定了基于部分開源組件加自主開發的架構和技術方案,完成平臺的整體搭建實施,并通過不斷的數據化應用和分析,持續推進數據平臺的迭代和優化。
1 應用場景分析
智能網聯最基本的數據需求,源于國家和地方政府對于新能源車輛安全行駛的管控要求,采集的數據包括基本的里程數、行駛軌跡、充放電情況等,逐步增加擴展到動力電池狀態、電動機狀態等數百個參數。隨著國家對于國六車型數據標準的推廣與實施,未來車聯網數據標準將成為所有車型的準入要求。除了基本法規標準的要求外,為了實現智能網聯的更多應用,如興趣點(POI)推送、人車智能交互、初級智能駕駛、車隊管理、客貨倉管理、租賃車輛遠程智能控制等功能,技術人員需要采集大量的車輛行駛數據、用戶駕駛行為數據、車載設備或車輛周邊環境數據。由于應用場景的實時性需求,有些數據在車輛本地的車機端就直接完成了采集和應用,而更大部分的數據,由于車機本地算力的限制,以及綜合應用的需要,都需要通過遠程通訊模塊(TBOX)和傳輸通道回傳到車聯網平臺(TSP)云端。數據格式包括文本、音頻、視頻等多種形式。數據采集的頻率從最初的幾十秒/次,逐步縮短到數秒/次,有些用于研發分析和故障診斷的數據采集頻率可能會更高。每個數據包大小從幾個千字節到十幾個千字節不等。根據每日平均在線車輛數的估算,每日近萬臺車輛的上傳數據將達到幾百個吉字節。這對于云端大數據平臺的容量和性能都是很高的要求[2]。
目前,主流的數據平臺技術和特點如表1所示。為了滿足大量數據的讀寫需求,主流的數據平臺可分為結構化數據庫和分布式數據庫。結構化數據庫通過提升節點硬件性能來實現大量數據的讀寫需求,但最終會達到縱向擴展的上限;而分布式數據庫則可通過擴展多套并行的數據節點來實現大數據的讀寫需求,理論上并沒有擴展的上限[3]。結構化數據庫的最大優勢是穩定性和單節點性能,而分布式數據庫的優勢在于操作的擴展性和數據的大量處理。在高并發場景下,Mysql數據庫被設計用來存放用戶在移動端等觸點上的在線行為或訂單交易等數據;Oracle數據庫被設計用來存放車輛配置、研發和生產等結構化標準化數據;MongoDB/Hbase數據庫被設計用來存放車輛行駛、駕駛行為,以及車機端娛樂主機等數據;Redis數據庫被設計用來存放高性能緩存數據,以滿足高速的數據讀取需求。作為大數據平臺的基礎架構,Hadoop數據庫在此基礎上為Hive/Spark提供查詢和計算引擎功能,Kafka數據庫則承擔接收高并發大數據的車機端上傳功能,并同時轉發給多個下級數據處理模塊。
2 智能網聯數據平臺架構
2.1 應用架構
智能網聯作為未來智能駕駛、萬物互聯、智慧城市的重要基礎設施,主要包含了“端、管、云”三大部分。其中,“端”包含了整車本身,以及核心的車控單元、車載主機、TBOX,以及各類車載操作系統和應用軟件等,可以看作是1個大號的手機或者1臺移動的計算機終端;“管”主要包括通信和數據傳輸所需要的運營商基站、無線傳輸通道,以及通信協議、加密協議等軟硬件系統;“云”則包含了接入網關、業務應用,平臺應用等。其中,業務應用包括面向個人車主的服務、面向大客戶車主的企業服務,以及面向政府的監管服務等;平臺應用包括基礎的車控服務、數據服務、生態服務、安全服務等。此外,與用戶的數字化觸點,如應用程序(APP)、小程序、全球廣域網(Web)應用等,以及這些觸點背后的系統平臺,都屬于廣義“云”的范疇。圖1為智能網聯TSP平臺的應用架構圖。
通過數據流,以上應用架構可以簡單說明如下:車輛行駛數據、車主或司機的駕駛行為通過各類TBOX、AVN等設備上傳至接入網關,考慮到并發容量,以及數據安全等因素,技術人員需要設置多種不同類型和用戶的網關?;谄髽I存量車的歷史原因,有些上聯設備之前已經有了異構的網聯平臺(比如上柴發動機、紅巖重卡等),可以通過“云云對接”的方式接入數據。數據在進入網關后,所有數據都會首先保存到大數據平臺,大數據平臺會根據數據的類型和應用需求不同,執行分類備份和歸檔策略。然后,系統根據應用的實時性要求進行處理。有的數據必須立刻轉發給相關的平臺,如國家或地方的遠程監控平臺。此外,根據各個應用的不同需求,系統將簡單加工過的數據(加密、解密等處理)傳遞到不同的應用服務。除了車機端上傳的數據,用戶在數字化觸點,如APP、小程序、Web應用等產生的數據,會通過相應的系統后臺傳遞到統一的大數據平臺。這個過程中還有1個關鍵步驟,即“用戶數據打通”。通過統一數據抽?。∣neID)機制,將不同渠道獲取的數據,通過不同密鑰標識符(keyID)進行關聯,最終完善多場景下的用戶標簽,為后續“數字孿生”奠定基礎。除此之外,車輛遠程控制、FOTA等下行數據,也是通過云端平臺和網關分發到不同的車機終端的。
智能網聯除了實現基本的車聯網功能外,最為核心的價值就是實現移動出行相關的數據采集、傳輸、分析和應用。通過對這些大數據的應用,可以提升智能駕駛、產品功能,以及用戶體驗,被稱為“從業務數據化到數據業務化”的持續迭代。因此,智能網聯的數據平臺是整個車聯網平臺的非常關鍵的組成部分,而且該數據平臺并不僅僅屬于車聯網的數據平臺,更是整個企業級的數據平臺。通過智能網聯數據平臺,可以打通并整合企業的用戶數據和車輛數據(圖2)。目前,企業應用的大數據平臺主要分為離線平臺和實時平臺2部分。其中,數據存儲主要存放于Hadoop集群中。Hadoop集群目前總共有3個管理節點和25個數據節點。
其中,OGG為Oracle Golden Gate軟件;DX為數據交換模塊;CDP為客戶數據平臺;Spark on Yarn為基于Yarn集群運行的Spark計算框架;RDBMS為關系數據庫管理系統;SQDT為報表記錄集;SSO為單點登錄。
2.2 離線平臺
2.2.1 數據倉庫抽取技術(ETL)匯總數據源
為了避免對生產環境數據庫造成影響,所有的ETL任務數據源分為2種模式抽取數據。對于Oracle數據庫,采用Oracle GoldenGate軟件將數據實時抽取到1臺Oracle數據庫中,ETL統一從該數據庫抽取數據;對于Mysql和SqlServer數據庫,統一使用只讀備庫來抽取數據。
2.2.2 ETL任務調度
智能網聯大數據使用自主開發的Kangaroo任務調度系統。該系統支持多租戶模式,可以將多個租戶納入同一系統進行管理,同時又能使各租戶的業務在物理和邏輯層面進行隔離,避免互相影響,保證數據安全。
2.2.3 Hive/Spark
Hive/Spark計算引擎提供了2種不同的引擎對離線數據進行查詢功能,其中Hive的查詢時間較長,但占用系統資源相對較少,Spark引擎則相反。
2.2.4 Hbase
目前,Hbase數據庫主要用于存放車聯網數據,分為生產集群和歸檔集群2部分。生產集群為生產業務提供服務,歸檔數據則用于存放歷史數據。
2.3 實時平臺
2.3.1 Kafka
Kafka數據收發系統主要用于數據通道,實時獲取斑馬系統實時埋點、蜘蛛智聯系統實時埋點、車聯網系統埋點、車聯網系統警告、房車全球定位系統(GPS)信號等數據。后續需求還有車機埋點數據,發動機信號數據接入等服務。
2.3.2 Spark/Flink
Spark/Flink數據處理引擎主要用于處理計算Kafka接收的數據。相比Spark計算引擎,Flink計算引擎能夠更方便地控制小文件的生成,緩解車聯網集群的性能壓力。
3 平臺應用情況
通過幾年的運行和迭代,上汽大通的智能網聯平臺逐步接入了上汽大通、躍進、申沃、紅巖、上柴公司的EV69、EV79、FCV80、EV31、SV51、C500、D20等幾十款車型或發動機,共約30多萬臺終端,日均實時在線車輛約10 000臺以上。歷史總數據約為300太字節,并以每月20太字節的速度增加。圖3為智能網聯平臺的應用情況圖。
在離線平臺方面,目前車聯網集群的任務資源共分為3個隊列。其中,上汽商用車隊列運行大通所有的ETL和報表任務;Azkaban任務調度系統的隊列負責運行數據管理平臺(DMP)相關業務;Dev_user隊列為業務和數據分析人員提供臨時查詢服務。
實時平臺主要服務于需要實時數據接入的業務。其中,斑馬系統的實時數據增長量最大,每天的數據接入量接近14吉字節;蜘蛛智聯系統的實時數據接入量每天在4吉字節左右;車聯網系統的實時接入業務也有顯著增長。
4 結論
基于自主開發的智能網聯平臺,技術人員統一了企業的車聯網終端數據格式。根據OTA協議,技術人員定義了智聯數據報文交互格式,通過Kafka數據收發系統對接入層和應用層進行了切割,可以讓研發團隊實現分頭獨立開發,同時也保證了系統數據流的統一性和延續性。在數據平臺架構層面,技術人員設計了離線數據平臺和實時數據平臺相結合的框架,通過關系型數據庫、非關系型數據庫,以及Hadoop大數據等多種數據平臺,整合技術解決方案,既滿足了不同業務應用對于數據的需求,又兼顧了系統的擴展性和兼容性,并考慮到了項目實施的成本因素。本文中提到的多個模塊已獲得了軟件著作權和發明專利。
[1]彭昭.智聯網 未來的未來[M].北京:電子工業出版社,1984.
[2]維克托 邁爾 舍恩 伯格,肯尼思 庫克耶.大數據時代[M].周濤,譯.杭州:浙江人民出版社.
[3]全面梳理SQL和NoSQL數據庫的技術差別[OL]. http://blog.csdn.net/alexdamiao/article/details/51457399.
[4]郝萌萌.互聯網內容分析系統的設計與實現[D].北京交通大學,2018.
[5]臧其事,謝立帆,李思宇.一種基于網絡旁路的應用系統通用監控與預警系統的設計和實現[J].網絡安全技術與應用,2018(012):122-123.