小 T 導讀：作為一家聚焦慣性傳感(gan)技術領域(yu)的企業(ye)，北(bei)微傳感(gan)致力(li)于讓物聯(lian)世界(jie)更美(mei)好，其(qi)研發(fa)的數百種型號(hao)的傾角傳感(gan)器、電子羅盤(pan)、航(hang)姿參考系統、慣性測量單元、光纖陀螺(luo)儀、組合導(dao)航(hang)等(deng)(deng)產品，在(zai)交通運輸(shu)、工程機(ji)械(xie)、航(hang)空航(hang)天(tian)、能源電力(li)、醫療器械(xie)等(deng)(deng)領域(yu)發(fa)揮著重要的作用。隨(sui)著業(ye)務的不(bu)斷發(fa)展(zhan)，北(bei)微傳感(gan)對(dui)傳感(gan)器數據的重視程度也在(zai)逐漸提高(gao)。

為(wei)了實(shi)現(xian)傳(chuan)(chuan)感器的智(zhi)能(neng)監(jian)(jian)控(kong)以及(ji)智(zhi)能(neng)管理，北(bei)微(wei)傳(chuan)(chuan)感旗下(xia)的北(bei)微(wei)云(yun)團隊打造了物聯網接入平(ping)臺，實(shi)現(xian)傳(chuan)(chuan)感器數據的解析、處理、可視化、狀態監(jian)(jian)控(kong)、數據監(jian)(jian)測(ce)、月度數據下(xia)載、告警推送、上傳(chuan)(chuan)日志記錄等諸多(duo)功(gong)能(neng)。

這(zhe)套系統在(zai)終(zhong)端(duan)設(she)備(bei)對(dui)接(jie)(jie)(jie)連接(jie)(jie)(jie)管(guan)理(li)平(ping)臺后(hou)，可通過(guo)TCP/UDP等形(xing)式采集(ji)終(zhong)端(duan)數(shu)(shu)據，并在(zai)連接(jie)(jie)(jie)結(jie)束后(hou)將當前傳輸(shu)的數(shu)(shu)據集(ji)通過(guo)消息隊列(lie)的形(xing)式，推送到設(she)備(bei)管(guan)理(li)及數(shu)(shu)據解(jie)析平(ping)臺，實現對(dui)傳輸(shu)數(shu)(shu)據的解(jie)析以及上(shang)傳日志的留檔。在(zai)應用開(kai)發(fa)層，從物聯網平(ping)臺的基礎(chu)業務場景(jing)出發(fa)，結(jie)合(he)數(shu)(shu)據實現業務封裝，提(ti)供(gong)大(da)屏數(shu)(shu)據接(jie)(jie)(jie)口、數(shu)(shu)據狀態監測等諸多功能。后(hou)續計劃(hua)提(ti)供(gong)對(dui)應的SDK，將平(ping)臺數(shu)(shu)據及能力下放(fang)，方便用戶在(zai)自身系統上(shang)拓展(zhan)出平(ping)臺提(ti)供(gong)的能力。

由于傳(chuan)(chuan)感(gan)器(qi)設備數(shu)量(liang)(liang)眾多且(qie)數(shu)據不(bu)一，連接管理平臺所接收(shou)的(de)數(shu)據傳(chuan)(chuan)輸量(liang)(liang)巨大(da)。為了保證數(shu)據接收(shou)日(ri)志的(de)連貫以及(ji)上(shang)傳(chuan)(chuan)間隔(ge)的(de)直觀(guan)可視化(hua)，無論是TCP還是UDP的(de)接收(shou)都采用了批量(liang)(liang)插入的(de)操作，每次終端上(shang)傳(chuan)(chuan)的(de)突(tu)發(fa)數(shu)據量(liang)(liang)都很大(da)，因此要求搭載的(de)數(shu)據庫要具備極高(gao)的(de)數(shu)據吞吐率(lv)和存儲(chu)低延時。

基于此，我們(men)決定(ding)進(jin)行數據庫選型，以匹配(pei)北微云平臺的(de)搭建。

一、為什么選擇TDengine Database

在(zai)整套(tao)系統的(de)構(gou)建中(zhong)，用戶(hu)出(chu)于對后續(xu)產品的(de)迭代等考量，在(zai)研發初期就對數(shu)據動態化、接入設備多元(yuan)化、系統性(xing)能(neng)、查詢速度以及數(shu)據展(zhan)現形(xing)式設定了相關的(de)要求(qiu)。

初期(qi)系統采(cai)用的(de)(de)是簡單的(de)(de)單設(she)備類型及單協(xie)議設(she)計(ji)，數(shu)(shu)據庫搭建上選用的(de)(de)是MySQL+索引的(de)(de)方式，弊端是當數(shu)(shu)據寫入過多以及查(cha)詢深度過大時(shi)，時(shi)常(chang)出現數(shu)(shu)據庫宕機等各種問題。此外(wai)，當接入終端的(de)(de)數(shu)(shu)量增(zeng)加時(shi)會(hui)產生大量的(de)(de)時(shi)序數(shu)(shu)據，在實現存儲、壓縮(suo)、查(cha)詢等基本需求外(wai)，還(huan)需要平衡(heng)學(xue)習及運維成本。

