小 T 導(dǎo)讀：為了更好地支持陽光氫能 PEM 綠電制氫系統(tǒng)，本文作者所在的部門需要尋找一套滿足業(yè)務(wù)和性能需求、而且具有國產(chǎn)知識產(chǎn)權(quán)的時序數(shù)據(jù)庫，來替代原本使用的 InfluxDB。本文分享了他們將 InfluxDB 替換為 TDengine 的具體原因，以及相關(guān)的實踐思路。

企業(yè)簡介

陽光電源成立于 1997 年，專注于逆變器的自主研發(fā)與制造。經(jīng)過二十多年的技術(shù)積累，集團逐漸確立在光伏逆變器領(lǐng)域的龍頭地位，打造了風(fēng)、光、儲、氫的新能源完整格局，做到傳統(tǒng)業(yè)務(wù)和創(chuàng)新業(yè)務(wù)雙管齊下、協(xié)同發(fā)展。

項目介紹

在碳中和這個大背景下，氫能是新能源領(lǐng)域中與油氣行業(yè)現(xiàn)有業(yè)務(wù)結(jié)合最緊密的一類，也是幫助油氣行業(yè)早日實現(xiàn)碳達(dá)峰、碳中和的最佳路徑之一。2022?年?7?月?16?日，陽光氫能?200Nm3/h PEM?綠電制氫系統(tǒng)啟運發(fā)貨。該套系統(tǒng)采用國內(nèi)領(lǐng)先的?PEM?電解水制氫技術(shù)和?IGBT?制氫電源，工藝復(fù)雜，涉及多項國內(nèi)專利技術(shù)。為了更好地監(jiān)測整體生產(chǎn)流程數(shù)據(jù)，我們需要尋找一套滿足業(yè)務(wù)和性能需求，而且具有國產(chǎn)知識產(chǎn)權(quán)的時序數(shù)據(jù)庫（Time Series Database），以響應(yīng)國家信創(chuàng)號召。

時序數(shù)據(jù)庫選型之 InfluxDB vs TDengine

在 InfluxDB 和 TDengine 之間，之所以選擇 TDengine ，其實我很早之前就寫過一篇文章，題目是《從 InfluxDB 到 TDengine，我們?yōu)槭裁磿龀鲞@個選擇》，在其中表述的比較清楚了。這里可以再簡單總結(jié)一下：

第一，TDengine 超級表和普通表的概念非常契合我們項目的業(yè)務(wù)場景。此前我們的項目是一個站點一個單元對應(yīng)多個測點，現(xiàn)在利用超級表-普通表的模型，業(yè)務(wù)模型會更加清晰。

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

但是在使用 TDengine 之后，不論是大批量拉取范圍數(shù)據(jù)，還是使用函數(shù)計算，查詢再也沒有出現(xiàn)過瀏覽器卡死的情況。TDengine 拉取單設(shè)備大范圍時間數(shù)據(jù)查詢的 SQL 以及耗時情況，如以下截圖如下：

不得不說，這些查詢的性能都十分出色，完全滿足我們的應(yīng)用場景。

第三，搭建集群的成本更低廉。眾所周知，InfluxDB 集群功能是閉源的，如果后續(xù)業(yè)務(wù)發(fā)展需要用到集群時會帶來很大的不便。然而 TDengine 的集群功能是開源的，且擴展方便，因此可以顯著降低運維成本。

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

TDengine 落地實踐

在我們的這套系統(tǒng)中應(yīng)用的 TDengine 版本為 2.4.0.0，主要用于存儲大量設(shè)備產(chǎn)生的時序數(shù)據(jù)，我們整個項目的智能化都是基于這些數(shù)據(jù)展開。采集設(shè)備主要為堿液循環(huán)泵、脫氧塔、純水機、電解槽等制氫設(shè)備。

該套制氫系統(tǒng)除 PEM 制氫優(yōu)勢外，還具有智能化程度高的特點，采用的智能控制算法與可再生能源波動、間歇性特點相契合，兼具高效、經(jīng)濟、安全、智能等優(yōu)勢，適用于制、儲、加一體化制氫項目。在這個過程中，我們會對 TDengine 存儲的設(shè)備數(shù)據(jù)進行分析計算，最后通過大屏展示以達(dá)到實時監(jiān)控、分析等需求。

整個業(yè)務(wù)架構(gòu)大致如下：以我們自己編寫的 mosbusTCP 驅(qū)動，結(jié)合數(shù)采硬件設(shè)備采集設(shè)備數(shù)據(jù)，然后通過 JDBC-RESTful 的方式將數(shù)據(jù)寫入 TDengine。數(shù)據(jù)采集點總共有 9000 多個，頻率為大概每秒寫入一次。

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

經(jīng)驗分享

值得一提的是，TDengine 是根據(jù)表來做數(shù)據(jù)分片的，vnode 就是最小單位，在這種情況下，保證數(shù)據(jù)量均衡的前提是寫入量均勻，否則如果某些設(shè)備過熱，某些設(shè)備過冷，就會出現(xiàn)某個 vnode 極大，某個 vnode 極小的情況。

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

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

對于 TDengine 在現(xiàn)有業(yè)務(wù)體系下的表現(xiàn)，我們還比較滿意，后面也會嘗試探索更多的合作可能，不斷為客戶創(chuàng)造價值，以技術(shù)驅(qū)動綠氫產(chǎn)業(yè)發(fā)展。