雙(shuang)匯發(fa)展多個分(fen)廠的能(neng)源管(guan)控大數據系(xi)統(tong)主要采用兩(liang)種技術棧：InfluxDB/Redis和(he)Kafka/Redis/HBase/Flink，對于中(zhong)小型研發(fa)團隊來講(jiang)，無論是系(xi)統(tong)搭建，還(huan)是實施運維(wei)都(dou)非(fei)常棘手。經過對InfluxDB/Redis和(he)TDengine大數據平臺的功(gong)能(neng)和(he)性能(neng)對比測試，最終將TDengine作為實施方案。

1. 項目背景

基于(yu)雙匯發展對能(neng)源管(guan)控(kong)的需求(qiu)，利(li)用云平臺技術以及電(dian)氣自動化處理手段，對雙匯發展的一(yi)級、二級、三(san)級能(neng)源儀表進行整體改造，實(shi)(shi)(shi)現儀表組網，進一(yi)步通過邊緣網關(guan)進行能(neng)源在線監測數據的采集，并上報至云平臺，建(jian)立統一(yi)能(neng)源管(guan)理信息(xi)化系統，實(shi)(shi)(shi)現能(neng)源的實(shi)(shi)(shi)時監控(kong)、報表統計、能(neng)源流向分析與(yu)預(yu)測，降低企(qi)業單位產品能(neng)源消(xiao)耗，提高(gao)經濟效益，最終實(shi)(shi)(shi)現企(qi)業能(neng)源精細化管(guan)理。

2. 總體架構

能源(yuan)(yuan)管控平臺(tai)基于私(si)有云構建，包(bao)括完整的IaaS層、PaaS層和SaaS層，而能源(yuan)(yuan)采集系統(tong)作為管控平臺(tai)中最為重要的一(yi)環，采用TDengine作為核心數(shu)據(ju)引擎(qing)，通過Restful接口進行儀表在線數(shu)據(ju)插入，并實現(xian)大規模時序(xu)數(shu)據(ju)的高(gao)效穩(wen)定存(cun)儲(chu)，同時，也為能源(yuan)(yuan)管控應用層提(ti)供實時數(shu)據(ju)查詢、歷史(shi)聚合(he)統(tong)計(ji)、流計(ji)算和訂閱服(fu)務等功(gong)能，實現(xian)能源(yuan)(yuan)地(di)圖監控、能耗預警、能源(yuan)(yuan)流向(xiang)預測(ce)和能源(yuan)(yuan)互(hu)聯綜合(he)決策，具體架構如下圖所示。

3. TDengine關鍵應用

3.1 Connector選擇

本項目數據(ju)采集最(zui)(zui)關鍵的(de)環節，就(jiu)是將訂(ding)閱到的(de)MQTT數據(ju)插(cha)入到TDengine中，于是也就(jiu)涉及(ji)到了(le)(le)TDengine連接器的(de)選擇(ze)，我們(men)平時項目中java使用居(ju)多，而(er)且JDBC的(de)性能也相(xiang)對較強(qiang)，理論上，應該選擇(ze)JDBC API，但(dan)最(zui)(zui)終選擇(ze)了(le)(le)RESTful Connector，主要考慮以下幾(ji)點：

1）簡潔性

毫無疑問，RESTful通用性最強，TDengine直接通過HTTP POST 請求BODY中包含的SQL語句來操作數據庫，而且TDengine本身作為時序數據庫（Time-Series Database）并不提供存(cun)儲過(guo)程或者事務機制，基本上(shang)(shang)都是(shi)每次(ci)執行單條SQL語句，所以RESTful在使用上(shang)(shang)很簡(jian)便。

2）可移植性

本項目的Java應用(yong)都是部署在Kubernetes中，所(suo)以向TDengine插入數據的Java應用(yong)需要容器化部署，而之前了解到，JDBC需要依(yi)賴的本地函數庫(ku)libtaos.so文件，所(suo)以容器化部署可能較為麻煩，而RESTful僅(jin)需采(cai)用(yong)OKHttp庫(ku)即可實現，移植性(xing)較強。

