一、項目背景

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

為了對設備進行更高效的管理，需要將設備采集數(shù)據(jù)上報至云端進行存儲，并提供實時數(shù)據(jù)查詢、歷史數(shù)據(jù)查詢等業(yè)務服務，用來做設備監(jiān)控和分析。

現(xiàn)狀

在業(yè)務誕生之初，我們用作數(shù)據(jù)存儲的選型是 MySQL + HBase，MySQL 存儲設備最新實時數(shù)據(jù)，HBase 存儲設備原始數(shù)據(jù)，大體架構(gòu)如下：

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

• HBase 在大數(shù)據(jù)領域應用較為廣泛，適合存儲海量數(shù)據(jù)，寫入性能好
• 支持動態(tài)添加列，非常方便兼容數(shù)據(jù)模型變化
• 底層是鍵值對存儲，數(shù)據(jù)可以比較稀疏，空數(shù)據(jù)不占存儲空間
• 團隊 HBase 技術使用相對較為成熟

痛點

初期因為設備不多，數(shù)據(jù)量不大，加上查詢場景單一，HBase 表現(xiàn)不錯，可以滿足業(yè)務需求。

隨著換電站和超充站等設備在全國的快速布局，設備數(shù)量持續(xù)增長，積累的數(shù)據(jù)量越來越多，長時間跨度數(shù)據(jù)查詢效率出現(xiàn)瓶頸，再加上查詢場景不斷豐富，HBase 已經(jīng)無法滿足當前業(yè)務需要。問題主要體現(xiàn)在以下幾點：

• HBase 只支持 Rowkey 索引，有很大的局限性，一些查詢場景依賴 Rowkey 設計合理，如果業(yè)務調(diào)整，無法兼容
• 可以引入二級索引解決，單獨維護查詢條件與 Rowkey 關系，查詢時先查到 Rowkey 再查數(shù)據(jù)，不管是引入中間件還是自己實現(xiàn)，都會增加整體架構(gòu)和實現(xiàn)復雜度
• HBase 單表隨著數(shù)據(jù)量增大，會觸發(fā)自動分區(qū)，導致寫入性能下降，需要通過建表時指定預分區(qū)來解決，調(diào)整起來很麻煩，需要重新建表生效
• HBase 不適用于大范圍掃描查詢，性能比較差
• HBase 不支持聚合查詢，大跨度時間范圍查詢數(shù)據(jù)量太大，圖表無法渲染
• HBase 部署需要依賴 ZooKeeper，運維成本高

二、落地方案

技術選型

為了解決這些痛點，我們將目光投向時下流行并且更適合物聯(lián)網(wǎng)領域的時序數(shù)據(jù)庫（Time-Series Database）。經(jīng)過調(diào)研，對比多個技術選型，最終決定使用 TDengine 代替 HBase 作為設備原始數(shù)據(jù)存儲。

在選型時我們考慮過 OpenTSDB，也是一款優(yōu)秀的時序數(shù)據(jù)庫產(chǎn)品，在部門其他業(yè)務中已經(jīng)有過比較成熟的使用，能解決一部分遇到的痛點：

• OpenTSDB 在 HBase 基礎上做了優(yōu)化，包括存儲元數(shù)據(jù)映射和壓縮機制，使數(shù)據(jù)存儲占用空間大大降低
• OpenTSDB 提供數(shù)據(jù)聚合查詢功能，可以支持更大時間跨度查詢的業(yè)務需求

但是 OpenTSDB 底層還是基于 HBase 的，HBase 存在的一些問題，OpenTSDB 依然會有，并且架構(gòu)并沒有變簡單，沒有擺脫 HBase 的依賴。

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

• 引入超級表概念對應設備類型，對每個設備創(chuàng)建子表繼承超級表，通常相同設備類型的設備數(shù)據(jù)模型一定相同，通過超級表管理 schema 直接對子表生效很方便，同時對每個設備建表可以很好地做數(shù)據(jù)隔離，同時避免互相影響
• 采用多級存儲，不同時間的數(shù)據(jù)使用不同存儲介質(zhì)，新數(shù)據(jù)經(jīng)常訪問存 SSD 保證效率，老數(shù)據(jù)存 HDD，節(jié)約成本
• 不依賴任何第三方軟件，集群安裝部署方便，支持靈活擴容
• 提供多種聚合函數(shù)，支持對數(shù)據(jù)的聚合查詢

