TDengine 在蔚來能源系統的落地實踐

一、 專案背景

為了給使用者提供更好的補能體驗，蔚來能源在加電基礎設施上進行了大量的投入，截止 2021 年底，已經在全國各地佈局了換電站 777 座，超充樁 3,404 根，目充樁 3,461 根，為使用者安裝家充樁 96,000+ 根。

為了對裝置進行更高效的管理，需要將裝置採集資料上報至雲端進行儲存，並提供實時資料查詢、歷史資料查詢等業務服務，用來做裝置監控和分析。

現狀

在業務誕生之初，我們用作資料儲存的選型是 MySQL + HBase，MySQL 儲存裝置最新實時資料，HBase儲存裝置原始資料，大體架構如下：

之所以選擇 HBase，有以下幾個理由：

• HBase 在大資料領域應用較為廣泛，適合儲存海量資料，寫入效能好
• 支援動態新增列，非常方便相容資料模型變化
• 底層是鍵值對儲存，資料可以比較稀疏，空資料不佔儲存空間
• 團隊 HBase 技術使用相對較為成熟

痛點

初期因為裝置不多，資料量不大，加上查詢場景單一，HBase 表現不錯，可以滿足業務需求。

隨著換電站和超充站等裝置在全國的快速佈局，裝置數量持續增長，積累的資料量越來越多，長時間跨度資料查詢效率出現瓶頸，再加上查詢場景不斷豐富，HBase 已經無法滿足當前業務需要。問題主要體現在以下幾點：

• HBase 只支援 Rowkey 索引，有很大的侷限性，一些查詢場景依賴 Rowkey 設計合理，如果業務調整，無法相容
• 可以引入二級索引解決，單獨維護查詢條件與 Rowkey 關係，查詢時先查到 Rowkey 再查資料，不管是引入中介軟體還是自己實現，都會增加整體架構和實現複雜度
• HBase 單表隨著資料量增大，會觸發自動分割槽，導致寫入效能下降，需要透過建表時指定預分割槽來解決，調整起來很麻煩，需要重新建表生效
• HBase 不適用於大範圍掃描查詢，效能比較差
• HBase 不支援聚合查詢，大跨度時間範圍查詢資料量太大，圖表無法渲染
• HBase 部署需要依賴 ZooKeeper，運維成本高

二、 落地方案

技術選型

為了解決這些痛點，我們將目光投向時下流行並且更適合物聯網領域的時序資料庫。經過調研，對比多個技術選型，最終決定使用 TDengine 代替 HBase 作為裝置原始資料儲存。

在選型時我們考慮過 OpenTSDB，也是一款優秀的時序資料庫產品，在部門其他業務中已經有過比較成熟的使用，能解決一部分遇到的痛點：

• OpenTSDB 在 HBase 基礎上做了最佳化，包括儲存後設資料對映和壓縮機制，使資料儲存佔用空間大大降低
• OpenTSDB 提供資料聚合查詢功能，可以支援更大時間跨度查詢的業務需求

但是 OpenTSDB 底層還是基於 HBase 的，HBase 存在的一些問題，OpenTSDB 依然會有，並且架構並沒有變簡單，沒有擺脫 HBase 的依賴。

經過對比，我們決定嘗試一下 TDengine，其官方給出的效能指標，單節點部署情況下可以達到 14810 k/s 讀取，和 880k/s 寫入，同時 TDengine 具備的一些特點能很好地解決我們遇到的痛點：

• 引入 概念對應裝置型別，對每個裝置建立子表繼承超級表，通常相同裝置型別的裝置資料模型一定相同，透過超級表管理 schema 直接對子表生效很方便，同時對每個裝置建表可以很好地做資料隔離，同時避免互相影響
• 採用多級儲存，不同時間的資料使用不同儲存介質，新資料經常訪問存 SSD 保證效率，老資料存 HDD，節約成本
• 不依賴任何第三方軟體， 安裝部署方便，支援靈活擴容
• 提供多種聚合函式，支援對資料的

前期測試

我們使用 TDengine 做了一些簡單的效能測試，評估使用 TDengine 是否能滿足我們的業務需求。

測試準備

• 採用單節點部署
• 8 核 32GB，500GB 儲存
• 採用預設配置
• 採用   方式寫入資料

