雙匯發(fā)展多個(gè)分廠的能源管控大數(shù)據(jù)系統(tǒng)主要采用兩種技術(shù)棧：InfluxDB/Redis和Kafka/Redis/HBase/Flink，對(duì)于中小型研發(fā)團(tuán)隊(duì)來(lái)講，無(wú)論是系統(tǒng)搭建，還是實(shí)施運(yùn)維都非常棘手。經(jīng)過(guò)對(duì)InfluxDB/Redis和TDengine大數(shù)據(jù)平臺(tái)的功能和性能對(duì)比測(cè)試，最終將TDengine作為實(shí)施方案。

1. 項(xiàng)目背景

基于雙匯發(fā)展對(duì)能源管控的需求，利用云平臺(tái)技術(shù)以及電氣自動(dòng)化處理手段，對(duì)雙匯發(fā)展的一級(jí)、二級(jí)、三級(jí)能源儀表進(jìn)行整體改造，實(shí)現(xiàn)儀表組網(wǎng)，進(jìn)一步通過(guò)邊緣網(wǎng)關(guān)進(jìn)行能源在線監(jiān)測(cè)數(shù)據(jù)的采集，并上報(bào)至云平臺(tái)，建立統(tǒng)一能源管理信息化系統(tǒng)，實(shí)現(xiàn)能源的實(shí)時(shí)監(jiān)控、報(bào)表統(tǒng)計(jì)、能源流向分析與預(yù)測(cè)，降低企業(yè)單位產(chǎn)品能源消耗，提高經(jīng)濟(jì)效益，最終實(shí)現(xiàn)企業(yè)能源精細(xì)化管理。

2. 總體架構(gòu)

能源管控平臺(tái)基于私有云構(gòu)建，包括完整的IaaS層、PaaS層和SaaS層，而能源采集系統(tǒng)作為管控平臺(tái)中最為重要的一環(huán)，采用TDengine作為核心數(shù)據(jù)引擎，通過(guò)Restful接口進(jìn)行儀表在線數(shù)據(jù)插入，并實(shí)現(xiàn)大規(guī)模時(shí)序數(shù)據(jù)的高效穩(wěn)定存儲(chǔ)，同時(shí)，也為能源管控應(yīng)用層提供實(shí)時(shí)數(shù)據(jù)查詢(xún)、歷史聚合統(tǒng)計(jì)、流計(jì)算和訂閱服務(wù)等功能，實(shí)現(xiàn)能源地圖監(jiān)控、能耗預(yù)警、能源流向預(yù)測(cè)和能源互聯(lián)綜合決策，具體架構(gòu)如下圖所示。

圖1 能源采集系統(tǒng)架構(gòu)

3. TDengine關(guān)鍵應(yīng)用

3.1 Connector選擇

本項(xiàng)目數(shù)據(jù)采集最關(guān)鍵的環(huán)節(jié)，就是將訂閱到的MQTT數(shù)據(jù)插入到TDengine中，于是也就涉及到了TDengine連接器的選擇，我們平時(shí)項(xiàng)目中java使用居多，而且JDBC的性能也相對(duì)較強(qiáng)，理論上，應(yīng)該選擇JDBC API，但最終選擇了RESTful Connector，主要考慮以下幾點(diǎn)：

1)簡(jiǎn)潔性

毫無(wú)疑問(wèn)，RESTful通用性最強(qiáng)，TDengine直接通過(guò)HTTP POST 請(qǐng)求BODY中包含的SQL語(yǔ)句來(lái)操作數(shù)據(jù)庫(kù)，而且TDengine本身作為時(shí)序數(shù)據(jù)庫(kù)并不提供存儲(chǔ)過(guò)程或者事務(wù)機(jī)制，基本上都是每次執(zhí)行單條SQL語(yǔ)句，所以RESTful在使用上很簡(jiǎn)便。

2)可移植性

本項(xiàng)目的Java應(yīng)用都是部署在Kubernetes中，所以向TDengine插入數(shù)據(jù)的Java應(yīng)用需要容器化部署，而之前了解到，JDBC需要依賴(lài)的本地函數(shù)庫(kù)libtaos.so文件，所以容器化部署可能較為麻煩，而RESTful僅需采用OKHttp庫(kù)即可實(shí)現(xiàn)，移植性較強(qiáng)。

3)數(shù)據(jù)規(guī)模

本項(xiàng)目數(shù)采規(guī)模不大，大約每分鐘7000條數(shù)據(jù)，甚至后續(xù)數(shù)采功能擴(kuò)展到其他分廠，RESTful也完全滿(mǎn)足性能要求。

