作者 ｜ 溫金雄、彭濤、周玉峰

小 T 導讀：為了解決廣大新能源汽車車主面臨的充電效率問題，協(xié)鑫能科打造了以換電為核心業(yè)務的移動能源品牌「協(xié)鑫電港」，需要對各種數(shù)據(jù)流進行科學管理、合理運用與智能調(diào)度，在數(shù)據(jù)庫的選擇上尤為重要。本文分享了他們對于數(shù)據(jù)庫架構(gòu)的搭建思考以及 TDengine 的應用心得。

企業(yè)簡介

協(xié)鑫能源科技股份有限公司（證券簡稱：協(xié)鑫能科 002015.SZ） 系協(xié)鑫（集團）控股有限公司旗下企業(yè)，主營業(yè)務為清潔能源運營、移動能源運營以及綜合能源服務。公司傾力打造從清潔能源生產(chǎn)、補能服務到儲能的便捷、經(jīng)濟、綠色的出行生態(tài)圈，為電動化出行提供一體化能源解決方案，致力于成為領先的移動數(shù)字能源科技運營商。

1、業(yè)務痛點

隨著新能源汽車的廣泛普及，補能的效率問題逐漸成為了廣大車主面臨的痛點難題。為了解決此難題，作為一家頭部的新能源公司，協(xié)鑫能科創(chuàng)新突破，切入能源服務領域，打造了以換電為核心業(yè)務的移動能源解決方案品牌「協(xié)鑫電港」。

由于這是一個在全新領域中打造的全新項目，想要獲得成功，需要對各種數(shù)據(jù)流進行科學管理、合理運用與智能調(diào)度，所以針對該場景，我們一開始便把量級最大的物聯(lián)網(wǎng)數(shù)據(jù)處理方案鎖定在了時序數(shù)據(jù)庫（Time Series Database）上，重點對比了 InfluxDB、OpenTSDB 以及 TDengine。

最終，TDengine 以其獨特而科學的設計和優(yōu)秀的測試表現(xiàn)成為我們選中的時序數(shù)據(jù)處理引擎，承擔了用戶車輛數(shù)據(jù)、電池設備數(shù)據(jù)以及換電港工作設備等的海量數(shù)據(jù)存儲分析任務，為我們解決了該項目上難度最大的一個環(huán)節(jié)。最終，我們決定使用 TDengine 2.4.0.10 版本，并在電信的天翼云上落地了該項目。

2、架構(gòu)與搭建

從流量削峰以及數(shù)據(jù)安全的角度出發(fā)，我們會先通過使用某 MQTT 消息服務器把這些不同種類的設備數(shù)據(jù)先統(tǒng)一轉(zhuǎn)發(fā)給到 Kafka。其中不同類型的數(shù)據(jù)，將會分別上傳到不同的 Kafka topic，最后再通過 Java 連接器把數(shù)據(jù)寫入 TDengine。具體架構(gòu)如下圖所示：

在整體架構(gòu)上，除了 TDengine，也有一些其它數(shù)據(jù)庫共同支持系統(tǒng)服務，其中 MySQL 負責存儲訂單、流水等需要精細查詢的關系型數(shù)據(jù)，但由于 MySQL 可以承受的數(shù)據(jù)量比較有限，為了做一些大表的連接查詢，因此我們也接入了 TiDB，負責分析報表類數(shù)據(jù)的存儲。

目前接入 TDengine 最主要的入庫數(shù)據(jù)是車輛傳感器（如：車輛里程、經(jīng)緯度等）以及換電站電池相關的傳感器（電池的各種指標）數(shù)據(jù)。當前共有 55 張超級表，子表數(shù)量達到 11 萬張。

我們當前在 TDengine、TiDB、MySQL 中存儲的數(shù)據(jù)量比例大概為 6:3:1，僅僅使用了三臺 4C+16G 的服務器，TDengine 便挑起了整個系統(tǒng)數(shù)據(jù)存儲的大頭，輕松支撐起了我們的服務。在數(shù)據(jù)庫的選擇上，我們一直認為不同數(shù)據(jù)庫之間術業(yè)有專攻，不得不承認，TDengine 在存儲引擎上的獨特設計，在降低成本方面的效果十分顯著。 

對于 TDengine，我們一開始使用的是單節(jié)點，在穩(wěn)定運營了幾個月后，于今年 3 月完成了動態(tài)擴容，發(fā)展到了 3 節(jié)點集群模式，把數(shù)據(jù)庫也升級到了三副本（從圖中可以看出來）。

TDengine 的動態(tài)擴展非常方便，只要確保一些必要的參數(shù)保持一致，就可以直接通過 “create dnode”把新的計算資源加進來。加入后，再通過 “alter database iot replica 3” 這個命令，即可直接在線令數(shù)據(jù)庫變?yōu)?nbsp;3 副本，從而實現(xiàn)數(shù)據(jù)的備份及高可用。 

3、效果分析

當前，我們在 TDengine 中一共存儲了數(shù)百億級別的數(shù)據(jù)量（由于表結(jié)構(gòu)各異，不方便統(tǒng)計，不在本篇文章中展示），存儲空間大概占用 600GB 左右（200GB*3），CPU 日常使用為 15% 左右，內(nèi)存使用在 20% 左右。

在查詢方面，在此列舉一些我們常用的 SQL，TDengine 的響應速度都很快，完全可以滿足我們的需求：

select max(pmk)-min(pmk) from aodong_109 where sid='P42100001' and sd=0 and ts>'2021-12-01 00:00:00'

select last(sv),last(st) from aodong_112 where bn='001PB0GM000002B3L0300067';

4、關于 TDengine 的一些思考

由于我們業(yè)務是 24*7 不間斷運轉(zhuǎn) ，所以沒有時間做版本升級。我們首先計劃抽出時間把 TDengine 版本升級到比較新的版本，再做一些碎片重組壓縮的工作來加強查詢效率。此外，我們還計劃使用 Flink 從 TDengine 中讀取數(shù)據(jù)做流式計算（看到了官方發(fā)布了 Flink 適配 TDengine 的文章）。

隨著業(yè)務快速增長，TDengine 集群存儲的數(shù)據(jù)量也會越來越大，而數(shù)據(jù)又需要長期保留，大數(shù)據(jù)量的運維對于 TDengine 來說將是一個巨大的挑戰(zhàn)。伴隨數(shù)據(jù)量級的增長，備份、遷移、庫、表的運維都會受到影響，也有可能遇到我們之前沒有經(jīng)歷過的問題，這就需要 TDengine 集群實現(xiàn)升級、擴展、拆分、維護等運維操作。未來我們希望能積累更多的經(jīng)驗分享給社區(qū)，讓更多的人了解 TDengine。

對于 TDengine 未來的發(fā)展，我們也有自己的期待：

• 希望能增加動態(tài)修改參數(shù)功能，減少停機維護次數(shù)。
• 實現(xiàn)類似慢 SQL 日志功能，降低高負載、調(diào)優(yōu)事后分析定位、回溯故障原因。
• 進一步權衡 udp 帶來的好處和導致的各種問題。我們經(jīng)常連接報錯 Ref is not there ，目前來看在客戶端添加 rpcForceTcp 1  應該是有效的。
• 增強報錯信息可讀性，很多報錯提示不夠明確，無法快速判斷出具體原因。

總而言之，希望 TDengine 后面越來越好，也希望我們的合作能更上一層樓。