小 T 導(dǎo)讀：在歐圣達(dá)的物聯(lián)網(wǎng)智能設(shè)備平臺項目中，需支持?jǐn)?shù)百萬以上物聯(lián)網(wǎng)表具和智能終端的接入管理，支持分布式部署且具備良好擴展性。在規(guī)則引擎場景下，TDengine Database 提供了很好的查詢和存儲性能，成為本項目實現(xiàn)實時告警和監(jiān)控服務(wù)的重要一環(huán)。本篇文章分享了歐圣達(dá)在數(shù)據(jù)庫調(diào)研和搭建階段的思考和經(jīng)驗，供參考。

公司簡介

哈工歐圣達(dá)是深圳市歐圣達(dá)科技有限公司和哈工大機器人集團的合資公司，總公司深圳市歐圣達(dá)科技有限公司成立于 2010 年 5 月，總部位于深圳，下設(shè)合肥研發(fā)中心、華東分公司（合肥）和西南分公司（成都）。公司始終致力于燃?xì)?、供熱等公共事業(yè)領(lǐng)域的智慧化解決方案研發(fā)和應(yīng)用推廣，擁有超過 10 余項自主知識產(chǎn)權(quán)的、基于 5G/NB-IoT 和大數(shù)據(jù)的“一體化平臺+智能安全終端”智慧燃?xì)饨鉀Q方案，作為核心成員參與制定并發(fā)布 2019、2020 年 5G 智慧燃?xì)庑袠I(yè)標(biāo)準(zhǔn)。

某燃?xì)夤緮M建設(shè)一套物聯(lián)網(wǎng)智能設(shè)備平臺來滿足各類物聯(lián)網(wǎng)設(shè)備接入以及數(shù)據(jù)的采集、存儲、分析、展示等各類需求，項目需包括數(shù)據(jù)采集模塊、數(shù)據(jù)分析模塊、監(jiān)控告警模塊、預(yù)付費實時結(jié)算模塊、API 接口模塊、大屏\地圖顯示模塊、后臺管理模塊、手機 App 功能模塊。

該平臺的搭建目的是為了取代各燃?xì)獗韽S原有的數(shù)據(jù)接收服務(wù)器，實現(xiàn)對各表廠物聯(lián)網(wǎng)表具（含 FSK、GFSK、LoRa、GPRS、4G、5G、NB-IoT 等技術(shù)標(biāo)準(zhǔn)）讀數(shù)、壓力、溫度、監(jiān)控報警、氣價調(diào)整、系統(tǒng)參數(shù)設(shè)置等遠(yuǎn)傳控制和管理。系統(tǒng)需支持?jǐn)?shù)百萬以上物聯(lián)網(wǎng)表具和智能終端的接入管理， 1 秒內(nèi)瞬時并發(fā)連接數(shù)不低于 5 萬，系統(tǒng)支持分布式部署，且具備良好的擴展性，能夠根據(jù)業(yè)務(wù)需要，靈活的擴展系統(tǒng)性能和接入能力。

一、選型調(diào)研

以上是典型的時序物聯(lián)網(wǎng)場景，因此我們調(diào)研了國外的主流時序數(shù)據(jù)庫 InfluxDB，但考慮到國家基礎(chǔ)設(shè)施建設(shè)安全，我們最終把目光投向了國產(chǎn)開源數(shù)據(jù)庫 TDengine。我們結(jié)合業(yè)務(wù)數(shù)據(jù)量對 TDengine 進(jìn)行了數(shù)百萬設(shè)備的壓測，滿足本項目的數(shù)據(jù)存儲和性能要求。具體測試結(jié)果如下：

從測試結(jié)果來看，TDengine 的整體硬件消耗資源比較低，且能滿足數(shù)百萬設(shè)備的并發(fā)寫入。此外相比 MongoDB，其壓縮率可以提升至 1/10 – 1/20，也為我們節(jié)約了大量存儲成本。最有吸引力的一點是 TDengine 具有完善的開源社區(qū)生態(tài)，不僅支持集群版部署，更有完善的中國服務(wù)團隊及多元化的服務(wù)模式，可以做到實時響應(yīng)。