3）數據規模

本項目(mu)數(shu)采規模不大，大約每分鐘(zhong)7000條數(shu)據，甚至后續數(shu)采功(gong)能(neng)擴展到其他分廠，RESTful也完全(quan)滿(man)足性能(neng)要求(qiu)。

但總體來(lai)講，JDBC是在(zai)插(cha)入與查詢(xun)性能上具(ju)有一(yi)定(ding)優(you)勢的，而(er)且支(zhi)持從firstEp和secondEp選擇有效節點進行連接（類似于Nginx的keepalive高可(ke)用），目前TDengine版本發布情況上看，JDBC的維(wei)護與提(ti)升也(ye)是重中之重，后(hou)續項目也(ye)可(ke)能會向JDBC遷移。

3.2 RESTful代碼實現

1）ThreadPoolExecutor線程池

訂(ding)閱EMQX和RESTful插(cha)(cha)入(ru)TDengine的代(dai)碼寫在了(le)同一個(ge)java服務(wu)中，每接收(shou)到一條MQTT訂(ding)閱消息，便開啟一個(ge)線(xian)(xian)程向TDengine插(cha)(cha)入(ru)數據，線(xian)(xian)程均來自(zi)于(yu)線(xian)(xian)程池，初始化如下：

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

線程池采(cai)用基于數組的(de)先(xian)進先(xian)出(chu)隊列，采(cai)用丟(diu)棄(qi)早期任務的(de)拒絕(jue)策略，因為本(ben)次場景(jing)中單次RESTful插(cha)入數據(ju)量大約在100~200條(tiao)，執(zhi)行速度快，遲遲未(wei)執(zhi)行完極可(ke)能是SQL語句異(yi)常或連接(jie)taosd服務異(yi)常等原因，應該丟(diu)棄(qi)任務。核(he)心線程數設為150，相對較高，主(zhu)要為了保證高峰抗壓能力。

2）OKHttp線(xian)程池

在每個ThreadPoolExecutor線程中，基于OKHttp庫進行RESTful插(cha)入(ru)操作，也是(shi)采用(yong)ConnectionPool管理 HTTP 和 HTTP/2 連(lian)接的重用(yong)，以減少網絡延(yan)遲(chi)，OKHttp重點(dian)配(pei)置(zhi)如下：

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

即最(zui)大空閑連接(jie)數為(wei)20，每個(ge)連接(jie)最(zui)大空閑時間為(wei)5分鐘(zhong)，每個(ge)OKHttp插入操作采用異步調(diao)用方(fang)式，主要代碼如(ru)下：

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("執行tdengine操作報錯:"+ e.getMessage());
    }
}

3）Java打包鏡像

長期壓力測試顯示，每(mei)秒(miao)執行200次RESTful插入請求，單次請求包含100條數(shu)據(ju)，每(mei)條數(shu)據(ju)包含5組(zu)標簽，Java服務內存(cun)穩(wen)定(ding)在(zai)300M~600M。而且上(shang)述模擬(ni)規模僅針對單個Java應(ying)用而言，在(zai)Kubernetes可以跑多個這樣pod來消(xiao)費不同的MQTT主題，所以并發能力完全(quan)夠用。打包鏡像時，堆內存(cun)最(zui)大值設為1024MB，主要語句為：

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

3.3 性能測試

1）RESTful插入(ru)性能

按照(zhao)3.2小(xiao)節中(zhong)的RESTful代碼進行(xing)數據插入，Java程序(xu)和TDengine集群均運(yun)行(xing)在私有(you)云(yun)中(zhong)，虛擬(ni)機(ji)之間配備萬兆光纖交換機(ji)，Java程序(xu)具體(ti)如(ru)3.2小(xiao)節所(suo)示，TDengine集群部署(shu)在3個虛擬(ni)機(ji)中(zhong)，配置(zhi)均為(wei)1TB硬(ying)盤、12核、12GB（私有(you)云(yun)中(zhong)CPU比較充裕，但內存比較緊張），經過大約三周的生產環境運(yun)行(xing)，性(xing)能總結(jie)如(ru)下：