但總體來(lái)講，JDBC是在插入與查詢(xún)性能上具有一定優(yōu)勢(shì)的，而且支持從firstEp和secondEp選擇有效節(jié)點(diǎn)進(jìn)行連接(類(lèi)似于Nginx的keepalive高可用)，目前TDengine版本發(fā)布情況上看，JDBC的維護(hù)與提升也是重中之重，后續(xù)項(xiàng)目也可能會(huì)向JDBC遷移。

3.2 RESTful代碼實(shí)現(xiàn)

1)ThreadPoolExecutor線程池

訂閱EMQX和RESTful插入TDengine的代碼寫(xiě)在了同一個(gè)java服務(wù)中，每接收到一條MQTT訂閱消息，便開(kāi)啟一個(gè)線程向TDengine插入數(shù)據(jù)，線程均來(lái)自于線程池，初始化如下：

ExecutorService pool = new ThreadPoolExecutor(150, 300, 1000, TimeUnit.MILLISECONDS, new ArrayBlockingQueue(100), Executors.defaultThreadFactory(),new ThreadPoolExecutor.DiscardOldestPolicy());

線程池采用基于數(shù)組的先進(jìn)先出隊(duì)列，采用丟棄早期任務(wù)的拒絕策略，因?yàn)楸敬螆?chǎng)景中單次RESTful插入數(shù)據(jù)量大約在100~200條，執(zhí)行速度快，遲遲未執(zhí)行完極可能是SQL語(yǔ)句異常或連接taosd服務(wù)異常等原因，應(yīng)該丟棄任務(wù)。核心線程數(shù)設(shè)為150，相對(duì)較高，主要為了保證高峰抗壓能力。

2)OKHttp線程池

在每個(gè)ThreadPoolExecutor線程中，基于OKHttp庫(kù)進(jìn)行RESTful插入操作，也是采用ConnectionPool管理 HTTP 和 HTTP/2 連接的重用，以減少網(wǎng)絡(luò)延遲，OKHttp重點(diǎn)配置如下：

public ConnectionPool pool() { return new ConnectionPool(20, 5, TimeUnit.MINUTES);}

即最大空閑連接數(shù)為20，每個(gè)連接最大空閑時(shí)間為5分鐘，每個(gè)OKHttp插入操作采用異步調(diào)用方式，主要代碼如下：

public void excuteTdengineWithSqlAsync(String sql,Callback callback) { try{ okhttp3.MediaType mediaType = okhttp3.MediaType.parse("application/octet-stream"); RequestBody body = RequestBody.create(mediaType, sql); Request request = new Request.Builder() .url(tdengineHost) .post(body) .addHeader("Authorization", "Basic cm9vdDp0YW9zZGF0YQ==") .addHeader("cache-control", "no-cache") .build(); mOkHttpClient.newCall(request).enqueue(callback); } catch (Exception e) { logger.error("執(zhí)行tdengine操作報(bào)錯(cuò):"+ e.getMessage()); }}

3)Java打包鏡像

長(zhǎng)期壓力測(cè)試顯示，每秒執(zhí)行200次RESTful插入請(qǐng)求，單次請(qǐng)求包含100條數(shù)據(jù)，每條數(shù)據(jù)包含5組標(biāo)簽，Java服務(wù)內(nèi)存穩(wěn)定在300M~600M。而且上述模擬規(guī)模僅針對(duì)單個(gè)Java應(yīng)用而言，在Kubernetes可以跑多個(gè)這樣pod來(lái)消費(fèi)不同的MQTT主題，所以并發(fā)能力完全夠用。打包鏡像時(shí)，堆內(nèi)存最大值設(shè)為1024MB，主要語(yǔ)句為：

ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-XX:MaxRAM=2000m","-Xms1024m","-jar","/app.jar"]

3.3 性能測(cè)試

1)RESTful插入性能

按照3.2小節(jié)中的RESTful代碼進(jìn)行數(shù)據(jù)插入，Java程序和TDengine集群均運(yùn)行在私有云中，虛擬機(jī)之間配備萬(wàn)兆光纖交換機(jī)，Java程序具體如3.2小節(jié)所示，TDengine集群部署在3個(gè)虛擬機(jī)中，配置均為1TB硬盤(pán)、12核、12GB(私有云中CPU比較充裕，但內(nèi)存比較緊張)，經(jīng)過(guò)大約三周的生產(chǎn)環(huán)境運(yùn)行，性能總結(jié)如下：

表1 生產(chǎn)環(huán)境下RESTful插入性能測(cè)試

生產(chǎn)環(huán)境下，單條插入性能極高，完全滿(mǎn)足需求，當(dāng)然前期也進(jìn)行過(guò)稍大規(guī)模的插入場(chǎng)景模擬，主要是基于2.0.4.0以后的版本，注意到2.0.4.0之前的TDengine版本RESTful的SQL語(yǔ)句上限為64KB。模擬環(huán)境下，RESTful插入性能非常優(yōu)秀，具體如下表所示。

