作者：寧龍 華自科技

小 T 導讀：華(hua)自科技專注于自動化(hua)、信息化(hua)和智能化(hua)技術(shu)，為能源、環保、工業控制(zhi)、水利等領(ling)(ling)域用戶提供核(he)心軟(ruan)硬件產品(pin)與系統解決方案，是多能物聯技術(shu)領(ling)(ling)航企業。公司在(zai)電站及(ji)泵站自動化(hua)控制(zhi)設備市場占有率全球領(ling)(ling)先，是聯合國工業發展組(zu)織國際小水電中心控制(zhi)設備制(zhi)造基地。

物聯網數(shu)據(ju)平臺(tai)是電站及泵站智慧運維平臺(tai)的核心組成(cheng)，其整體(ti)架(jia)構如(ru)下：

物聯網數(shu)據(ju)(ju)平臺(tai)的(de)數(shu)據(ju)(ju)來源主(zhu)要為電(dian)站(zhan)、水廠、儲能站(zhan)，通(tong)過數(shu)據(ju)(ju)網關，將各場站(zhan)端(duan)的(de)設備運行數(shu)據(ju)(ju)傳輸至云平臺(tai)的(de)消息隊(dui)列（MQ）中，數(shu)據(ju)(ju)處(chu)理服務(wu)訂(ding)閱(yue)MQ的(de)消息，根據(ju)(ju)設定的(de)規則(ze)引擎，進行實時(shi)數(shu)據(ju)(ju)處(chu)理，之后(hou)將數(shu)據(ju)(ju)存儲落盤。數(shu)據(ju)(ju)服務(wu)API則(ze)根據(ju)(ju)業(ye)務(wu)需求提供包含實時(shi)數(shu)據(ju)(ju)和歷史數(shu)據(ju)(ju)在內的(de)數(shu)據(ju)(ju)API。

一、現狀及痛點

對于歷史數(shu)據(ju)，目前我(wo)們采用的MySQL分庫分表(biao)方(fang)案來存儲；實時數(shu)據(ju)會存儲在(zai)Redis中。在(zai)測點數(shu)較少或者集控需求不是(shi)很多的場景下，基本滿足需求。

歷史數據

歷史數據用MySQL存(cun)儲，一(yi)個(ge)站點對應一(yi)個(ge)數據庫；一(yi)個(ge)測點對應一(yi)張表(biao)，建表(biao)語句(ju)大(da)致如下：

CREATE TABLE `yc_測點id` (
  `ts` datetime NOT NULL,
  `val` double NOT NULL
);

實時數據

實時(shi)數據(ju)緩存(cun)到Redis中，以測(ce)點Id為key，同時(shi)緩存(cun)數據(ju)上報的時(shi)間、測(ce)量值(zhi)和質量值(zhi)等信息。

數據計算查詢

我們利用MySQL的(de)各種函數、多表連(lian)接、應(ying)用程(cheng)序內存計算(suan)等方式，計算(suan)出結果返回(hui)給前(qian)端，對于月、年等報表類的(de)計算(suan)，則(ze)采用定時任務生成。

痛點

隨著平(ping)臺業務(wu)的發展，接入的站(zhan)點(dian)(dian)越來越多，或(huo)者單(dan)站(zhan)的測點(dian)(dian)數越來越多，問題逐漸凸顯出(chu)來了。具體(ti)可以歸納為如下幾個方面：

運維難

• 對于新接入的站點，首先得為這個站建立好數據庫、數據表，增加了接站的工作量；
• 由于一個站對應著一個數據庫，隨著平臺接入的站點越來越多，數據庫不斷增加，數據庫的管理和備份成本不斷提高；
• 隨著測點的增加，緩存實時數據的單機Redis遲早有一天會撐不住，需要考慮維護Redis集群。

開發難

隨著平臺(tai)的(de)業務發展，越(yue)(yue)來(lai)越(yue)(yue)多的(de)站被接入平臺(tai)，集(ji)控需求(跨站聚(ju)合分(fen)析需求)增(zeng)加，跨庫(ku)跨表的(de)查詢操作(zuo)越(yue)(yue)來(lai)越(yue)(yue)多，這(zhe)就增(zeng)加了系統開發的(de)難度(du)，嚴重影(ying)響(xiang)了系統響(xiang)應(ying)速(su)度(du)和(he)穩定(ding)性。

