小T導讀:上海電氣集團股份有限公司是世界級的綜合性高端裝備制造企業,聚焦智慧能源、智能制造、智能(neng)基(ji)礎設施三大業務領域(yu),為客(ke)戶提(ti)供工(gong)業級的(de)綠(lv)色(se)智能(neng)系統解決(jue)方案。業務遍及(ji)(ji)全(quan)球,主要包括新能(neng)源(yuan)、綜(zong)合能(neng)源(yuan)、環保(bao)、醫療器械(xie)及(ji)(ji)工(gong)業自動化等。
公(gong)司圍繞“一芯 3S”核心產品鏈(lian),構建(jian)儲(chu)能(neng)核心競爭力(li)。作為(wei)其中關鍵(jian)組(zu)成部分(fen)的“SmartOPS 儲(chu)能(neng)智(zhi)慧運維系統”,基于物聯網(wang)、大數據、機器學習(xi)等技術(shu),打通儲(chu)能(neng)系統從信息采集到云端(duan)接(jie)入,再(zai)到數據存儲(chu)、數據分(fen)析的完整(zheng)技術(shu)鏈(lian)條,構建(jian)智(zhi)慧儲(chu)能(neng)管控體系平臺,實(shi)現全面監測、預(yu)測性維護(hu)、熱管理(li)分(fen)析等高(gao)級應用,幫助客戶實(shi)現儲(chu)能(neng)設備的最優(you)配置和高(gao)效(xiao)利用。

一、應用背景
SmartOPS 支持云端部署(shu)和本地部署(shu)兩種(zhong)方式(shi)。
云端部署基于上海電氣集團當前統一的架構,利用云端時序數據庫(Time-Series Database),可擴(kuo)展、可靈活配(pei)置的(de)各類資(zi)源,可輕松滿足(zu)使用要求,高效且(qie)流(liu)暢。
但是在本地(di)部署(shu)中,需要重點考慮(lv)本地(di)硬(ying)件資源的限(xian)制(zhi),如站端系(xi)統的內存、CPU 以及讀寫性能等。目前(qian)站端系(xi)統的配(pei)置下圖所示。

所(suo)以我們(men)需要考(kao)慮適合(he)在(zai)站端系(xi)統(tong)中部(bu)署的(de)時(shi)序數據庫,也就(jiu)有了接下(xia)來的(de)技術(shu)選型。
二、技術選型
整體(ti)選型考慮會涉及很多(duo)維(wei)度,具體(ti)包括讀寫性(xing)(xing)(xing)能(neng)、壓縮率、行業認可度、產品活力(li)、服務(wu)支持、安全性(xing)(xing)(xing)、兼容性(xing)(xing)(xing)、可維(wei)護性(xing)(xing)(xing)、可擴展(zhan)性(xing)(xing)(xing)、功能(neng)性(xing)(xing)(xing)、可靠性(xing)(xing)(xing)、易(yi)用性(xing)(xing)(xing)等屬(shu)性(xing)(xing)(xing)。
我們(men)團隊著重評(ping)估(gu)了以下(xia)幾款 Database:
- OpenTSDB:以 HBase 為底層存儲,向上封裝了自己的邏輯層和對外接口層。這種架構可以充分利用 HBase 的特性,實現數據的高可用和較好的寫入性能。但相比原生時序數據庫,OpenTSDB 數據棧較長,在讀寫性能和數據壓縮方面都還有進一步優化的空間。
- InfluxDB:目前流行度最高的時序數據庫,數據按列存儲,能夠高效地對時序數據進行處理、存儲、查詢,并提供了功能豐富的 Web 平臺,可以對數據進行可視化展示和交互式分析。
- Apache IoTDB:專為物聯網打造的分布式時序數據庫,數據按列存儲,具有優秀的寫入性能和豐富的數據分析功能,能夠有效地處理亂序數據。
- TDengine:專為物聯網場景設計和優化的分布式時序數據庫,數據按列存儲,具有極致的寫入性能和豐富的查詢功能,同時提供緩存、流處理、消息隊列等大數據平臺常用功能。其官網提到的不到10MB 的安裝包以及 10 倍的性能提升,確實非常吸引人。
- ClickHouse:性能強勁的 OLAP 數據庫,數據按列存儲,數據壓縮比極高,具有很高的寫入吞吐和極致的查詢性能,同時提供了豐富的數據處理函數,便于對數據進行各種分析。
基于站端(duan)本地化部署需(xu)要輕量級資源占(zhan)用出發,我們首先排(pai)除了 OpenTSDB 和(he) Apache IoTDB,OpenTSDB 基于 HBase,比較重(zhong),而 Apache IoTDB 在資源占(zhan)用方面對邊緣輕量級設備(bei)也(ye)不算友好;ClickHouse 優(you)勢(shi)是單表快,其他方面偏弱(ruo),包括 join、管理運(yun)維都(dou)比較復雜,也(ye)放棄了。
研發團(tuan)隊最(zui)終圈(quan)定在 InfluxDB 和 TDengine 中(zhong)測試(shi)選擇(ze)。
三、初步對比測試
技術團隊實際對比測試了(le) InfluxDB 和 TDengine。
先來看 InfluxDB 的測試情況。
InfluxDB 的安裝包大小(xiao)為 60.2 MB,運行之后資源占用如下圖所示(shi):

