為什麼說 MongoDB 和 HBase 不適用於汽車行業的時序資料處理？

近年來，在能源和環保的壓力下，新能源汽車成為了未來汽車發展的新方向。為支援其快速發展，我國出臺了一系列扶持政策，在《新能源汽車產業發展規劃（2021-2035年）》中就有提出，到 2025 年新能源汽車新車銷售量要達到汽車新車銷售總量的 20% 左右，其市場廣闊程度可見一斑。現在火熱的自動駕駛技術，也是新能源汽車的一大優勢，而自動駕駛又需要各類感測器產生的源源不斷的時序資料來輔助判斷，所以與時序資料相關的採集、處理和儲存等各項需求也顯著增長。

一直以來，對於新能源車企來說，在時序資料的儲存上，選擇的大多都是 MongoDB 或 Apache HBase，這兩大資料庫技術相對更加成熟，在業務規模尚未擴張之前，因為裝置不多、資料量不大，加上查詢場景單一，尚且可以滿足業務需求。隨著業務的加速擴張，寫入速度太慢、支撐成本過高等問題也逐漸顯現。

以零跑汽車為例，此前他們將時序資料分別儲存在 MongoDB 和 HBase 中，前者會將資料全部儲存在記憶體中，過高的儲存成本導致只能儲存一段時間內的資料，且儲存的資料格式需要經過業務組織處理，不僅業務變更不靈活，可以做的業務也非常有限。後者用來儲存部分實時訊號，需要整套 HDFS 做支撐，使用、運維和人力等成本都很高，需要大資料相關的人才才能保證平穩執行。而且公司的 HBase 環境是私有云環境，而云平臺在公有云環境，跨專網業務時常會被網路問題影響。

在合適的時候選擇合適的資料庫是支援業務發展的關鍵，但資料庫的更換也並不是頭腦一熱就能拍板決定的，還需要進行資料庫產品的縝密觀察和調研，才能選中真正適合自身業務發展的“天選資料庫”。那對於車企來說，到底什麼樣的資料庫更加適合呢？我們不妨從它所產生的資料本身去做一下分析。

從時序資料本身的特點看車企適用的資料庫型別

當下車聯網已經成為車企佈局未來的一個重要場景，如工業網際網路一樣其產生的資料分類為時序資料，而時序資料具有如下特點：

• 所有采集的資料都是時序的
• 資料都是結構化的
• 一個採集點的資料來源是唯一的
• 資料很少有更新或刪除操作
• 資料一般是按到期日期來刪除的
• 資料以寫操作為主，讀操作為輔
• 資料流量平穩，可以較為準確的計算
• 資料都有統計、聚合等實時計算操作
• 資料一定是指定時間段和指定區域查詢的

而關係型資料庫主要對應的資料特點卻與之差別甚廣：資料寫入上大多數操作都是 DML 操作，插入、更新、刪除等；資料讀取邏輯一般都比較複雜；在資料儲存上，很少有壓縮需求，一般也不設定資料生命週期管理。很顯然，關係型資料庫是不適合用於處理時序資料的。

企業在選擇資料庫檔案系統等產品時，最終目的都是為了以最佳價效比來滿足資料寫入、資料讀取和資料儲存這三個核心需求。而時序資料庫（Time-Series Database）正是從以上特點出發、以時序資料的三個核心需求為最終結果進行設計和研發的，因此在資料處理上會更加具有針對性。

近年來，隨著物聯網的快速發展、業務規模和資料量的快速爆發，國內外越來越多的科技企業發現了用傳統關係型資料庫來儲存時序資料的問題，針對時序資料庫的選型調研也由此開始。

目前市面上的時序資料庫種類繁多，老將如 InfluxDB、Prometheus，後起之秀如 OpenTSDB、TDengine 等，在對自身業務進行時序資料庫選型時，除了效能各方面的考量外，大部分企業還會考量其是否具備水平擴充套件能力。