生(sheng)產環(huan)境(jing)下，單條插入(ru)性(xing)能(neng)極高，完全(quan)滿(man)足需求(qiu)，當然(ran)前(qian)期(qi)也進(jin)行(xing)過稍大規(gui)模的(de)(de)插入(ru)場景模擬(ni)，主要(yao)是基(ji)于2.0.4.0以后的(de)(de)版本，注意到(dao)2.0.4.0之前(qian)的(de)(de)TDengine版本RESTful的(de)(de)SQL語(yu)句上限(xian)為64KB。模擬(ni)環(huan)境(jing)下，RESTful插入(ru)性(xing)能(neng)非常優秀(xiu)，具體(ti)如下表(biao)所示。

2）RESTful查(cha)詢性能

使用RESTful進(jin)行SQL查詢時，性能也是(shi)非常好，目前真實生產環(huan)境中(zhong)，數據總量(liang)為800萬，相(xiang)對單薄(bo)，所以查詢性能測試(shi)在模擬環(huan)境下(xia)進(jin)行，在8億數據量(liang)下(xia)，LAST_ROW函(han)(han)數可(ke)以達到10ms響應速度，count、interval、group by等(deng)相(xiang)關函(han)(han)數執行速度均在百毫(hao)秒量(liang)級(ji)上。

3.4 實施方案

本(ben)項(xiang)目針(zhen)對雙匯發(fa)展(zhan)下屬的(de)(de)6個(ge)分(fen)(fen)(fen)廠（后續(xu)(xu)會繼續(xu)(xu)擴(kuo)(kuo)充）進行能源數(shu)據采集，大約1200多塊儀(yi)表(biao)(biao)(biao)（后續(xu)(xu)會繼續(xu)(xu)擴(kuo)(kuo)充），每(mei)塊儀(yi)表(biao)(biao)(biao)包(bao)括3至5個(ge)采集標簽，采集頻率均(jun)為1分(fen)(fen)(fen)鐘(zhong)，數(shu)據接入規模(mo)不大。六(liu)個(ge)廠各(ge)自有獨立(li)(li)的(de)(de)租戶空間(jian)，為了方(fang)便(bian)各(ge)自的(de)(de)時序數(shu)據庫(ku)管理，同時也方(fang)便(bian)各(ge)廠間(jian)的(de)(de)聚合(he)查詢（目前(qian)六(liu)個(ge)分(fen)(fen)(fen)廠均(jun)從屬雙匯發(fa)展(zhan)總(zong)部(bu)），所(suo)以各(ge)分(fen)(fen)(fen)廠分(fen)(fen)(fen)別建立(li)(li)超(chao)級表(biao)(biao)(biao)，每(mei)個(ge)超(chao)級表(biao)(biao)(biao)包(bao)括4個(ge)tag，分(fen)(fen)(fen)別為廠編號、儀(yi)表(biao)(biao)(biao)級別、所(suo)屬工序和儀(yi)表(biao)(biao)(biao)編號，具體超(chao)級表(biao)(biao)(biao)建表(biao)(biao)(biao)情況(kuang)如下圖所(suo)示。

主要用(yong)到的(de)集(ji)(ji)(ji)群(qun)(qun)包括TDengine集(ji)(ji)(ji)群(qun)(qun)、EMQX集(ji)(ji)(ji)群(qun)(qun)和Redis集(ji)(ji)(ji)群(qun)(qun)，其(qi)中Redis集(ji)(ji)(ji)群(qun)(qun)在(zai)(zai)數據采集(ji)(ji)(ji)方面(mian)，僅(jin)僅(jin)用(yong)于(yu)緩存儀表連接狀態，其(qi)重點在(zai)(zai)于(yu)緩存業務系統(tong)數據；EMQX集(ji)(ji)(ji)群(qun)(qun)用(yong)于(yu)支撐(cheng)MQTT數據的(de)發布(bu)與訂(ding)閱，部(bu)署在(zai)(zai)Kubernetes中，可以實現資源靈(ling)活(huo)擴(kuo)展；TDengine集(ji)(ji)(ji)群(qun)(qun)部(bu)署在(zai)(zai)IaaS虛擬機中，支持大規模(mo)時序(xu)數據的(de)存儲與查詢(xun)。