開啟(qi)測試(shi)場站(zhan)數據接入(ru)(ru),當前(qian)時刻(ke),每分(fen)鐘寫入(ru)(ru)字(zi)段數小于 3000,此時資源消耗(hao)情況如下(xia)圖所示(shi),當前(qian) InfluxDB 消耗(hao) CPU 有所上升,內存資源變化不大。

通過如下命令測試(shi)查詢(xun)功(gong)能:

資源消耗情況如下圖所示(shi):

同時,當(dang)前查(cha)詢會被卡住,所以沒有結果。可見,在(zai)當(dang)前資源配置條件下,InfluxDB 私有化部署資源消耗較高,若同時啟(qi)用(yong)本地應用(yong)服(fu)務(SmartOPS),則(ze)無法提(ti)供所需功能。
再來看 TDengine 的測試情(qing)況(kuang)。
我們使用(yong)的是(shi) TDengine 2.1.6.0 版本(ben)。查看安裝包 TDengine-server-2.1.6.0-beta-Linux-x64.rpm 的大(da)小,發(fa)現只有 9.42 MB。后端開發(fa)人員將其部(bu)署到了測(ce)試節(jie)點上(shang)。
剛(gang)部(bu)署時的(de)資源(yuan)消耗如下(xia):

模擬某場站數據(ju)接入時,資(zi)源消(xiao)耗如下:

