小 T 導讀：為了更好地支持陽光氫能 PEM 綠電制氫系統，本文作者所在的部門需要尋找一套滿足業務和性能需求、而且具有國產知識產權的時序數據庫，來替代(dai)原本使(shi)用的(de) InfluxDB。本文分享了他們(men)將 InfluxDB 替換(huan)為 TDengine 的(de)具(ju)體原因(yin)，以(yi)及(ji)相關(guan)的(de)實踐思路。

企業簡介

陽光(guang)電源成立于(yu) 1997 年(nian)，專注于(yu)逆變(bian)器的(de)自(zi)主研發與(yu)制造。經過二(er)十多年(nian)的(de)技術積累，集(ji)團逐漸確立在(zai)光(guang)伏(fu)逆變(bian)器領(ling)域的(de)龍頭(tou)地位，打造了風、光(guang)、儲、氫的(de)新(xin)能源完整(zheng)格局，做到傳統業(ye)務和創(chuang)新(xin)業(ye)務雙管(guan)齊下、協同發展。

項目介紹

在碳(tan)中和這個大背景(jing)下，氫(qing)(qing)能是新能源領域中與油(you)(you)氣行(xing)業(ye)現(xian)有(you)業(ye)務(wu)結(jie)合最(zui)緊密(mi)的一(yi)類，也是幫助(zhu)油(you)(you)氣行(xing)業(ye)早日實(shi)現(xian)碳(tan)達峰、碳(tan)中和的最(zui)佳路(lu)徑之(zhi)一(yi)。2022?年?7?月?16?日，陽光氫(qing)(qing)能?200Nm3/h PEM?綠電(dian)制氫(qing)(qing)系統(tong)(tong)啟(qi)運發貨。該套系統(tong)(tong)采(cai)用國(guo)內(nei)(nei)領先的?PEM?電(dian)解水制氫(qing)(qing)技(ji)術和?IGBT?制氫(qing)(qing)電(dian)源，工藝復雜，涉及多項(xiang)國(guo)內(nei)(nei)專(zhuan)利(li)技(ji)術。為了更好地監(jian)測整體生產(chan)(chan)流(liu)程(cheng)數(shu)據(ju)，我們需要尋(xun)找一(yi)套滿足(zu)業(ye)務(wu)和性能需求，而且具(ju)有(you)國(guo)產(chan)(chan)知識產(chan)(chan)權的時序數(shu)據(ju)庫（Time Series Database），以響應國(guo)家信創號召。

時序數據庫選型之 InfluxDB vs TDengine

在 InfluxDB 和 TDengine 之間，之所以選擇 TDengine ，其實我很早之前就寫過一篇文章，題目是《從 InfluxDB 到 TDengine，我們為什么會做出這個選擇》，在其中表述的比較清楚了。這里可(ke)以再簡單總結一(yi)下：

第一，TDengine 超級表和普通表的概念非常契合我們項目的業務場景。此前我(wo)們的項目(mu)是一(yi)個站點一(yi)個單元對應(ying)多個測(ce)點，現在(zai)利用超級(ji)表(biao)-普通表(biao)的模型，業務(wu)模型會更加清晰。

第二，查詢更具有優勢。在使用(yong)老版 InfluxDB 的歷史數據查詢功能(neng)時(shi)，只(zhi)要操作(zuo)稍微頻(pin)繁一點（比如選擇一個時(shi)間(jian)段之后(hou)，曲線(xian)很久還沒有渲染出來，又去換了一個時(shi)間(jian)段），就會導致頁面卡死，取(qu)不到數據，這(zhe)時(shi)候(hou)需要重啟瀏覽器，極(ji)度影(ying)響客戶體驗。

但是(shi)在(zai)使(shi)(shi)用(yong) TDengine 之后，不(bu)論是(shi)大批量拉取范圍數(shu)據，還是(shi)使(shi)(shi)用(yong)函(han)數(shu)計算(suan)，查詢(xun)再也沒(mei)有出(chu)現過瀏覽器卡死的(de)情(qing)(qing)況。TDengine 拉取單設備大范圍時間數(shu)據查詢(xun)的(de) SQL 以及耗時情(qing)(qing)況，如以下截圖如下：

不得(de)不說，這(zhe)些查詢的性能都(dou)十(shi)分出(chu)色，完(wan)全滿足我們(men)的應用場景。

第三，搭建集群的成本更低廉。眾所周(zhou)知，InfluxDB 集群(qun)功(gong)能是閉源(yuan)的，如(ru)果(guo)后續(xu)業(ye)務發展(zhan)需要用到集群(qun)時會帶來很大的不便。然而 TDengine 的集群(qun)功(gong)能是開源(yuan)的，且擴(kuo)展(zhan)方便，因此可以(yi)顯著降低運維成本。