按照TDengine官(guan)方的(de)建議(yi)，“一(yi)個數(shu)據采集(ji)點(dian)一(yi)張表(biao)，同一(yi)類型數(shu)據采集(ji)點(dian)一(yi)張超(chao)級(ji)表(biao)”，我針對不同分廠(chang)的(de)水表(biao)、電表(biao)、蒸汽(qi)表(biao)和(he)燃氣(qi)表(biao)分別(bie)建立(li)的(de)超(chao)級(ji)表(biao)，每個儀(yi)表(biao)單獨建表(biao)，保證(zheng)每張表(biao)的(de)時(shi)間(jian)戳嚴格(ge)遞(di)增。在實(shi)踐(jian)TDengine的(de)過程中，重(zhong)點(dian)體會(hui)如下(xia)：

1）集群搭建門檻低

TDengine集群安裝部署非常便捷，尤其相比于其他(ta)集群，僅需要簡單的配置就(jiu)可以實現生產環境級的搭建，官方文檔(dang)也比較豐富，社區活躍，也大為(wei)降低了后(hou)續運維成本(ben)。

2）插入與查詢效率(lv)極高

TDengine的插(cha)入(ru)與查(cha)詢(xun)性能極(ji)高，這點在實際運行時也深有感(gan)觸，用(yong)last_row函(han)數查(cha)詢(xun)儀表最新數據(ju)，基本(ben)上(shang)可(ke)以達(da)(da)到(dao)毫(hao)秒級(ji)(ji)，在幾十億級(ji)(ji)的數據(ju)上(shang)進行聚合(he)查(cha)詢(xun)操作，也可(ke)達(da)(da)到(dao)百(bai)毫(hao)秒級(ji)(ji)，極(ji)大提供了系(xi)統的響應速度(du)。

3）全棧式時序處理引擎

在(zai)未使用(yong)TDengine之(zhi)前，我們主要采用(yong)InfluxDB/Redis和Kafka/Redis/HBase/Flink兩種(zhong)技(ji)術棧(zhan)(zhan)，對于(yu)我們中小型研發團隊來(lai)講，無論是(shi)(shi)系(xi)統(tong)搭建，還是(shi)(shi)實施運(yun)維都非常棘手。但是(shi)(shi)使用(yong)TDengine后，一(yi)切都簡化了，TDengine將數(shu)據庫、消(xiao)息隊列、緩存、流式計算等(deng)功能融(rong)合一(yi)起，以一(yi)種(zhong)全(quan)棧(zhan)(zhan)的(de)方式，為(wei)我們的(de)大數(shu)據系(xi)統(tong)帶來(lai)了便捷。技(ji)術方案的(de)對比如表(biao)4所示。

注：方案(an)一(yi)為(wei)InfluxDB/Redis，方案(an)二為(wei)Kafka/Redis/HBase/Flink，方案(an)三為(wei)TDengine

從表4的(de)對比方(fang)案中可以(yi)(yi)看出，TDengine（方(fang)案三）是有著很大的(de)優(you)勢(shi)，尤其在開源EMQX Broker的(de)支持上(shang)(shang)也非常好（主要依(yi)賴于Restful接口(kou)），其他的(de)例(li)如Kafka和InfluxDB只能和企業(ye)版EMQX集成；在數(shu)據(ju)插入和查(cha)詢效率方(fang)面，上(shang)(shang)述三種(zhong)方(fang)案關鍵在于TDengine、HBase和InfluxDB的(de)對比，官網有非常詳細的(de)測試(shi)報告，TDengine也是有絕對優(you)勢(shi)，這里就不過多敘述。所以(yi)(yi)選擇TDengine是勢(shi)在必行的(de)。

