為什麼説 MongoDB 和 HBase 不適用於汽車行業的時序數據處理？

語言: CN / TW / HK
時間 2023-02-15 04:15:04
主題:

近年來，在能源和環保的壓力下，新能源汽車成為了未來汽車發展的新方向。為支持其快速發展，我國出台了一系列扶持政策，在《新能源汽車產業發展規劃（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 的核心創新點之一——“一個設備一張表”，以此保證每個採集點的數據在存儲介質上以塊為單位進行連續存儲，減少隨機讀的同時成數量級提升查詢速度，還可以通過無鎖、追加的方式寫入，提升寫入速度。

1.png

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

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

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

2.png

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

3.png

在表數據的搭建上，通常車企在採集數據時包含的通常都是“採集時間（時間戳）、車輛標誌（字符串）、經度（雙精度浮點）、維度（雙精度浮點）、海拔（浮點）、方向（浮點）、速度（浮點）、車牌號（字符串）、車輛型號（字符串）、車輛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上查看相關源代碼。 飛書20220210-132320.jpg

「」