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

小 T 導讀：為了(le)解決廣大新能(neng)源汽車車主面臨的(de)充(chong)電效(xiao)率問(wen)題，協(xie)鑫能(neng)科(ke)打造了(le)以換電為核心(xin)業務的(de)移動能(neng)源品(pin)牌「協(xie)鑫電港」，需要對(dui)(dui)各種數據(ju)(ju)流(liu)進行科(ke)學管(guan)理、合(he)理運用與智能(neng)調度，在(zai)數據(ju)(ju)庫的(de)選擇上尤為重要。本文(wen)分享(xiang)了(le)他們對(dui)(dui)于數據(ju)(ju)庫架構的(de)搭建思考(kao)以及(ji) TDengine 的(de)應(ying)用心(xin)得(de)。

企業簡介

協(xie)鑫(xin)能(neng)(neng)(neng)源(yuan)(yuan)科技股份(fen)有限公(gong)司（證券簡(jian)稱：協(xie)鑫(xin)能(neng)(neng)(neng)科 002015.SZ） 系協(xie)鑫(xin)（集團）控股有限公(gong)司旗下企業(ye)，主營(ying)(ying)業(ye)務為清潔能(neng)(neng)(neng)源(yuan)(yuan)運(yun)營(ying)(ying)、移動(dong)(dong)能(neng)(neng)(neng)源(yuan)(yuan)運(yun)營(ying)(ying)以(yi)及綜合(he)能(neng)(neng)(neng)源(yuan)(yuan)服務。公(gong)司傾力打造從清潔能(neng)(neng)(neng)源(yuan)(yuan)生(sheng)產、補能(neng)(neng)(neng)服務到儲(chu)能(neng)(neng)(neng)的(de)便捷、經濟、綠色的(de)出(chu)行(xing)生(sheng)態圈，為電動(dong)(dong)化(hua)出(chu)行(xing)提供(gong)一(yi)體化(hua)能(neng)(neng)(neng)源(yuan)(yuan)解決(jue)方案，致力于成為領先的(de)移動(dong)(dong)數字能(neng)(neng)(neng)源(yuan)(yuan)科技運(yun)營(ying)(ying)商。

1、業務痛點

隨著(zhu)新能(neng)(neng)源(yuan)汽(qi)車的(de)(de)廣泛普及，補能(neng)(neng)的(de)(de)效率問題逐漸(jian)成為(wei)(wei)了廣大車主(zhu)面臨的(de)(de)痛點難(nan)題。為(wei)(wei)了解決此難(nan)題，作為(wei)(wei)一家頭部的(de)(de)新能(neng)(neng)源(yuan)公司，協鑫(xin)能(neng)(neng)科創新突破，切入(ru)能(neng)(neng)源(yuan)服務(wu)領域，打造了以換(huan)電(dian)為(wei)(wei)核心業務(wu)的(de)(de)移動能(neng)(neng)源(yuan)解決方案品(pin)牌(pai)「協鑫(xin)電(dian)港」。

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

最(zui)(zui)終(zhong)，TDengine 以其獨特而科學的(de)(de)設計和優秀的(de)(de)測試表(biao)現成為(wei)我們(men)選中的(de)(de)時序數據處理引擎，承擔了用(yong)(yong)戶車輛數據、電池設備(bei)數據以及換電港工(gong)作設備(bei)等(deng)的(de)(de)海量數據存儲分析(xi)任務，為(wei)我們(men)解決了該(gai)項目上難度最(zui)(zui)大的(de)(de)一個(ge)環節。最(zui)(zui)終(zhong)，我們(men)決定使用(yong)(yong) TDengine 2.4.0.10 版本，并在電信(xin)的(de)(de)天(tian)翼云上落地(di)了該(gai)項目。

2、架構與搭建

從流量削峰以及數(shu)據安全的(de)角度出(chu)發，我(wo)們(men)會先通(tong)過使用某 MQTT 消息服務器把這些不(bu)同(tong)種類的(de)設備數(shu)據先統(tong)一轉(zhuan)發給到(dao)(dao) Kafka。其中不(bu)同(tong)類型的(de)數(shu)據，將(jiang)會分別上傳到(dao)(dao)不(bu)同(tong)的(de) Kafka topic，最后再通(tong)過 Java 連接器把數(shu)據寫(xie)入(ru) TDengine。具體(ti)架構如下圖所示：

在整(zheng)體(ti)架(jia)構上，除了 TDengine，也有(you)一些其它數(shu)(shu)據庫共同支(zhi)持系統服務，其中 MySQL 負責存儲(chu)訂(ding)單(dan)、流水(shui)等需要精(jing)細查詢的(de)關系型數(shu)(shu)據，但由于(yu) MySQL 可以承(cheng)受的(de)數(shu)(shu)據量比較有(you)限，為了做一些大(da)表(biao)的(de)連接(jie)查詢，因此我們(men)也接(jie)入了 TiDB，負責分析報表(biao)類數(shu)(shu)據的(de)存儲(chu)。

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

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

對于 TDengine，我們一開始(shi)使用的是單節點，在穩定運營了(le)(le)幾(ji)個月后(hou)，于今年(nian) ;3 月完成了(le)(le)動態(tai)擴容，發(fa)展到了(le)(le) 3 節點集群模式，把數據庫也(ye)升級到了(le)(le)三副本（從圖中可以(yi)看(kan)出來）。

TDengine 的動態擴(kuo)展非常方(fang)便，只要(yao)確保一些必(bi)要(yao)的參數(shu)保持(chi)一致(zhi)，就可(ke)以直接通過(guo)(guo) “create dnode”把新的計算資源加進(jin)來。加入后，再通過(guo)(guo) “alter database iot replica 3” 這個命令，即可(ke)直接在線令數(shu)據庫變為 3 副(fu)本，從(cong)而實現數(shu)據的備份及高(gao)可(ke)用(yong)。 

3、效果分析

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

在查(cha)詢方面，在此列(lie)舉一些我們(men)常(chang)用的(de)(de) SQL，TDengine 的(de)(de)響應速度(du)都很(hen)快，完全可以滿足我們(men)的(de)(de)需求：

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 的一些思考

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

隨著業務(wu)快(kuai)速增長(chang)(chang)，TDengine 集(ji)群(qun)存(cun)儲(chu)的(de)數據量(liang)也會(hui)越(yue)來越(yue)大，而數據又需(xu)要長(chang)(chang)期(qi)保留，大數據量(liang)的(de)運(yun)維(wei)對于(yu) TDengine 來說將(jiang)是一個巨(ju)大的(de)挑戰。伴隨數據量(liang)級的(de)增長(chang)(chang)，備份(fen)、遷移、庫、表的(de)運(yun)維(wei)都會(hui)受到影響，也有可能遇到我(wo)們(men)之前沒有經(jing)歷(li)過的(de)問(wen)題，這就需(xu)要 TDengine 集(ji)群(qun)實現升級、擴展(zhan)、拆分(fen)、維(wei)護等(deng)運(yun)維(wei)操作。未來我(wo)們(men)希望能積累更多(duo)的(de)經(jing)驗分(fen)享(xiang)給社(she)區，讓更多(duo)的(de)人了解 TDengine。

對(dui)于 TDengine 未來的發展，我們也(ye)有(you)自(zi)己的期(qi)待：

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

總(zong)而言之，希望(wang)(wang) TDengine 后面越(yue)來越(yue)好，也(ye)希望(wang)(wang)我們的合作能更上一層(ceng)樓。