然后測試查詢功能(neng),在同(tong)樣條(tiao)件下(xia),TDengine 出現 CPU 上的短時(shi)(shi)小幅上升,同(tong)時(shi)(shi)毫秒(miao)級獲取到了查詢返回結果。
從(cong)上述的(de)初步(bu)測試中可以(yi)發現(xian),在(zai)本地(di)化部署(shu)服務器(qi)資源受限的(de)情(qing)況下,相比(bi)于(yu) InfluxDB,TDengine 在(zai)站端系統的(de)應(ying)用(yong)上,性能(neng)具(ju)有明顯(xian)的(de)優勢。TDengine 能(neng)較好地(di)應(ying)對(dui)場站端低配(pei)服務器(qi)的(de)資源限制問題(ti)。對(dui)于(yu)大批量應(ying)用(yong)的(de)儲(chu)能(neng)場景,提供了(le)高性價比(bi)的(de)解決方(fang)案。
TDengine 針對物聯網應用的場景特點,比如數據極少有更新或刪除操作,無需傳統數據庫的事務處理,相對互聯網應用寫多讀少等,又通過“一個數據采集點一張表”和“超級表”的概念,簡化了數據存儲結構,這些優化確實非常適合我們的方案。另外通過一些預計算功能,提高了聚合查詢效率,完全滿足我(wo)們站(zhan)端資源有限情況下儲能場景的需求(qiu)。
于是我(wo)們就嘗試在(zai)系統(tong)中落地(di)了(le) TDengine。
四、TDengine 數據模型設計
儲能場(chang)(chang)站設(she)(she)備(bei)返回的(de)數(shu)據格式基本固(gu)定,一(yi)個(ge)(ge)時間戳一(yi)個(ge)(ge)值。所以我們(men)為一(yi)個(ge)(ge)場(chang)(chang)站構(gou)建了一(yi)張(zhang)超級表。子(zi)表是根據點(dian)(dian)位的(de)信(xin)息,一(yi)個(ge)(ge)點(dian)(dian)位一(yi)張(zhang)子(zi)表,用于區分不(bu)同的(de)設(she)(she)備(bei)采集的(de)信(xin)息。結合業務(wu)需求,標(biao)簽(qian)定為 5 個(ge)(ge):點(dian)(dian)的(de)標(biao)識,場(chang)(chang)站 id,子(zi)站 id,單元 id 和設(she)(she)備(bei) id。
超級表建(jian)表語句為:
create table ops (ts TIMESTAMP,value FLOAT) TAGS (name NCHAR(10),sid NCHAR(20),sub NCHAR(10),unit NCHAR(10),dev NCHAR(20))
子表(biao)建表(biao)語句(ju)為:
CREATE TABLE escngxsh02_g01_e03h01_c1 USING ops TAGS ("C1","ESCNGXSH02","G01","E03","E03H01")
在使用(yong) InfluxDB 一(yi)周(zhou)以后,使用(yong) SQL 語句
select * from ops WHERE ts>1629450000000 and ts<1629463600000 limit 2;
來執(zhi)行查詢(xun),內存使用率達到了(le) 80%,并且過了(le)十分鐘也沒出來結果,所以已(yi)經完全(quan)不適合(he)業務(wu)使用。 而(er)在使用了(le) TDengine 近1個月后(hou),使用相同的(de) SQL 語句,查詢(xun)只需要 0.2 秒。表現非常優異(yi)。
五、TDengine 的使用情況
目前(qian)技術團隊已采用 TDengine 作為 SCU(Station Control Unit) 架構的(de)核(he)心時序數(shu)據庫,實現(xian)儲(chu)能(neng)(neng)系統綜合信息感知、就地運(yun)行(xing)控(kong)制與(yu)協(xie)調保護功能(neng)(neng);同時支持儲(chu)能(neng)(neng)電站(zhan)及設(she)備的(de)遠程運(yun)維,實現(xian)高級(ji)數(shu)據分析與(yu)運(yun)行(xing)優化,全方面守護儲(chu)能(neng)(neng)電站(zhan)的(de)安全。

TDengine 高性能的寫入和聚合查詢功能,能夠毫秒級響(xiang)應(ying)電站運行(xing)信(xin)息(xi)監視。


在(zai)壓(ya)縮(suo)方面,TDengine 也表現得很優秀(xiu)。在(zai)采(cai)集點數量相同的(de)情況下,在(zai)使(shi)(shi)用(yong) TDengine 之前,我們(men)使(shi)(shi)用(yong)的(de)是(shi) InfluxDB,1 天的(de)數據(ju)(ju)量大概是(shi) 200 多 MB,而使(shi)(shi)用(yong)了 TDengine 后(hou),1 天的(de)數據(ju)(ju)居(ju)然不到(dao) 70 MB,是(shi) InfluxDB 的(de) 1/3。
我們還將在后續項目(mu)中,繼續拓展其(qi)分(fen)(fen)(fen)布式集群應用,構建(jian)儲(chu)能電站運行情況(kuang)的(de)數(shu)(shu)字化檔案,結合開發的(de)分(fen)(fen)(fen)析(xi)算法、預(yu)測算法、數(shu)(shu)據挖掘技術,實現電站穩定(ding)(ding)性(xing)分(fen)(fen)(fen)析(xi)、效率(lv)和(he)損(sun)耗分(fen)(fen)(fen)析(xi)、故障預(yu)測、壽(shou)命預(yu)測、性(xing)能短板定(ding)(ding)位以(yi)及熱(re)管理分(fen)(fen)(fen)析(xi)等高級分(fen)(fen)(fen)析(xi)和(he)診(zhen)斷功(gong)能。


