測試場景

模擬 10,000 個裝置上報資料，訊息併發約 4k 左右。

• 定義超級表如下

1.SQL -- 程式碼示例，非真實程式碼 
2.CREATE STABLE device_data_point_0 (ts timestamp, d1 nchar(64), d2 nchar(64), ...) TAGS (t1 binary(64));

• 最初採用每條上報訊息進行一次資料寫入，效能無法滿足，而將單條訊息寫入改為批次寫入，積累一批資料（100 條）後，再批次寫入一次，效能可以支撐

測試結論

採用批次寫入資料方式，調整合適的單批次資料量大小，使用單機部署（8 核 32 GB，500 GB 儲存）預設配置的 TDengine 服務，RESTful API寫入方式，在 4k 併發流量下寫入沒有問題，同時消費積壓資料時峰值達到 7 k/s，因為單條訊息包含資訊量太大，實際處理中會拆分為 30 條寫入 TDengine，所以實際寫入 QPS 為 210 k/s，比滿足同樣資料流量的 HBase 叢集規模要小不少，可以節省成本，再加上 TDengine 本身部署不依賴其他三方軟體，也可以同時節省運維成本。

遷移方案

經過測試，我們決定先對部分裝置應用 TDengine 時序資料庫替代 HBase，同時需要考慮如何在不影響業務功能的情況下平滑過渡並完成遷移。

資料雙寫

因為目前沒有現成的工具可以直接把資料從 HBase 遷移到 TDengine，如果自己開發一個工具做這件事情，開發成本太高，而且可能是一次性的。

考慮到不想浪費開發資源，同時我們需要一個過渡期，期間如果 TDengine 出現問題可以迅速切換回 HBase，不影響業務，所以不能馬上把 HBase 廢掉，所以我們決定先實現 TDengine 寫入，並且暫時保持 HBase 和 TDengine 兩個資料庫雙寫。

寫入方式

根據前期測試結果，我們選擇直接採用批次方式寫入資料：

• 並行處理不同裝置型別資料
• 消費裝置上報資料放入佇列
• 當佇列長度達到n或超過等待時間t，從佇列中取出資料批次寫入

經過壓測，在n = 1,000，t = 500 ms 情況下，單次寫入耗時基本在 10 ms 以內，意味著我們可以支援單個裝置型別每秒上萬的併發寫入，並且還有進一步的最佳化提升空間。

查詢切換

為了保證遷移過程順利，並且遷移前後不會出現資料不完整的情況，我們做了一個查詢開關：

• 配置 TDengine 功能上線時間
• 判斷查詢請求時間範圍與配置時間大小，決定查 HBase 還是 TDengine
• 過渡期結束後，停止 HBase 服務

遷移後架構變為如下所示：

三、實際效果

目前我們已將線上部分裝置的資料切換到 TDengine 叢集，上線後叢集表現穩定。

對比之前使用 HBase：

• 查詢速度提升明顯，從使用 HBase 查詢單裝置 24 小時資料的秒級返回，到使用 TDengine 查詢查詢相同資料的毫秒級返回
• 每天增量資料佔用的儲存空間相當於原來使用 HBase 時的 50%
• 叢集計算資源成本相比使用 HBase 節省超過 60%

四、 總結

• 總體上說，TDengine 讀寫效能表現很好，在滿足我們業務需求的同時，極大地節省了計算資源和運維成本，目前嘗試 TDengine 的業務場景還比較簡單，只是單純的資料寫入和時間範圍查詢，後續可以結合 TDengine 更多進階功能探索其他可以落地的業務場景
• 使用上還有一些問題待解決，比如 schema 調整在應用發版過程中對資料寫入的影響，產生預期外的寫入異常，以及異常定義不明確，無法快速定位問題，尤其是跟 schema 相關資料寫入問題
• 監控方面目前支援的監控指標較少，這個問題據說會在後續版本豐富
• 資料遷移方面，目前官方支援工具還比較少，不能比較方便的把資料從其他儲存引擎遷移到 TDengine，需要進行額外開發

關於作者

李鵬飛，蔚來汽車能源數字化產品開發部高階工程師，目前負責能源物聯平臺開發。