3.5 技術期望

在時序數據庫性能方(fang)面，TDengine有著很大(da)的(de)優勢，并且也(ye)集成(cheng)了消息訂閱和(he)流計算功能，可以說在中小型物聯場景下，是(shi)(shi)無需部署Kafka和(he)Flink的(de)。當然個人(ren)理解TDengine不是(shi)(shi)為(wei)了完全取代Kafka和(he)Flink而生的(de)，尤其是(shi)(shi)在大(da)型云(yun)服務項目中，更(geng)多(duo)是(shi)(shi)共存。

但是在邊(bian)緣端，TDengine憑借著極低的(de)資源(yuan)占用率和(he)優秀的(de)時序處理性能，將會(hui)產生(sheng)更大的(de)能量，期望能徹底集成(cheng)邊(bian)緣流計算(suan)和(he)MQTT broker等(deng)功能，擴(kuo)充Modbus、OPC-UA等(deng)常見工(gong)業協議支持(chi)，向下(xia)連(lian)接工(gong)業設備或者(zhe)物聯設施，向上和(he)邊(bian)緣Kubernetes生(sheng)態（如KubeEdge、K3S等(deng)）協同，或者(zhe)直接和(he)云中心(xin)協同。

3.6 系統運行界面

項目重點(dian)是(shi)能(neng)耗(hao)統計，而在(zai)線(xian)采集到TDengine里的(de)(de)數據都是(shi)累計量(liang)，所以(yi)在(zai)計算能(neng)耗(hao)時(shi)，需(xu)要(yao)在(zai)不同的(de)(de)超(chao)級表執行(xing)按表分組、按時(shi)間周期采樣的(de)(de)查詢，類似下面語法：

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

得益(yi)于(yu)TDengine的極佳性能，基本能保(bao)證不超過百毫秒的訪問延時，下面是一些相關的PC端(duan)、移動端(duan)界面（我(wo)們移動端(duan)是用H5做(zuo)的，為了直接(jie)能跑在Android和iOS上）。

寫在最后

其(qi)實(shi)從(cong)2019年(nian)開始就一(yi)直(zhi)在(zai)關注TDengine Database，也看了很多陶總(zong)的演講，受益匪淺，尤其(qi)在(zai)今年(nian)8月份，TDengine進行了集群版(ban)開源(yuan)，也正好準備啟動(dong)能源(yuan)數(shu)據采集項(xiang)目，所(suo)以果(guo)斷采用TDengine作(zuo)為核心時(shi)序引擎，目前也是收獲(huo)了非常的效果(guo)。本(ben)次項(xiang)目實(shi)施過程中，尤其(qi)感(gan)謝濤思(si)數(shu)據的蘇曉慰工程師，多次協助解決TDengine相關的實(shi)施問(wen)題。計劃在(zai)后續其(qi)他項(xiang)目也也會繼續推廣TDengine，同時(shi)也愿意為一(yi)些商(shang)業版(ban)功能付費，支持國產，支持濤思(si)。

作者介紹
于淼，學歷碩(shuo)士，副(fu)研(yan)究(jiu)員，主要(yao)從事MES系統研(yan)發(fa)以(yi)及(ji)智能(neng)(neng)制(zhi)造相(xiang)關理論和標準(zhun)研(yan)究(jiu)，主要(yao)研(yan)究(jiu)方(fang)向(xiang)：數字工(gong)廠(chang)使能(neng)(neng)技術、制(zhi)造執行系統關鍵技術和智能(neng)(neng)制(zhi)造標準(zhun)體系等，參與(yu)國(guo)家(jia)級項(xiang)目及(ji)企業項(xiang)目十(shi)余項(xiang)，包括國(guo)家(jia)重點(dian)研(yan)發(fa)計劃以(yi)及(ji)國(guo)家(jia)智能(neng)(neng)制(zhi)造專項(xiang)等。