前期測試

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

測試準備

• 采用單節(jié)點部署
• 8 核 32GB，500GB 存儲
• 采用默認配置
• 采用 RESTful API 方式寫入數(shù)據(jù)

測試場景

模擬 10,000 個設備上報數(shù)據(jù)，消息并發(fā)約 4k 左右。

• 定義超級表如下

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

• 最初采用每條上報消息進行一次數(shù)據(jù)寫入，性能無法滿足，而將單條消息寫入改為批量寫入，積累一批數(shù)據(jù)（100 條）后，再批量寫入一次，性能可以支撐

測試結(jié)論

采用批量寫入數(shù)據(jù)方式，調(diào)整合適的單批次數(shù)據(jù)量大小，使用單機部署（8 核 32 GB，500 GB 存儲）默認配置的 TDengine 服務，RESTful API寫入方式，在 4k 并發(fā)流量下寫入沒有問題，同時消費積壓數(shù)據(jù)時峰值達到 7 k/s，因為單條消息包含信息量太大，實際處理中會拆分為 30 條寫入 TDengine，所以實際寫入 QPS 為 210 k/s，比滿足同樣數(shù)據(jù)流量的 HBase 集群規(guī)模要小不少，可以節(jié)省成本，再加上 TDengine 本身部署不依賴其他三方軟件，也可以同時節(jié)省運維成本。

遷移方案

經(jīng)過測試，我們決定先對部分設備應用 TDengine 時序數(shù)據(jù)庫替代 HBase，同時需要考慮如何在不影響業(yè)務功能的情況下平滑過渡并完成遷移。

數(shù)據(jù)雙寫

因為目前沒有現(xiàn)成的工具可以直接把數(shù)據(jù)從 HBase 遷移到 TDengine，如果自己開發(fā)一個工具做這件事情，開發(fā)成本太高，而且可能是一次性的。

考慮到不想浪費開發(fā)資源，同時我們需要一個過渡期，期間如果 TDengine 出現(xiàn)問題可以迅速切換回 HBase，不影響業(yè)務，所以不能馬上把 HBase 廢掉，所以我們決定先實現(xiàn) TDengine 寫入，并且暫時保持 HBase 和 TDengine 兩個數(shù)據(jù)庫雙寫。

寫入方式

根據(jù)前期測試結(jié)果，我們選擇直接采用批量方式寫入數(shù)據(jù)：

• 并行處理不同設備類型數(shù)據(jù)
• 消費設備上報數(shù)據(jù)放入隊列
• 當隊列長度達到n或超過等待時間t，從隊列中取出數(shù)據(jù)批量寫入

經(jīng)過壓測，在n = 1,000，t = 500 ms 情況下，單次寫入耗時基本在 10 ms 以內(nèi)，意味著我們可以支持單個設備類型每秒上萬的并發(fā)寫入，并且還有進一步的優(yōu)化提升空間。

查詢切換

為了保證遷移過程順利，并且遷移前后不會出現(xiàn)數(shù)據(jù)不完整的情況，我們做了一個查詢開關：

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

遷移后架構(gòu)變?yōu)槿缦滤荆?/p>

三、實際效果

目前我們已將線上部分設備的數(shù)據(jù)切換到 TDengine Database 集群，上線后集群表現(xiàn)穩(wěn)定。

對比之前使用 HBase：

• 查詢速度提升明顯，從使用 HBase 查詢單設備 24 小時數(shù)據(jù)的秒級返回，到使用 TDengine 查詢查詢相同數(shù)據(jù)的毫秒級返回
• 每天增量數(shù)據(jù)占用的存儲空間相當于原來使用 HBase 時的 50%
• 集群計算資源成本相比使用 HBase 節(jié)省超過 60%

四、總結(jié)

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

關于作者

李鵬飛，蔚來汽車能源數(shù)字化產(chǎn)品開發(fā)部高級工程師，目前負責能源物聯(lián)平臺開發(fā)。