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