從以上問題和(he)需求出發，數據庫需要具備以下幾(ji)點能力：

• 可以準確地記錄插入時間，具有較高的查詢速度、強大的數據讀寫及壓縮能力
• 從報表的查詢場景出發要具備優秀的時間檢索能力，以提高月度報表的請求速度
• 提供毫秒級別的數據查詢、時間軸的滑動窗口聚合以及多種針對物聯網場景的函數
• 提供可以快速集成的告警組件，減少開發成本

幸運(yun)的(de)(de)是(shi)，我(wo)在(zai)2020年(nian)3月參與過一個空調控制系統的(de)(de)研發(fa)，當時采取的(de)(de)是(shi)InfluxDB、TDengine雙數據(ju)庫(ku)存儲的(de)(de)形(xing)式，但在(zai)后續(xu)的(de)(de)迭代中(zhong)(zhong)已經全面轉向TDengine。在(zai)這個研發(fa)任(ren)務中(zhong)(zhong)，我(wo)負(fu)責的(de)(de)業務就是(shi)基于TDengine實現(xian)監測數據(ju)的(de)(de)可視化以(yi)及大屏展示，對(dui)于其類SQL的(de)(de)操作(zuo)方式以(yi)及優秀(xiu)的(de)(de)查詢性(xing)能印象深刻。

基于以上原因，為了保證項目的快速交付以及系統的穩定運行，我們選擇了TDengine作為北微云平臺接入設備的時序數據庫。

二、TDengine Database的具體實踐

具體到我們的場景中，使用TDengine建庫建表的思路如下所示：

TDengine超級表的(de)結構十分簡單，采集(ji)字(zi)段就是時間戳ts和(he)采集(ji)值data_value。但此處定(ding)義了三個標(biao)簽，分別是用于描述(shu)設備的(de)地址(zhi)編碼(ma)、企業分組編碼(ma)以及參數編碼(ma)。

從下面子表的設計中可以看到，針對大數據量以及多數據參數的查詢情況，我們采取了一個數據參數、一個地址編碼為一張表的存儲方式，在查詢時直接對設備地址編碼_參數編碼的表進行查詢，大大降低了數據查詢時間。在可視化服務通過一定算法優化的前提下，單核2G輕量服務器的配置，近百萬條數據的分析查詢時間僅在3秒以內。

在(zai)實際使用中(zhong)，我們還發現采用TDengine提供的(de)連(lian)續查(cha)詢(xun)功能，可以高(gao)效(xiao)處理類(lei)似(si)于時(shi)間窗口下傳感器(qi)的(de)電(dian)量及溫度場景。舉個例子，以每小時(shi)為時(shi)間窗口、每半小時(shi)為前進量來統計傳感器(qi)所在(zai)地點的(de)溫度：

可以(yi)通過select * from avg_temp_100000015 order by ts desc;的(de)形式(shi)快(kuai)速獲取(qu)已經存儲好(hao)的(de)數據，對于類似的(de)按(an)照時間周(zhou)期進(jin)行(xing)折線(xian)統計的(de)場景相當有效。反映到實際業務(wu)場景中(zhong)，如下(xia)所(suo)示：

下圖為TDengine的(de)查詢效果展示，幾乎(hu)達(da)到(dao)了所(suo)查即所(suo)得的(de)效果。

三、北微云架構搭載TDengine的效果與優勢

北微云采用(yong)了工業互聯網平臺(tai)(tai)典型(xing)的(de)(de)端(duan)邊(bian)云系統(tong)架(jia)(jia)構，通過設備(bei)管理(li)平臺(tai)(tai)、連接管理(li)平臺(tai)(tai)、應用(yong)開發(fa)平臺(tai)(tai)等幾大模塊(kuai)的(de)(de)運作保障(zhang)應用(yong)層(ceng)業務功能的(de)(de)穩定，更好地服務于終端(duan)型(xing)號及(ji)解析(xi)策略配置、設備(bei)連接與(yu)管理(li)、數據(ju)分析(xi)及(ji)監控、月度數據(ju)查詢(xun)與(yu)下載等場景，同時可(ke)支持(chi)多類型(xing)終端(duan)及(ji)為其(qi)他項目提供接入的(de)(de)需求(qiu)。下圖為具體的(de)(de)架(jia)(jia)構示(shi)意圖：