在效能層面，TDengine 曾做過幾家時序資料庫的對比——TDengine 與 InfluxDB、OpenTSDB、Cassandra、MySQL、ClickHouse 等資料庫的對比測試報告，聚焦工業網際網路的和利時也從使用者的角度做過一些對比——從四種時序資料庫選型中脫穎而出，TDengine 在工控領域邊緣側的應用，大家可做參考。而在水平擴充套件能力方面， TDengine 早在 2020 年就實現了單機和叢集版的雙開源，同時憑藉著效能上的硬核表現，深受著車聯網、物聯網、工業網際網路等企業客戶的青睞。

下面我們以 TDengine Database 為例，看看時序資料庫針對車聯網場景下龐大的時序資料的寫入、查詢、儲存是如何實現的。

基於TDengine，你可以怎麼設計架構和表

作為時序資料庫引擎，TDengine Database 不需要基於 Hadoop 生態搭建，也不需要拼裝 Kafka、Redis、HBase 等諸多元件，它將資料處理中的快取、訊息佇列、資料庫、流式計算等功能都統一在了一起，這樣輕量級的設計不僅讓它的安裝包很小、對叢集資源消耗很少，同時也在一定程度上降低了研發、運維成本，因為需要整合的開源元件少，因而系統可以更加健壯，也更容易保證資料的一致性。可以試驗一下，如果你要搭建一套車隊管理系統，你只需要寫一個 Java 應用，再加上 TDengine 完全能夠實現。

從時序資料的特點出發，TDengine 沒有選擇流行的 KV 儲存，而是使用了結構化儲存。同時，基於物聯網場景裡，每個資料採集點的資料來源是唯一的、資料是時序的，且使用者關心的往往是一個時間段的資料而非某個特殊時間點等特點出發，TDengine Database 要求對每個採集裝置單獨建表。也就是如果有 1000 萬個裝置，就需要建 1000 萬張表。

這就是 TDengine Database 的核心創新點之一——“一個裝置一張表”，以此保證每個採集點的資料在儲存介質上以塊為單位進行連續儲存，減少隨機讀的同時成數量級提升查詢速度，還可以通過無鎖、追加的方式寫入，提升寫入速度。

篇幅有限，關於 TDengine 的更多設計特點，大家如果有興趣可以移步官網查閱瞭解更多，在這裡就不多做贅述了。

下面我們來看一下兩種資料庫下的架構圖，從中我們也可以得出一個結論，選擇 TDengine Database 明顯會更加輕量。

• 基於 HBase 的解決方案，架構圖如下——

• 基於 TDengine 的解決方案，架構圖如下——

在表資料的搭建上，通常車企在採集資料時包含的通常都是“採集時間（時間戳）、車輛標誌（字串）、經度（雙精度浮點）、維度（雙精度浮點）、海拔（浮點）、方向（浮點）、速度（浮點）、車牌號（字串）、車輛型號（字串）、車輛vid（字串）”這 10 類欄位。

不同於其他時序資料庫，TDengine 會為每輛車單獨建立一張資料表，資料欄位為採集時間、車輛標誌、經度、緯度、海拔、方向、速度等與時間序列相關的採集資料；標籤欄位為車牌號、車輛型號等車輛本身固定的描述資訊。這裡面有一個小技巧，浮點資料壓縮比相對整型資料壓縮比很差，經度緯度通常精確到小數點後 7 位，因此我們可以將經度緯度增大 1E7 倍轉為長整型儲存，將海拔、方向、速度增大 1E2 倍轉為整型儲存。

超級表建立語句：create table vehicle(ts timestamp, longitude bigint, latitude bigint, altitude int, direction int, velocity int) tags(card int, model binary(10));

