小 T 導讀：在(zai)歐圣達的物聯(lian)網智能設(she)備平臺項(xiang)目(mu)中，需支持(chi)數百萬以上物聯(lian)網表具和(he)智能終端的接(jie)入管理，支持(chi)分(fen)布式部署且具備良好(hao)擴展性。在(zai)規則引(yin)擎(qing)場景下，TDengine Database 提(ti)供(gong)(gong)了很(hen)好(hao)的查(cha)詢和(he)存儲性能，成為本(ben)項(xiang)目(mu)實(shi)現實(shi)時告警和(he)監控服(fu)務的重要一環。本(ben)篇文(wen)章分(fen)享了歐圣達在(zai)數據庫調研和(he)搭(da)建(jian)階(jie)段(duan)的思考和(he)經(jing)驗，供(gong)(gong)參考。

公司簡介

哈工(gong)歐圣達(da)是深圳市(shi)歐圣達(da)科技有限公(gong)(gong)司(si)(si)和(he)哈工(gong)大機器人(ren)集團(tuan)的(de)合(he)資公(gong)(gong)司(si)(si)，總公(gong)(gong)司(si)(si)深圳市(shi)歐圣達(da)科技有限公(gong)(gong)司(si)(si)成立于(yu) 2010 年(nian) 5 月(yue)，總部位于(yu)深圳，下設合(he)肥研(yan)發中心、華東分(fen)公(gong)(gong)司(si)(si)（合(he)肥）和(he)西南分(fen)公(gong)(gong)司(si)(si)（成都(dou)）。公(gong)(gong)司(si)(si)始終致力(li)于(yu)燃氣、供(gong)熱(re)等公(gong)(gong)共事業(ye)領域的(de)智(zhi)慧化解(jie)決(jue)方案研(yan)發和(he)應用推廣(guang)，擁(yong)有超過(guo) 10 余項(xiang)自(zi)主知(zhi)識產權的(de)、基(ji)于(yu) 5G/NB-IoT 和(he)大數據的(de)“一體化平(ping)臺+智(zhi)能安(an)全終端”智(zhi)慧燃氣解(jie)決(jue)方案，作為核心成員參(can)與制定并發布(bu) 2019、2020 年(nian) 5G 智(zhi)慧燃氣行業(ye)標準。

某燃氣公(gong)司擬建設一套物(wu)聯網(wang)智(zhi)能(neng)設備(bei)平臺來(lai)滿足各(ge)類物(wu)聯網(wang)設備(bei)接入以及數據(ju)的采集、存儲、分析(xi)、展(zhan)示等各(ge)類需求，項(xiang)目需包(bao)括數據(ju)采集模(mo)(mo)塊(kuai)(kuai)、數據(ju)分析(xi)模(mo)(mo)塊(kuai)(kuai)、監控告警模(mo)(mo)塊(kuai)(kuai)、預付費實(shi)時(shi)結(jie)算(suan)模(mo)(mo)塊(kuai)(kuai)、API 接口模(mo)(mo)塊(kuai)(kuai)、大屏\地圖顯示模(mo)(mo)塊(kuai)(kuai)、后臺管(guan)理模(mo)(mo)塊(kuai)(kuai)、手機 App 功能(neng)模(mo)(mo)塊(kuai)(kuai)。

該平臺的搭建目的是(shi)為(wei)了取代(dai)各(ge)燃氣表廠原有(you)的數(shu)據接(jie)收服務器，實現對各(ge)表廠物(wu)聯(lian)(lian)網(wang)表具（含 FSK、GFSK、LoRa、GPRS、4G、5G、NB-IoT 等技術標準）讀數(shu)、壓力、溫度、監控報警、氣價調整、系(xi)統(tong)(tong)參(can)數(shu)設置等遠傳控制和(he)管理(li)。系(xi)統(tong)(tong)需(xu)支持數(shu)百萬以上物(wu)聯(lian)(lian)網(wang)表具和(he)智能終端的接(jie)入管理(li)， 1 秒內瞬時(shi)并發連接(jie)數(shu)不(bu)低于 5 萬，系(xi)統(tong)(tong)支持分布式(shi)部署，且具備良好(hao)的擴展(zhan)性(xing)，能夠根據業務需(xu)要(yao)，靈活的擴展(zhan)系(xi)統(tong)(tong)性(xing)能和(he)接(jie)入能力。

一、選型調研