本項目中，通過各種(zhong)協議(yi)以及(ji)SDK、API等獲取(qu)的(de)傳感器(qi)(qi)數據是(shi)主要(yao)的(de)數據來源。物聯網終端設(she)備按(an)照(zhao)固定的(de)上傳周期進行上傳，隨著時(shi)間的(de)推移，傳感器(qi)(qi)積累(lei)的(de)數據量在不斷增多，由此所帶來的(de)查詢成本以及(ji)數據導出壓(ya)力也(ye)(ye)變得相當巨大。同(tong)時(shi)，用戶(hu)對于數據安全(quan)也(ye)(ye)具有(you)較高(gao)的(de)要(yao)求。

在咨詢濤思數據的小伙伴后，我們在線上環境搭建時采用了TDengine雙主節點部署的形式，降低了單機遇到全量查詢時的數據壓力，提高吞吐的同時也提升了查詢響應的速度。

該項(xiang)目中的(de)(de)應(ying)用開發平臺以及設(she)備管理(li)平臺采取了(le)多機部署，通過(guo)設(she)置(zhi)對應(ying)的(de)(de)Nginx負載均衡策(ce)略提升系(xi)統的(de)(de)流暢程度。相較于北微傳(chuan)感之(zhi)前使(shi)用的(de)(de)三方平臺——進入設(she)備列(lie)表至(zhi)少要等待3秒、海(hai)量數據查(cha)(cha)詢1分鐘(zhong)以上，目前情(qing)況已經有了(le)相當大的(de)(de)改善：全量查(cha)(cha)詢基本(ben)控制在了(le)秒級，大屏的(de)(de)實(shi)時場景(jing)也可以提供(gong)毫秒級別的(de)(de)數據響應(ying)。

在傳感器監測的場景下，系統需要根據傳感器數據對不同的數據項進行監控，若超過預設閾值則進行對應的告警推送。從技術的角度講，報警是指從最近一段時間產生的數據中篩選出符合一定條件的數據，根據定義好的計算方法得出一個結果，當結果符合某個條件且持續一定時間后，觸發警告并以某種形式通知用戶。在TDengine 告警模塊的幫助下，組件的開發尤其迅速，我們短短兩天就完成了相關編碼。

在告(gao)警組件的開發中，我(wo)們通過封裝參(can)數(shu)內置公式解(jie)(jie)析算法對請求JSON中的expr（表達式以(yi)及部分函數(shu)）進行封裝，為復雜的邏輯運算提供(gong)了解(jie)(jie)析與支(zhi)持(chi)，并基于Alert組件的RESTful接(jie)口擴展(zhan)出(chu)報(bao)警監(jian)測(ce)規則、報(bao)警監(jian)測(ce)組件以(yi)及報(bao)警監(jian)測(ce)模板的能力。

在收到(dao)規則(ze)及模板添加請求后，通(tong)過(guo)(guo)領域模型(xing)封裝能力，可(ke)以(yi)快(kuai)速構建符(fu)合(he)請求規范(fan)的JSON形式(shi)的報警(jing)(jing)規則(ze)。在推(tui)(tui)送完成后還可(ke)以(yi)實現(xian)告警(jing)(jing)規則(ze)的本(ben)地化存儲，使前(qian)端可(ke)以(yi)通(tong)過(guo)(guo)調用后端接(jie)口的方式(shi)，對已經推(tui)(tui)送的報警(jing)(jing)規則(ze)進行(xing)管理。

在對應的(de)數據行為以(yi)(yi)及業務封裝完(wan)成(cheng)后，只需要通過SpringBoot整(zheng)合(he)AlertManager，以(yi)(yi)實現數據的(de)接收，再走消息總線發送到解(jie)(jie)析(xi)平臺進行解(jie)(jie)析(xi)與記錄，并根據擴展點(dian)和預先制定的(de)推送方(fang)式完(wan)成(cheng)告警信息的(de)推送即成(cheng)功（目(mu)前(qian)站內提供(gong)了網站彈窗(chuang)以(yi)(yi)及郵箱推送的(de)功能(neng))。

四、寫在最后

在(zai)第一(yi)期的(de)設計中，我們(men)針對TDengine Database提供的(de)告警模(mo)塊(kuai)實現了一(yi)些內部的(de)封裝以及功能的(de)拓展，該項目在(zai)12月初已(yi)經交付使用且在(zai)年后將轉(zhuan)入(ru)第二階段(duan)的(de)開(kai)發。

二期(qi)中對于系統的(de)(de)拆分有著(zhu)比(bi)較清晰的(de)(de)要(yao)求，在完善對外SDK的(de)(de)同時，需(xu)要(yao)將(jiang)一些非(fei)核心領(ling)域的(de)(de)相關能力做一定的(de)(de)剝(bo)離，可能會將(jiang)封(feng)裝的(de)(de)告警組件通(tong)(tong)過Java SDK的(de)(de)版本(ben)暴露(lu)出(chu)去。后續平(ping)臺使用(yong)穩定后會通(tong)(tong)過GitHub、Gitee將(jiang)其進行開源(yuan)，希望(wang)可以幫助有同樣需(xu)求的(de)(de)同仁，快速擴展并設計出(chu)基于平(ping)臺特色的(de)(de)告警組件。