此前有研發人員使用 C 語言編寫了一個車輛模擬資料生成程式，對 TDengine 進行測試，以 10 萬張資料表，每張寫入 1 個月的資料（資料間隔 1 分鐘，計 44000 條資料）為測試資料。編譯之後，將測試程式和資料庫在同一臺 2 核 8G 的桌上型電腦上執行，寫入時間共計為 3946 秒，相當於 4400000000條/3946 秒=111.5 萬條/秒，折算成點數為 111.5*5=557 萬點/秒。

在這裡要注意的是，該程式是單執行緒執行的，如將其修改成多執行緒，速度還會有更大提升，但是僅就目前的效能來看，對於車聯網的場景也已經足夠。

從蔚來、零跑、理想三家車企，看時序資料庫的應用效果

聚焦在實際業務中，時序資料庫之於車聯網的匹配度之高，我們從 TDengine 的三個車企客戶案例中也可見一斑。

對於蔚來汽車來說，隨著業務的發展，截止 2021 年底其已經在全國各地佈局了換電站 777 座，超充樁 3404 根，目充樁 3461 根，為使用者安裝家充樁 96,000+ 根。為了對裝置進行更高效的管理，他們需要將裝置採集資料上報至雲端進行儲存，並提供實時資料查詢、歷史資料查詢等業務服務，實現裝置監控和分析。

但一直作為蔚來汽車資料儲存的 MySQL + HBase 模型卻越來越難以為繼，隨著換電站和超充站等裝置在全國的快速佈局，裝置數量持續增長，積累的資料量越來越多，長時間跨度資料查詢效率出現瓶頸，再加上查詢場景不斷豐富，HBase 已經無法滿足當前業務需要。他們決定從 OpenTSDB 和 TDengine 中進行選擇，在進行各種對比測試後決定將 HBase 替換為 TDengine。

從最終的改造結果上來看可以說是非常成功了。在查詢速度上，從使用 HBase 查詢單裝置 24 小時資料的秒級返回升級到使用 TDengine 查詢相同資料的毫秒級返回；在儲存空間上，每天增量資料佔用的儲存空間相當於原來使用 HBase 時的 50%；在成本對比上，遷移後集群計算資源成本相比使用 HBase 節省超過 60%。

無獨有偶，零跑汽車面臨著和蔚來汽車一樣的困境，他們此前在資料儲存上的選擇是 MongoDB 和 HBase，隨著業務規模的擴大，資料庫效能越來越難以滿足資料處理需求，成本也隨之提升。從降本增效的角度考慮，零跑決定在 C11 新車型上試用 TDengine。

零跑科技在做資料庫選型調研時只有兩點訴求：效能強、成本低。而最終的事實證明，TDengine 確實沒有辜負他們的期待。在查詢上，TDengine 的列式儲存可以直接以 SQL 計算，不用再像 MongoDB 一樣，在查詢前還需要根據業務加工出需求資料。同時 TDengine 的高壓縮演算法也助力零跑科技提升 10-20 倍的壓縮效能，既節省了儲存空間也解決了儲存成本高的問題。

和前兩面兩家公司不同，理想汽車是從 TiDB 遷移到 TDengine 的。整體來看，TiDB 更適合 TP 或者輕 AP 場景。從理想汽車的角度而言，其寫入價效比較低，一次性大批量寫入場景也不太適合，且對業務有入侵性，底層庫表要按照月份來建表，還要針對每個採集點打上標籤。

在遷移到 TDengine 之後，理想汽車的機器使用成本顯著降低，聚合類查詢速度顯著提成，引入了 firstEP 機制的彈性擴縮容在一定程度上保障了效能的強勁，同時 TTL 和標籤機制也實現了對業務的透明。

就如零跑汽車的專案對接人所感嘆的一樣，做汽車這樣一種產品，資料量之大難以想象，如果沒有一款能夠實現高效儲存的資料庫，伺服器成本會非常的高。

但現在他們都找到了破解困境的有效方法。從理論到實踐，時序資料庫無疑都是車聯網的“天選資料庫”。

---

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