1. 程式人生 > 其它 >解決兩大難題,TDengine 助力億咖通打造自動駕駛技術典範

解決兩大難題,TDengine 助力億咖通打造自動駕駛技術典範

小 T 導讀:在安全解決方案 SuperCloud 中,億咖通面臨著磁碟佔用量大、車輛最新狀態實時查詢難以實現兩個核心問題。最終,他們選擇了讓 TDengine 承擔資料中臺的重要角色,負責車輛實時資料的寫入、儲存以及實時查詢。本文講述了研發團隊在前期使用 Apache HBase 時遇到的具體難點、為什麼沒有堅持選擇 OpenTSDB,以及選擇 TDengine 的過程和成效。

 

企業簡介

億咖通科技是一家汽車智慧化科技公司,在武漢、杭州、上海、蘇州、馬來西亞吉隆坡、英國倫敦等國內外多地設立有分支機構和研發中心,致力於持續打造行業領先的智慧網聯生態開放平臺,全面為車企賦能,創造更智慧、更安全的出行體驗。

 

專案介紹

為實現高水準的自動駕駛能力,億咖通科技(ECARX)打造了一整套安全解決方案 SuperCloud,該方案旨在利用人工智慧技術以及攝像頭、雷達、聲納等多種感測器技術來保證駕乘者的安全。自動駕駛的核心資料就是裝置的影子資料和狀態資料,對裝置進行精準的資料控制和採集,再結合高精地圖的資料,是完成自動駕駛的兩個重要環節。值得一提的是,億咖通也是目前國內為數不多的擁有高精地圖資質的企業。

在 SuperCloud 專案當中,TDengine 承擔著資料中臺的重要角色,負責車輛實時資料的寫入、儲存以及實時查詢。

 

選型經過

 

在此之前,我們使用的儲存架構是 Kafka + Flink + HBase,但隨著業務的發展,逐漸發現 HBase 的 Key-Value 儲存模型並不適合我們的場景,究其原因,是因為落地到資料庫的都是結構化的資料,Key-Value 儲存模型會導致磁碟佔用量特別大,並且效能上也無法實現車輛最新狀態的實時查詢,這也是亟待解決的兩個核心問題。

經過調研,我們發現時序資料庫才是正確的選擇方向,而且核心資料也符合時序資料的種種特點,因此,我們決定在 InfluxDB、TDengine 和 OpenTSDB 之間進行產品選型。

事實上,一開始我們選擇的是 OpenTSDB,因為它基於 HBase,所以我們很方便上手。但成也蕭何敗也蕭何,也正因為要依賴 HBase,OpenTSDB 並沒有解決 HBase 遺留的效能、壓縮率等問題。而 InfluxDB 由於單機效能並不夠卓越,而且叢集功能沒有開源,所以也沒有被採納。最終經過各種維度的對比後,我們毅然選擇了國產、開源、支援 SQL 的時序資料庫 TDengine。

TDengine 非常符合我們現在的業務場景,尤其是超級表的概念,甚至可以說是為我們量身定做的。我們為每輛車都分配了一個子表,用以接收 IHU 裝置產生的資料。(注:IHU 是億咖通投入研發的第一代整車計算平臺產品,於 2017 年第二季度投放市場使用,是一款採用車載專用處理器、基於車身匯流排系統和第三方應用服務打造而成的多媒體娛樂系統,能實現包括地圖導航、多媒體娛樂、車輛資訊等一系列資訊娛樂功能及車聯網服務。)

優化後的新架構為:Kafka + Flink + TDengine。Flink 上游的資料可分為 2 類,一類是用 json 儲存的結構化資料,還有一類是如圖片、視訊一類的非結構化資料。上游如果是結構化的 json 資料,則通過如下鏈路寫入 TDengine:Kafka—>Flink—>TDengine,如果是非結構化的資料,則會直接儲存到 S3 上,然後把這些視訊圖片的檔案路徑通過如下鏈路寫入 TDengine:S3—->Kafka —-> Flink—>TDengine。

 

搭建與效果

 

我們以單副本模式落地了一個三節點的叢集,機器配置為 8C + 16G + 500G 機械硬碟,備份用其他方式完成。當前環境下有 3 張超級表、276571 張表。

   

超級表表結構如下:

由於我們的 json 較大,所以選擇使用 protobuf 進行壓縮後再寫入 TDengine,這樣只需要 1500 位元組的長度就可以容納該類 json,取出進行反序列化後以供使用。

當前最大的一張超級表已經存有 300 多億條資料,每行 2362 位元組。粗略估算,專案執行至今,總資料量大概有 68T 左右,但實際的磁碟佔用量只有 1.4T,以前 20 天就能寫滿 15T 的磁碟,但現在基本已經不再需要考慮磁碟的問題了。資源使用率相比以前節省了近百倍。

此外,困擾我們許久的資料實時查詢問題也有望得到解決,TDengine 的 last 函式可以實現毫秒級返回裝置最新狀態。由於我們當前使用的版本還是比較老舊的 2.0.18,這一版還沒有針對 last 函式的快取,TDengine 的工作人員表示後續會有針對這個函式專門的優化,等日後版本升級後再做體驗。 最常用的查詢車輛實時位置的 SQL 是這樣的,全部都是毫秒級別返回結果:

 

寫在最後

 

總體而言,TDengine 的獨特設計幫助我們解決了傳統架構磁碟儲存佔用過高,以及效能上不能支援車輛狀態實時查詢這兩大痛點,在實現降本增效方面名副其實。不止如此,我們後續要實現的裝置統計需求也在應用 TDengine 之後得到了解決。在 TDengine 的官方社群中,所提出的問題也都可以得到支援人員的快速反饋,事無鉅細,這幫我們極大降低了專案落地的難度。 TDengine 的應用,不僅完全解決了我們當前業務上存在的痛點,也匹配上了後續業務發展的需求。隨著業務的快速發展,我們希望和濤思資料後續可以在更多維度上通力合作,共同打造自動駕駛的行業技術典範。

 

想了解更多 TDengine 的具體細節,歡迎大家在GitHub上檢視相關原始碼。