以上是典型的時序物聯網場景，因此我們調研了國外的主流時序數據庫 InfluxDB，但考慮(lv)到(dao)國家基礎設施建設安(an)全，我們最終把目光(guang)投向了國產(chan)開(kai)源數據(ju)庫 TDengine。我們結合業務(wu)數據(ju)量對 TDengine 進行了數百萬設備的(de)壓測，滿(man)足本項目的(de)數據(ju)存儲和性能(neng)要(yao)求(qiu)。具體測試結果如下：

從測試結果來看，TDengine 的(de)(de)整體(ti)硬(ying)件消耗資源(yuan)比較低，且(qie)能滿足數(shu)百萬設備的(de)(de)并發寫入。此外相(xiang)比 MongoDB，其壓縮率可以提升(sheng)至 1/10 – 1/20，也為(wei)我(wo)們節約了大量存儲成本。最有吸引力的(de)(de)一(yi)點(dian)是 TDengine 具有完(wan)善的(de)(de)開源(yuan)社區生態(tai)，不(bu)僅(jin)支持集群版部署，更(geng)有完(wan)善的(de)(de)中國服(fu)務(wu)團隊(dui)及多元化的(de)(de)服(fu)務(wu)模式(shi)，可以做到實時(shi)響應。

二、業務架構部署

在具體搭建上，我(wo)(wo)們將不同廠家、不同型號設備定(ding)義為產(chan)品(pin)，不同產(chan)品(pin)的(de)(de)通信(xin)機制、上報數據項、指(zhi)令內容、上報頻(pin)次都是(shi)不同的(de)(de)，我(wo)(wo)們使用 TDengine 對(dui)不同產(chan)品(pin)創建對(dui)應的(de)(de)超級表，使用設備 ID 創建子表。

• 技術架構圖如下圖所示：

具體路徑上，傳感器數據經過 MQ 緩存、結構化解析后進入到 TDengine，供后續業務進行查詢使用。規則引擎根據已有的規則參數，進行傳感器數據訂閱，實時判斷傳感器是否觸發了報警規則，從而實現項目的實時監控和報警需求。同時，規則引擎還會根據傳感器數據，觸發對應的指令操作（如恢復服務、暫停服務指令），通過 MQ 異步傳達給傳感器。TDengine 在規則引擎場景下，提供了很好的查詢性能，是實現實時告警和監控服務的重要一環。

• 建模思路

在(zai)本項目中，每種設備的(de)協議(yi)及上報數(shu)(shu)據參數(shu)(shu)都是(shi)不同的(de)，我們將公共(gong)屬性(xing)（如(ru)(ru)所(suo)(suo)屬公司(si)、所(suo)(suo)屬分公司(si)、所(suo)(suo)屬廠家(jia)、是(shi)否(fou)預付費等）作為超級表(biao)(biao) tags，將共(gong)有(you)參數(shu)(shu)（如(ru)(ru)閥門狀態、最新讀數(shu)(shu)、抄表(biao)(biao)時間(jian)、溫(wen)度(du)、壓力、電(dian)(dian)量、信號強度(du)等）作為普(pu)通(tong)(tong)列(lie)，通(tong)(tong)信時間(jian)戳+時間(jian)漂移作為 TDengine 主鍵(jian)，其他非共(gong)有(you)參數(shu)(shu)（如(ru)(ru)一些設備會上報瞬時工況流量、一些會上報抄表(biao)(biao)模塊(kuai)電(dian)(dian)池電(dian)(dian)量等）作為子(zi)表(biao)(biao)字段。以(yi)本項目的(de)其中一張表(biao)(biao)作為示(shi)例，結構如(ru)(ru)下：

show create stable device_meter_record\G;
create table device_meter_record (receive_time TIMESTAMP,meter_readnum DOUBLE,meter_balance INT,meter_volume DOUBLE,meter_time TIMESTAMP,meter_temperature DOUBLE,meter_pressure DOUBLE,meter_instantflow DOUBLE,cust_num BINARY(50),cust_name BINARY(255),company_id BINARY(32),subcompany_id BINARY(32),readingteam_id BINARY(32),subreadingteam_id BINARY(32),area_id BINARY(32),community_id BINARY(32),building_id BINARY(32),user_type BINARY(20),is_holiday BOOL,supplier_id BINARY(32),supplier_device_code BINARY(20),platform_balance INT,platform_last_reading DOUBLE,platform_last_balance INT,platform_price BINARY(15)) TAGS (device_id BINARY(32),device_no BINARY(32),sno BINARY(32),model_id BINARY(32),type_id BINARY(100))

• 效果展示