成本高

成本(ben)主要(yao)有兩個方面，一(yi)個是人(ren)力成本(ben)高(gao)(gao)，由于(yu)開(kai)發、運維的難度(du)增加，造成員(yuan)工(gong)工(gong)作量增加，工(gong)作效(xiao)率變低，從企(qi)業經營角(jiao)度(du)看，人(ren)力成本(ben)變高(gao)(gao)；另一(yi)個是硬(ying)件資源(yuan)成本(ben)高(gao)(gao)，由于(yu)服務節點眾多，占用的主機(ji)、內存和磁盤空間也會很多，購買(mai)或租(zu)用這(zhe)些(xie)硬(ying)件資源(yuan)需要(yao)支出(chu)更多費用。

二、技術選型

為了(le)解決目前這些問題，我們(men)決定重新進行技(ji)術(shu)選(xuan)型，尋找(zhao)替代(dai)方案，升級(ji)目前數(shu)據庫(ku)存儲方案。結(jie)合平臺實際(ji)需要，我們(men)確定了(le)幾(ji)個選(xuan)型要求：

• 業務改動小：盡可能減少對現有業務的影響；
• 開源免費：必須是開源的，并且允許免費商用，最好也有商業版；
• 迭代更新：社區活躍，不斷在迭代更新和發布新版本；
• 性能高：單機能支持每秒10萬以上的插入效率；
• 開銷低：服務節點少，占用的內存、CPU和磁盤空間少；
• 支持集群：能夠集群部署，容量可水平擴展；
• 安裝維護簡單: 數據量較小的情況下，支持單機部署，并且占用資源較少；

我們了解了多款典型的時序數據庫（Time-Series Database）產(chan)品，最終InfluxDB、庚頓、麥杰、TimescaleDB、TDengine這幾款進入了(le)我們的(de)考察(cha)范圍(wei)。下(xia)面我們來具(ju)體(ti)看一下(xia)：

1.InfluxDB

在開源(yuan)時序數(shu)據庫領域長期霸榜，社區活躍(yue)，生態也(ye)比較豐(feng)富，性能也(ye)算(suan)中規中距，唯(wei)一的缺陷就(jiu)是集群模塊不開源(yuan)。

2.庚頓、麥杰

兩(liang)者都(dou)是(shi)(shi)傳統老牌工業(ye)領域的(de)時序數據庫王者，功(gong)能、性(xing)能都(dou)非常不錯，唯一的(de)缺點就是(shi)(shi)不開源，只有商業(ye)版，而且價格昂貴。

3.TimescaleDB

它是在PostgreSQL之上開發的一個插件，是基于關系數據庫的時序數據庫，對于(yu)我們現有的業務使用幾(ji)乎無感知，上層可以繼續(xu)用MyBatis、JPA等ORM框架，但它(ta)(ta)不是一個純粹的時序數據庫；另外，它(ta)(ta)對集(ji)群(qun)支持不好，不支持水平擴展。

4.TDengine

支(zhi)(zhi)持使用(yong)類(lei)SQL查詢語言來插入或查詢數據(ju)，內嵌消息隊列和緩存機制、無歷史(shi)數據(ju)與實時(shi)數據(ju)之(zhi)分、分布式架構，支(zhi)(zhi)持線(xian)性擴展、支(zhi)(zhi)持多(duo)副本(ben)，無單點故障。看到官網的這些介紹，瞬間感覺TDengine就(jiu)是為(wei)我(wo)們準(zhun)備的，于(yu)是馬上(shang)做了各種(zhong)驗證，結果表明，TDengine完全符號我(wo)們的選型要求(qiu)。

為什么沒有采用傳統Hadoop生態