表2 模擬環(huán)境下RESTful插入性能測(cè)試

2)RESTful查詢(xún)性能

使用RESTful進(jìn)行SQL查詢(xún)時(shí)，性能也是非常好，目前真實(shí)生產(chǎn)環(huán)境中，數(shù)據(jù)總量為800萬(wàn)，相對(duì)單薄，所以查詢(xún)性能測(cè)試在模擬環(huán)境下進(jìn)行，在8億數(shù)據(jù)量下，LAST_ROW函數(shù)可以達(dá)到10ms響應(yīng)速度，count、interval、group by等相關(guān)函數(shù)執(zhí)行速度均在百毫秒量級(jí)上。

3.4 實(shí)施方案

本項(xiàng)目針對(duì)雙匯發(fā)展下屬的6個(gè)分廠(后續(xù)會(huì)繼續(xù)擴(kuò)充)進(jìn)行能源數(shù)據(jù)采集，大約1200多塊儀表(后續(xù)會(huì)繼續(xù)擴(kuò)充)，每塊儀表包括3至5個(gè)采集標(biāo)簽，采集頻率均為1分鐘，數(shù)據(jù)接入規(guī)模不大。六個(gè)廠各自有獨(dú)立的租戶(hù)空間，為了方便各自的時(shí)序數(shù)據(jù)庫(kù)管理，同時(shí)也方便各廠間的聚合查詢(xún)(目前六個(gè)分廠均從屬雙匯發(fā)展總部)，所以各分廠分別建立超級(jí)表，每個(gè)超級(jí)表包括4個(gè)tag，分別為廠編號(hào)、儀表級(jí)別、所屬工序和儀表編號(hào)，具體超級(jí)表建表情況如下圖所示。

主要用到的集群包括TDengine集群、EMQX集群和Redis集群，其中Redis集群在數(shù)據(jù)采集方面，僅僅用于緩存儀表連接狀態(tài)，其重點(diǎn)在于緩存業(yè)務(wù)系統(tǒng)數(shù)據(jù)；EMQX集群用于支撐MQTT數(shù)據(jù)的發(fā)布與訂閱，部署在Kubernetes中，可以實(shí)現(xiàn)資源靈活擴(kuò)展；TDengine集群部署在IaaS虛擬機(jī)中，支持大規(guī)模時(shí)序數(shù)據(jù)的存儲(chǔ)與查詢(xún)。

表3 集群配置信息

按照TDengine官方的建議，“一個(gè)數(shù)據(jù)采集點(diǎn)一張表，同一類(lèi)型數(shù)據(jù)采集點(diǎn)一張超級(jí)表”，我針對(duì)不同分廠的水表、電表、蒸汽表和燃?xì)獗矸謩e建立的超級(jí)表，每個(gè)儀表單獨(dú)建表，保證每張表的時(shí)間戳嚴(yán)格遞增。在實(shí)踐TDengine的過(guò)程中，重點(diǎn)體會(huì)如下：

1)集群搭建門(mén)檻低

TDengine集群安裝部署非常便捷，尤其相比于其他集群，僅需要簡(jiǎn)單的配置就可以實(shí)現(xiàn)生產(chǎn)環(huán)境級(jí)的搭建，官方文檔也比較豐富，社區(qū)活躍，也大為降低了后續(xù)運(yùn)維成本。

2)插入與查詢(xún)效率極高

TDengine的插入與查詢(xún)性能極高，這點(diǎn)在實(shí)際運(yùn)行時(shí)也深有感觸，用last_row函數(shù)查詢(xún)儀表最新數(shù)據(jù)，基本上可以達(dá)到毫秒級(jí)，在幾十億級(jí)的數(shù)據(jù)上進(jìn)行聚合查詢(xún)操作，也可達(dá)到百毫秒級(jí)，極大提供了系統(tǒng)的響應(yīng)速度。

3)全棧式時(shí)序處理引擎

在未使用TDengine之前，我們主要采用InfluxDB/Redis和Kafka/Redis/HBase/Flink兩種技術(shù)棧，對(duì)于我們中小型研發(fā)團(tuán)隊(duì)來(lái)講，無(wú)論是系統(tǒng)搭建，還是實(shí)施運(yùn)維都非常棘手。但是使用TDengine后，一切都簡(jiǎn)化了，TDengine將數(shù)據(jù)庫(kù)、消息隊(duì)列、緩存、流式計(jì)算等功能融合一起，以一種全棧的方式，為我們的大數(shù)據(jù)系統(tǒng)帶來(lái)了便捷。技術(shù)方案的對(duì)比如表4所示。

