> 小 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 張表。
![](http://img.blog.itpub.net/blog/2022/04/08/6d42fdbbf3887c48.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/04/08/80ebf8b65ca5f95b.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/04/08/02159d32faf86280.png?x-oss-process=style/bb)

超級表表結構如下：
![](http://img.blog.itpub.net/blog/2022/04/08/1d4bccb1103c79cf.png?x-oss-process=style/bb)

由於我們的 json 較大，所以選擇使用 protobuf 進行壓縮後再寫入 TDengine，這樣只需要 1500 位元組的長度就可以容納該類 json，取出進行反序列化後以供使用。
![](http://img.blog.itpub.net/blog/2022/04/08/e09d6721926c62b2.png?x-oss-process=style/bb)

當前最大的一張超級表已經存有 300 多億條資料，每行 2362 位元組。粗略估算，專案執行至今，總資料量大概有 68T 左右，但實際的磁碟佔用量只有 1.4T，以前 20 天就能寫滿 15T 的磁碟，但現在基本已經不再需要考慮磁碟的問題了。資源使用率相比以前節省了近百倍。
![](http://img.blog.itpub.net/blog/2022/04/08/a4ac3438d2b2be54.png?x-oss-process=style/bb)

此外，困擾我們許久的資料實時查詢問題也有望得到解決，TDengine 的 last 函式可以實現毫秒級返回裝置最新狀態。由於我們當前使用的版本還是比較老舊的 2.0.18，這一版還沒有針對 last 函式的快取，TDengine 的工作人員表示後續會有針對這個函式專門的最佳化，等日後版本升級後再做體驗。 最常用的查詢車輛實時位置的 SQL 是這樣的，全部都是毫秒級別返回結果：
![](http://img.blog.itpub.net/blog/2022/04/08/24224e4fe9320f71.png?x-oss-process=style/bb)

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

------------

想了解更多 TDengine 的具體細節，歡迎大家在[GitHub](https://github.com/taosdata/TDengine "GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/03/31/0fd6ee826ee55f96.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?utm_source=itpub&utm_medium=tdengine&utm_campaign=usecase&utm_term=20220408)

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

相關文章