最后，從用戶支持的角度來說，選用(yong)國外的 Database 有很大的不確定性(xing)，但(dan)在使用(yong) TDengine 時如(ru)果(guo)需要支持，就可(ke)以(yi)直接通過微信/郵箱(xiang)等工具隨時和技術人員(yuan)進行交流，更加有效(xiao)方便。如(ru)果(guo)對產品性(xing)能(neng)功能(neng)、業務保障要求高的話，就可(ke)以(yi)隨時升(sheng)級到企業級的服務。

TDengine 落地實踐

在我(wo)們的(de)(de)這套系統(tong)中應用(yong)(yong)的(de)(de) TDengine 版(ban)本為 2.4.0.0，主要(yao)用(yong)(yong)于存儲大(da)量設(she)(she)備(bei)產生(sheng)的(de)(de)時(shi)序數(shu)據，我(wo)們整(zheng)個項目的(de)(de)智能化都是基于這些(xie)數(shu)據展開。采集設(she)(she)備(bei)主要(yao)為堿(jian)液循環泵、脫氧塔(ta)、純水機、電(dian)解槽等制氫設(she)(she)備(bei)。

該(gai)套制(zhi)氫系統除(chu) PEM 制(zhi)氫優(you)勢外(wai)，還具有(you)智能(neng)(neng)(neng)化(hua)程(cheng)度高的(de)特(te)點(dian)(dian)，采用的(de)智能(neng)(neng)(neng)控制(zhi)算法與(yu)可再生能(neng)(neng)(neng)源波動(dong)、間歇性特(te)點(dian)(dian)相契合，兼具高效、經(jing)濟(ji)、安全、智能(neng)(neng)(neng)等(deng)(deng)優(you)勢，適(shi)用于制(zhi)、儲(chu)(chu)、加一體化(hua)制(zhi)氫項目(mu)。在這個過程(cheng)中，我們會(hui)對(dui) TDengine 存儲(chu)(chu)的(de)設備數(shu)據進行分析計(ji)算，最后通過大屏展示(shi)以達到實時(shi)監控、分析等(deng)(deng)需求。

整個(ge)業務架構(gou)大致如下：以我們(men)自(zi)己編寫(xie)的 mosbusTCP 驅動，結合(he)數(shu)(shu)采(cai)(cai)硬件設(she)備(bei)采(cai)(cai)集(ji)設(she)備(bei)數(shu)(shu)據，然(ran)后通過 JDBC-RESTful 的方式將數(shu)(shu)據寫(xie)入 TDengine。數(shu)(shu)據采(cai)(cai)集(ji)點(dian)總共有(you) 9000 多(duo)個(ge)，頻率為大概每秒寫(xie)入一次。

目前單列模型下，最大的超級表已經保留了幾百億行的的數據，當前磁盤占用 55GB 左右的空間，壓縮比大概在 10-15% 之間。

經驗分享

值得(de)一(yi)提的(de)是(shi)(shi)，TDengine 是(shi)(shi)根據表(biao)來做(zuo)數據分片的(de)，vnode 就是(shi)(shi)最小單(dan)位，在這(zhe)種情況(kuang)下，保證數據量均(jun)衡(heng)的(de)前提是(shi)(shi)寫入量均(jun)勻，否(fou)則如果某(mou)些設(she)備(bei)(bei)過熱，某(mou)些設(she)備(bei)(bei)過冷(leng)，就會出現某(mou)個 vnode 極(ji)大，某(mou)個 vnode 極(ji)小的(de)情況(kuang)。

這一點在建表之初是需要考慮的，防止時間過久后，數據過于傾斜。具體調整方式可以參考這篇文章。比如，如果初期的設備熱度比較高的話，就可以調小 minTablesPerVnode，在第一波建表時便把表均勻開到不同 vnode 里，這樣可以針對性地利用起每個 vnode 有獨立寫入線程的特點，充分利用計算資源。（上文中的 vnode 截圖并(bing)不是(shi)我的寫(xie)入不均(jun)勻，只是(shi)單純(chun)的新建(jian)表不久還(huan)沒有寫(xie)入太多數據。）

此外，在我們的使用過程中，也有遇到過一些問題。比如使用超級表的 select * 查詢時，時間跨度比較久的數據返回會有些慢，這跟當前版本的架構有關，一個該類查詢會生成多個子查詢，每個 vnode 的子查詢是在服務端串形處理的，即在一個 vnode 中檢索查詢完畢后再查下一個，最后匯總。解決方案是把時間段拆開成多段，使用多線程來查詢。根據 TDengine 的規劃，在后續的 3.x 版本中，此類查詢將會和聚合查詢一樣變成并行處理，查詢效率會大大提升。而其他問題多(duo)為配置部署相關(guan)，仔細閱讀文檔，都可(ke)以得到(dao)很(hen)好的解決。

對于 TDengine 在(zai)現有業(ye)務體系下的表現，我(wo)們還比較(jiao)滿(man)意(yi)，后面也會嘗試探(tan)索(suo)更多的合作可(ke)能，不斷為客戶創(chuang)造價值，以技術(shu)驅動綠(lv)氫產業(ye)發展(zhan)。