注：方案一為InfluxDB/Redis，方案二為Kafka/Redis/HBase/Flink，方案三為T(mén)Dengine

表4 數(shù)據(jù)采集方案對(duì)比

從表4的對(duì)比方案中可以看出，TDengine(方案三)是有著很大的優(yōu)勢(shì)，尤其在開(kāi)源EMQX Broker的支持上也非常好(主要依賴(lài)于Restful接口)，其他的例如Kafka和InfluxDB只能和企業(yè)版EMQX集成；在數(shù)據(jù)插入和查詢(xún)效率方面，上述三種方案關(guān)鍵在于TDengine、HBase和InfluxDB的對(duì)比，官網(wǎng)有非常詳細(xì)的測(cè)試報(bào)告，TDengine也是有絕對(duì)優(yōu)勢(shì)，這里就不過(guò)多敘述。所以選擇TDengine是勢(shì)在必行的。

3.5 技術(shù)期望

在時(shí)序數(shù)據(jù)庫(kù)性能方面，TDengine有著很大的優(yōu)勢(shì)，并且也集成了消息訂閱和流計(jì)算功能，可以說(shuō)在中小型物聯(lián)場(chǎng)景下，是無(wú)需部署Kafka和Flink的。當(dāng)然個(gè)人理解TDengine不是為了完全取代Kafka和Flink而生的，尤其是在大型云服務(wù)項(xiàng)目中，更多是共存。

但是在邊緣端，TDengine憑借著極低的資源占用率和優(yōu)秀的時(shí)序處理性能，將會(huì)產(chǎn)生更大的能量，期望能徹底集成邊緣流計(jì)算和MQTT broker等功能，擴(kuò)充Modbus、OPC-UA等常見(jiàn)工業(yè)協(xié)議支持，向下連接工業(yè)設(shè)備或者物聯(lián)設(shè)施，向上和邊緣Kubernetes生態(tài)(如KubeEdge、K3S等)協(xié)同，或者直接和云中心協(xié)同。

3.6 系統(tǒng)運(yùn)行界面

項(xiàng)目重點(diǎn)是能耗統(tǒng)計(jì)，而在線采集到TDengine里的數(shù)據(jù)都是累計(jì)量，所以在計(jì)算能耗時(shí)，需要在不同的超級(jí)表執(zhí)行按表分組、按時(shí)間周期采樣的查詢(xún)，類(lèi)似下面語(yǔ)法：

select last(累計(jì)列) as max_val,first(累計(jì)列) as min_val from [超級(jí)表名] where [標(biāo)簽欄相關(guān)過(guò)濾] and ts>=now-10h INTERVAL(1h) group by [儀表編號(hào)] ;

得益于TDengine的極佳性能，基本能保證不超過(guò)百毫秒的訪問(wèn)延時(shí)，下面是一些相關(guān)的PC端、移動(dòng)端界面(我們移動(dòng)端是用H5做的，為了直接能跑在Android和iOS上)。

寫(xiě)在最后

其實(shí)從2019年開(kāi)始就一直在關(guān)注TDengine，也看了很多陶總的演講，受益匪淺，尤其在今年8月份，TDengine進(jìn)行了集群版開(kāi)源，也正好準(zhǔn)備啟動(dòng)能源數(shù)據(jù)采集項(xiàng)目，所以果斷采用TDengine作為核心時(shí)序引擎，目前也是收獲了非常的效果。本次項(xiàng)目實(shí)施過(guò)程中，尤其感謝濤思數(shù)據(jù)的蘇曉慰工程師，多次協(xié)助解決TDengine相關(guān)的實(shí)施問(wèn)題。計(jì)劃在后續(xù)其他項(xiàng)目也也會(huì)繼續(xù)推廣TDengine，同時(shí)也愿意為一些商業(yè)版功能付費(fèi)，支持國(guó)產(chǎn)，支持濤思。

作者介紹于淼，學(xué)歷碩士，副研究員，主要從事MES系統(tǒng)研發(fā)以及智能制造相關(guān)理論和標(biāo)準(zhǔn)研究，主要研究方向：數(shù)字工廠使能技術(shù)、制造執(zhí)行系統(tǒng)關(guān)鍵技術(shù)和智能制造標(biāo)準(zhǔn)體系等，參與國(guó)家級(jí)項(xiàng)目及企業(yè)項(xiàng)目十余項(xiàng)，包括國(guó)家重點(diǎn)研發(fā)計(jì)劃以及國(guó)家智能制造專(zhuān)項(xiàng)等。

總結(jié)

以上是生活随笔為你收集整理的influxdb无法实现关联表_双汇：从棘手的InfluxDB+Redis到TDengine的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。