提到(dao)大數據，人們可(ke)(ke)能第一反(fan)應就(jiu)會想到(dao)Hadoop生態。因此我(wo)們前(qian)期也考查過(guo)騰訊云的TBDS數據套(tao)件。說實話(hua)那一套(tao)東(dong)(dong)西真(zhen)的是(shi)(shi)太笨重了，Hadoop、HBase、HDFS、ZooKeeper、Hive、Spark\Flink這系列的東(dong)(dong)西搞下(xia)來，還真(zhen)不是(shi)(shi)一般(ban)(ban)團隊能玩(wan)得轉的，另外我(wo)司的業務場景不止云端服務，還有(you)可(ke)(ke)能會私有(you)化部署在站(zhan)內，硬(ying)件條件可(ke)(ke)能也就(jiu)是(shi)(shi)一兩臺狀況一般(ban)(ban)的服務器。

三、TDengine存儲模型設計

由于TDengine Database可以(yi)設(she)置(zhi)將最新一(yi)條數據存(cun)儲(chu)在內存(cun)中(zhong)，因(yin)此我(wo)們利用這個特(te)性(xing)替換掉了用Redis存(cun)儲(chu)實(shi)時(shi)數據這個環節，改成(cheng)實(shi)時(shi)數據直接(jie)查詢TDengine。

TDengine里有超級表的(de)(de)(de)概念，每(mei)種設備對應(ying)一個超級表(biao)。這(zhe)個超級表(biao)只負責存(cun)儲這(zhe)種類型的(de)(de)(de)設備數(shu)據(ju)，數(shu)據(ju)存(cun)儲采用橫表(biao)存(cun)儲。但是，這(zhe)顯然(ran)不(bu)符合我們的(de)(de)(de)場景(jing)，因為(wei)在我們的(de)(de)(de)場景(jing)里沒有(you)固定(ding)的(de)(de)(de)某一設備對象，且每(mei)個測點的(de)(de)(de)頻率都可能不(bu)一致。

同(tong)時為(wei)了盡(jin)可能(neng)減少對(dui)現有業務的影響，我們將超表設計成如下(xia)結(jie)構：

CREATE STABLE IF NOT EXISTS stb_站點id  (    ts timestamp,        val double        ) TAGS (測id nchar(64))

TDengine的(de)(de)子表，可以在(zai)插入數(shu)據(ju)時(shi)動態創建，這(zhe)(zhe)是TDengine的(de)(de)一(yi)個很好用的(de)(de)功能(neng)。這(zhe)(zhe)樣(yang)能(neng)省去創建子表的(de)(de)業務環(huan)節，降(jiang)低了業務復(fu)雜(za)度。子表結構如(ru)下(xia)：

insert into 測點類型_測點id  USING stb_站點id (測點id) VALUES ( ts, val,q)    eg:  insert into yc_15143115161750995367 USING stb_站點id ('15143115161750995367') VALUES ( ts, val,q)

四、使用到的TDengine特性

1.緩存（Cache）

我們直接使用TDengine提供的(de)緩存（Cache）功(gong)能(neng)，替換了原(yuan)有系統中(zhong)的(de)Redis。創建數據(ju)庫直接開啟cachelast=1，將每張表的(de)最后一(yi)條記錄(lu)緩存，應用程(cheng)序通(tong)過(guo)last_row函數快速獲取實時數據(ju)。

2.數據訂閱(Publisher/Subscriber)

在(zai)我們的(de)(de)業務(wu)場景中有(you)一類(lei)(lei)數(shu)(shu)據(ju)叫SOE事件告警(jing)數(shu)(shu)據(ju)，這類(lei)(lei)數(shu)(shu)據(ju)要實(shi)時(shi)動(dong)(dong)態在(zai)前端頁面上滾動(dong)(dong)。原有(you)做法(fa)是(shi)通過頁面輪訓來實(shi)現的(de)(de)，現在(zai)直接使用(yong)(yong)taos的(de)(de)數(shu)(shu)據(ju)訂閱功能，配合WebSocket，可以優雅地(di)實(shi)現這一功能，大大提升了用(yong)(yong)戶體(ti)驗(yan)。

3.其它一些很用的(de)功(gong)能

比如降采樣查詢、多表聚合查詢、各種標準函數等。

五、改造遷移