最終我們采用了 3 節點 8 核 16 G 滿足整體業務需求，系統可以根據時間段范圍、針對單個設備進行數據上報的查詢功能，且支持按照小時用量、日用量、月用量、年用量四個維度進行統計分析。目前單個超級表的壓縮率為 2.5%。

三、經驗分享與未來規劃

在我們使(shi)用 TDengine 的過(guo)程中，也(ye)遇到了(le)一些小問題(ti)，在本(ben)文(wen)中總(zong)結出了(le)一些經驗，分享如下(xia)：

• 查詢結果字段名的特殊寫法

TDengine 的此前版本的設計當中，在查詢返回的字段名時使用的是特殊寫法：例如SELECT last_row(ts) FROM stb GROUP BY tbname，這(zhe)樣的設計會(hui)導致 MyBatis 等 ORM 框架(jia)在(zai)映射時無法(fa)直接對上。這(zhe)種(zhong)情況下(xia)只需要(yao)將 keepColumnName 設置為 1，就可(ke)以(yi)避免。

• 及時更新版本

在前期使用過程(cheng)中(zhong)，我(wo)們(men)曾(ceng)經遇(yu)到過 DROP TABLE 就(jiu)崩潰(kui)的 BUG。和官方溝通后發現，已(yi)經在很早(zao)的版本上修復了，建議各(ge)位遇(yu)到 TDengine 的新版本也及時更(geng)新。

• USING 語法

在使用 INSERT INTO table USING stable TAGS() 的(de)語(yu)法時，一(yi)直以為這(zhe)里會對 tag 進行重新賦值。到了使用的(de)時候才發現，原來 table 已經(jing)存在的(de)情況下，是不會對 tag 發生修改的(de)。細思一(yi)下絕對的(de)也是合理的(de)，因為畢竟多(duo)一(yi)次(ci)修改就(jiu)會多(duo)一(yi)次(ci)性能消耗,如果跟著 insert 來修改，就(jiu)會多(duo)了 1 : 1 的(de)修改操作。

• 調整分片策略

在前期寫入過程中，發現 CPU 占用只能到 1 核，CPU 資源上不去。和官方溝通后發現，原來默認的分片策略，在小規模設備上只會創建幾個 Vnode，因此并不能很好地把全部核數利用起來。官方告知可以通過這兩個參數來調整分片策略： tableIncStepPerVnode 50minTablesPerVnode 50 前者(zhe)(zhe)決定的(de)是何時采用下(xia)一個 Vnode 來(lai)存(cun)放(fang)新(xin)的(de) table，后者(zhe)(zhe)決定的(de)是何時創建下(xia)一個 Vnode 來(lai)存(cun)放(fang)新(xin)的(de) table。

• 寫入內存 blocks 很重要

在寫(xie)入(ru)過(guo)程中，官方的(de)(de)巡檢發現(xian)數(shu)據寫(xie)入(ru)的(de)(de)“碎(sui)片化(hua)”很嚴重。經過(guo)排查(cha)發現(xian)，分配(pei)給寫(xie)入(ru)過(guo)程的(de)(de)內(nei)存太小(xiao)（block 默(mo)認 6，意(yi)味著 1 個(ge) Vnode 只有 96 MB 用(yong)于(yu)寫(xie)入(ru)）。由于(yu) TDengine 在寫(xie)入(ru)原理上是依賴于(yu)內(nei)存來(lai)做(zuo)局部排序的(de)(de)，因此(ci)內(nei)存小(xiao)了就(jiu)會頻(pin)頻(pin)觸(chu)發落(luo)盤，從而導致數(shu)據的(de)(de)落(luo)盤區(qu)塊的(de)(de)平(ping)均條數(shu)很小(xiao)，需要頻(pin)繁 IO 來(lai)讀取數(shu)據。基于(yu)此(ci)，各位(wei)盡量設(she)置較大的(de)(de) block 來(lai)避免這個(ge)問(wen)題。

• 未來規劃

物聯網、車(che)聯網等涉及(ji)時序數(shu)據(ju)存(cun)儲、分析的(de)場(chang)景，使用 TDengine Database 可以(yi)大(da)大(da)降低(di)系(xi)統(tong)架構(gou)復雜度，在提(ti)升性(xing)能和開發效(xiao)率的(de)同時還能夠降低(di)學(xue)習(xi)和運維成本。之(zhi)后我們也會結合業務需求在項目中充分發揮(hui) TDengine 的(de)優勢，利用其來長期存(cun)儲設備上(shang)報的(de)有效(xiao)讀數(shu)數(shu)據(ju)，以(yi)及(ji)進行(xing)計(ji)費、抄表、用量統(tong)計(ji)分析。