二、業(yè)務(wù)架構(gòu)部署

在具體搭建上，我們將不同廠家、不同型號設(shè)備定義為產(chǎn)品，不同產(chǎn)品的通信機制、上報數(shù)據(jù)項、指令內(nèi)容、上報頻次都是不同的，我們使用 TDengine 對不同產(chǎn)品創(chuàng)建對應(yīng)的超級表，使用設(shè)備 ID 創(chuàng)建子表。

• 技術(shù)架構(gòu)圖如下圖所示：

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

• 建模思路

在本項目中，每種設(shè)備的協(xié)議及上報數(shù)據(jù)參數(shù)都是不同的，我們將公共屬性（如所屬公司、所屬分公司、所屬廠家、是否預(yù)付費等）作為超級表 tags，將共有參數(shù)（如閥門狀態(tài)、最新讀數(shù)、抄表時間、溫度、壓力、電量、信號強度等）作為普通列，通信時間戳+時間漂移作為 TDengine 主鍵，其他非共有參數(shù)（如一些設(shè)備會上報瞬時工況流量、一些會上報抄表模塊電池電量等）作為子表字段。以本項目的其中一張表作為示例，結(jié)構(gòu)如下：

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 節(jié)點 8 核 16 G 滿足整體業(yè)務(wù)需求，系統(tǒng)可以根據(jù)時間段范圍、針對單個設(shè)備進(jìn)行數(shù)據(jù)上報的查詢功能，且支持按照小時用量、日用量、月用量、年用量四個維度進(jìn)行統(tǒng)計分析。目前單個超級表的壓縮率為 2.5%。

三、經(jīng)驗分享與未來規(guī)劃

在我們使用 TDengine 的過程中，也遇到了一些小問題，在本文中總結(jié)出了一些經(jīng)驗，分享如下：

• 查詢結(jié)果字段名的特殊寫法

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

• 及時更新版本

在前期使用過程中，我們曾經(jīng)遇到過 DROP TABLE 就崩潰的 BUG。和官方溝通后發(fā)現(xiàn)，已經(jīng)在很早的版本上修復(fù)了，建議各位遇到 TDengine 的新版本也及時更新。

• USING 語法

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

• 調(diào)整分片策略

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

• 寫入內(nèi)存 blocks 很重要

在寫入過程中，官方的巡檢發(fā)現(xiàn)數(shù)據(jù)寫入的“碎片化”很嚴(yán)重。經(jīng)過排查發(fā)現(xiàn)，分配給寫入過程的內(nèi)存太?。╞lock 默認(rèn) 6，意味著 1 個 Vnode 只有 96 MB 用于寫入）。由于 TDengine 在寫入原理上是依賴于內(nèi)存來做局部排序的，因此內(nèi)存小了就會頻頻觸發(fā)落盤，從而導(dǎo)致數(shù)據(jù)的落盤區(qū)塊的平均條數(shù)很小，需要頻繁 IO 來讀取數(shù)據(jù)。基于此，各位盡量設(shè)置較大的 block 來避免這個問題。

• 未來規(guī)劃

物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等涉及時序數(shù)據(jù)存儲、分析的場景，使用 TDengine Database 可以大大降低系統(tǒng)架構(gòu)復(fù)雜度，在提升性能和開發(fā)效率的同時還能夠降低學(xué)習(xí)和運維成本。之后我們也會結(jié)合業(yè)務(wù)需求在項目中充分發(fā)揮 TDengine 的優(yōu)勢，利用其來長期存儲設(shè)備上報的有效讀數(shù)數(shù)據(jù)，以及進(jìn)行計費、抄表、用量統(tǒng)計分析。