由于TDengine采用了類SQL的語(yu)法(fa)，支持MyBatis等ORM框架，因(yin)此(ci)對于老(lao)的業(ye)務，我們在代碼層面的改動非常少，改動最多的就(jiu)是將原(yuan)來的MySQL函數(shu)結合應用代碼的一些計(ji)算邏輯直接用TDengine的函數(shu)替(ti)換(huan)掉。

在試運行(xing)階(jie)段，因為我們(men)都是通(tong)(tong)過自研(yan)數(shu)據(ju)網(wang)關(guan)將數(shu)據(ju)通(tong)(tong)過TCP發送上來的，所以我們(men)利用(yong)tcp-copy，將數(shu)據(ju)復制一份存到TDengine集群，然后通(tong)(tong)過業務(wu)系統觀察和驗(yan)證各項(xiang)功能是否正常。

驗證正常之后，就(jiu)是歷史數據的遷(qian)移(yi)了(le)。由(you)于TDengine的表結構(gou)與原來(lai)的MySQL存儲結構(gou)基本(ben)類似，因此(ci)我們采用DataX的TDengine插件，很方便(bian)就(jiu)將歷史數據遷(qian)移(yi)過來(lai)了(le)。

至此，我們(men)就(jiu)用TDengine Database替換了原有的存儲架構。

總結

初始(shi)接觸一(yi)個新(xin)產品(pin)，難(nan)免會遇到(dao)一(yi)些困難(nan)。好在辦法總比(bi)困難(nan)多，在同(tong)事(shi)們的支(zhi)持(chi)下(xia)，在TDengine的工(gong)程師們的支(zhi)持(chi)下(xia)，我們總算是基本完(wan)成(cheng)了這次實時數據存儲查(cha)詢的升(sheng)級改造(zao)。

當(dang)前項目數(shu)(shu)據(ju)測點(dian)大(da)概(gai)在18萬左右，改造后數(shu)(shu)據(ju)存儲(chu)周期由原來(lai)的(de)5分(fen)鐘(zhong)減少到(dao)1秒鐘(zhong)，存儲(chu)的(de)數(shu)(shu)據(ju)維度更精細了(le)，能為平臺(tai)的(de)智能診斷、智能分(fen)析服(fu)務(wu)提供(gong)更準確的(de)數(shu)(shu)據(ju)支持(chi)，同時各業務(wu)場景(jing)下的(de)計算(suan)查詢性能也(ye)提升了(le)不(bu)少，數(shu)(shu)據(ju)庫(ku)服(fu)務(wu)器(qi)由原來(lai)的(de)6臺(tai)減少到(dao)目前的(de)3個(ge)節點(dian)集群(qun)。

最后來個小廣告

 ;是一個基于Electron構建的(de)，針對時序數(shu)據庫(ku)TDengine的(de)圖形化管理工具(ju)。具(ju)有(you)跨平(ping)臺、易于使用(yong)、版本適應性強(qiang)等特點。(gitee地址：)

TD-Workbench是本人利用周末的(de)(de)時間(jian)，參考開源社(she)區(qu)部分(fen)優秀代碼(ma)設計(ji)并(bing)實(shi)現的(de)(de)，目前(qian)已(yi)經開源。 這個僅代表(biao)我本人的(de)(de)業(ye)余好愛，與公司或某(mou)個組織(zhi)無關，歡迎大(da)家去star/fork。由于(yu)TDengine官方并(bing)未提供客戶端GUI工(gong)具，社(she)區(qu)目前(qian)能找到的(de)(de)兩款(kuan)工(gong)具都不是很完善(shan)。本工(gong)具是在基礎上改造而(er)來，部分(fen)源碼(ma)來自此(ci)處。

作者介紹：

寧龍(long)，碼(ma)云昵稱【村口(kou)的大爺】，目(mu)前就職于華自科技(ji)。后(hou)端程序猿(yuan)一(yi)(yi)個，混跡Java界十(shi)余年，就愛寫點代碼(ma)。一(yi)(yi)杯茶一(yi)(yi)首(shou)歌，一(yi)(yi)個參數秀一(yi)(yi)天。