小 T 導(dǎo)讀：作為一家聚焦慣性傳感技術(shù)領(lǐng)域的企業(yè)，北微傳感致力于讓物聯(lián)世界更美好，其研發(fā)的數(shù)百種型號(hào)的傾角傳感器、電子羅盤、航姿參考系統(tǒng)、慣性測(cè)量單元、光纖陀螺儀、組合導(dǎo)航等產(chǎn)品，在交通運(yùn)輸、工程機(jī)械、航空航天、能源電力、醫(yī)療器械等領(lǐng)域發(fā)揮著重要的作用。隨著業(yè)務(wù)的不斷發(fā)展，北微傳感對(duì)傳感器數(shù)據(jù)的重視程度也在逐漸提高。

為了實(shí)現(xiàn)傳感器的智能監(jiān)控以及智能管理，北微傳感旗下的北微云團(tuán)隊(duì)打造了物聯(lián)網(wǎng)接入平臺(tái)，實(shí)現(xiàn)傳感器數(shù)據(jù)的解析、處理、可視化、狀態(tài)監(jiān)控、數(shù)據(jù)監(jiān)測(cè)、月度數(shù)據(jù)下載、告警推送、上傳日志記錄等諸多功能。

這套系統(tǒng)在終端設(shè)備對(duì)接連接管理平臺(tái)后，可通過TCP/UDP等形式采集終端數(shù)據(jù)，并在連接結(jié)束后將當(dāng)前傳輸?shù)臄?shù)據(jù)集通過消息隊(duì)列的形式，推送到設(shè)備管理及數(shù)據(jù)解析平臺(tái)，實(shí)現(xiàn)對(duì)傳輸數(shù)據(jù)的解析以及上傳日志的留檔。在應(yīng)用開發(fā)層，從物聯(lián)網(wǎng)平臺(tái)的基礎(chǔ)業(yè)務(wù)場(chǎng)景出發(fā)，結(jié)合數(shù)據(jù)實(shí)現(xiàn)業(yè)務(wù)封裝，提供大屏數(shù)據(jù)接口、數(shù)據(jù)狀態(tài)監(jiān)測(cè)等諸多功能。后續(xù)計(jì)劃提供對(duì)應(yīng)的SDK，將平臺(tái)數(shù)據(jù)及能力下放，方便用戶在自身系統(tǒng)上拓展出平臺(tái)提供的能力。

由于傳感器設(shè)備數(shù)量眾多且數(shù)據(jù)不一，連接管理平臺(tái)所接收的數(shù)據(jù)傳輸量巨大。為了保證數(shù)據(jù)接收日志的連貫以及上傳間隔的直觀可視化，無論是TCP還是UDP的接收都采用了批量插入的操作，每次終端上傳的突發(fā)數(shù)據(jù)量都很大，因此要求搭載的數(shù)據(jù)庫(kù)要具備極高的數(shù)據(jù)吞吐率和存儲(chǔ)低延時(shí)。

基于此，我們決定進(jìn)行數(shù)據(jù)庫(kù)選型，以匹配北微云平臺(tái)的搭建。

一、為什么選擇TDengine Database

在整套系統(tǒng)的構(gòu)建中，用戶出于對(duì)后續(xù)產(chǎn)品的迭代等考量，在研發(fā)初期就對(duì)數(shù)據(jù)動(dòng)態(tài)化、接入設(shè)備多元化、系統(tǒng)性能、查詢速度以及數(shù)據(jù)展現(xiàn)形式設(shè)定了相關(guān)的要求。

初期系統(tǒng)采用的是簡(jiǎn)單的單設(shè)備類型及單協(xié)議設(shè)計(jì)，數(shù)據(jù)庫(kù)搭建上選用的是MySQL+索引的方式，弊端是當(dāng)數(shù)據(jù)寫入過多以及查詢深度過大時(shí)，時(shí)常出現(xiàn)數(shù)據(jù)庫(kù)宕機(jī)等各種問題。此外，當(dāng)接入終端的數(shù)量增加時(shí)會(huì)產(chǎn)生大量的時(shí)序數(shù)據(jù)，在實(shí)現(xiàn)存儲(chǔ)、壓縮、查詢等基本需求外，還需要平衡學(xué)習(xí)及運(yùn)維成本。

從以上問題和需求出發(fā)，數(shù)據(jù)庫(kù)需要具備以下幾點(diǎn)能力：

• 可以準(zhǔn)確地記錄插入時(shí)間，具有較高的查詢速度、強(qiáng)大的數(shù)據(jù)讀寫及壓縮能力
• 從報(bào)表的查詢場(chǎng)景出發(fā)要具備優(yōu)秀的時(shí)間檢索能力，以提高月度報(bào)表的請(qǐng)求速度
• 提供毫秒級(jí)別的數(shù)據(jù)查詢、時(shí)間軸的滑動(dòng)窗口聚合以及多種針對(duì)物聯(lián)網(wǎng)場(chǎng)景的函數(shù)
• 提供可以快速集成的告警組件，減少開發(fā)成本

幸運(yùn)的是，我在2020年3月參與過一個(gè)空調(diào)控制系統(tǒng)的研發(fā)，當(dāng)時(shí)采取的是InfluxDB、TDengine雙數(shù)據(jù)庫(kù)存儲(chǔ)的形式，但在后續(xù)的迭代中已經(jīng)全面轉(zhuǎn)向TDengine。在這個(gè)研發(fā)任務(wù)中，我負(fù)責(zé)的業(yè)務(wù)就是基于TDengine實(shí)現(xiàn)監(jiān)測(cè)數(shù)據(jù)的可視化以及大屏展示，對(duì)于其類SQL的操作方式以及優(yōu)秀的查詢性能印象深刻。

基于以上原因，為了保證項(xiàng)目的快速交付以及系統(tǒng)的穩(wěn)定運(yùn)行，我們選擇了TDengine作為北微云平臺(tái)接入設(shè)備的時(shí)序數(shù)據(jù)庫(kù)。

二、TDengine Database的具體實(shí)踐

具體到我們的場(chǎng)景中，使用TDengine建庫(kù)建表的思路如下所示：

TDengine超級(jí)表的結(jié)構(gòu)十分簡(jiǎn)單，采集字段就是時(shí)間戳ts和采集值data_value。但此處定義了三個(gè)標(biāo)簽，分別是用于描述設(shè)備的地址編碼、企業(yè)分組編碼以及參數(shù)編碼。

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

在實(shí)際使用中，我們還發(fā)現(xiàn)采用TDengine提供的連續(xù)查詢功能，可以高效處理類似于時(shí)間窗口下傳感器的電量及溫度場(chǎng)景。舉個(gè)例子，以每小時(shí)為時(shí)間窗口、每半小時(shí)為前進(jìn)量來統(tǒng)計(jì)傳感器所在地點(diǎn)的溫度：

可以通過select * from avg_temp_100000015 order by ts desc;的形式快速獲取已經(jīng)存儲(chǔ)好的數(shù)據(jù)，對(duì)于類似的按照時(shí)間周期進(jìn)行折線統(tǒng)計(jì)的場(chǎng)景相當(dāng)有效。反映到實(shí)際業(yè)務(wù)場(chǎng)景中，如下所示：

下圖為TDengine的查詢效果展示，幾乎達(dá)到了所查即所得的效果。

三、北微云架構(gòu)搭載TDengine的效果與優(yōu)勢(shì)

北微云采用了工業(yè)互聯(lián)網(wǎng)平臺(tái)典型的端邊云系統(tǒng)架構(gòu)，通過設(shè)備管理平臺(tái)、連接管理平臺(tái)、應(yīng)用開發(fā)平臺(tái)等幾大模塊的運(yùn)作保障應(yīng)用層業(yè)務(wù)功能的穩(wěn)定，更好地服務(wù)于終端型號(hào)及解析策略配置、設(shè)備連接與管理、數(shù)據(jù)分析及監(jiān)控、月度數(shù)據(jù)查詢與下載等場(chǎng)景，同時(shí)可支持多類型終端及為其他項(xiàng)目提供接入的需求。下圖為具體的架構(gòu)示意圖：

本項(xiàng)目中，通過各種協(xié)議以及SDK、API等獲取的傳感器數(shù)據(jù)是主要的數(shù)據(jù)來源。物聯(lián)網(wǎng)終端設(shè)備按照固定的上傳周期進(jìn)行上傳，隨著時(shí)間的推移，傳感器積累的數(shù)據(jù)量在不斷增多，由此所帶來的查詢成本以及數(shù)據(jù)導(dǎo)出壓力也變得相當(dāng)巨大。同時(shí)，用戶對(duì)于數(shù)據(jù)安全也具有較高的要求。

在咨詢濤思數(shù)據(jù)的小伙伴后，我們?cè)诰€上環(huán)境搭建時(shí)采用了TDengine雙主節(jié)點(diǎn)部署的形式，降低了單機(jī)遇到全量查詢時(shí)的數(shù)據(jù)壓力，提高吞吐的同時(shí)也提升了查詢響應(yīng)的速度。

該項(xiàng)目中的應(yīng)用開發(fā)平臺(tái)以及設(shè)備管理平臺(tái)采取了多機(jī)部署，通過設(shè)置對(duì)應(yīng)的Nginx負(fù)載均衡策略提升系統(tǒng)的流暢程度。相較于北微傳感之前使用的三方平臺(tái)——進(jìn)入設(shè)備列表至少要等待3秒、海量數(shù)據(jù)查詢1分鐘以上，目前情況已經(jīng)有了相當(dāng)大的改善：全量查詢基本控制在了秒級(jí)，大屏的實(shí)時(shí)場(chǎng)景也可以提供毫秒級(jí)別的數(shù)據(jù)響應(yīng)。

在傳感器監(jiān)測(cè)的場(chǎng)景下，系統(tǒng)需要根據(jù)傳感器數(shù)據(jù)對(duì)不同的數(shù)據(jù)項(xiàng)進(jìn)行監(jiān)控，若超過預(yù)設(shè)閾值則進(jìn)行對(duì)應(yīng)的告警推送。從技術(shù)的角度講，報(bào)警是指從最近一段時(shí)間產(chǎn)生的數(shù)據(jù)中篩選出符合一定條件的數(shù)據(jù)，根據(jù)定義好的計(jì)算方法得出一個(gè)結(jié)果，當(dāng)結(jié)果符合某個(gè)條件且持續(xù)一定時(shí)間后，觸發(fā)警告并以某種形式通知用戶。在TDengine 告警模塊的幫助下，組件的開發(fā)尤其迅速，我們短短兩天就完成了相關(guān)編碼。

在告警組件的開發(fā)中，我們通過封裝參數(shù)內(nèi)置公式解析算法對(duì)請(qǐng)求JSON中的expr（表達(dá)式以及部分函數(shù)）進(jìn)行封裝，為復(fù)雜的邏輯運(yùn)算提供了解析與支持，并基于Alert組件的RESTful接口擴(kuò)展出報(bào)警監(jiān)測(cè)規(guī)則、報(bào)警監(jiān)測(cè)組件以及報(bào)警監(jiān)測(cè)模板的能力。

在收到規(guī)則及模板添加請(qǐng)求后，通過領(lǐng)域模型封裝能力，可以快速構(gòu)建符合請(qǐng)求規(guī)范的JSON形式的報(bào)警規(guī)則。在推送完成后還可以實(shí)現(xiàn)告警規(guī)則的本地化存儲(chǔ)，使前端可以通過調(diào)用后端接口的方式，對(duì)已經(jīng)推送的報(bào)警規(guī)則進(jìn)行管理。

在對(duì)應(yīng)的數(shù)據(jù)行為以及業(yè)務(wù)封裝完成后，只需要通過SpringBoot整合AlertManager，以實(shí)現(xiàn)數(shù)據(jù)的接收，再走消息總線發(fā)送到解析平臺(tái)進(jìn)行解析與記錄，并根據(jù)擴(kuò)展點(diǎn)和預(yù)先制定的推送方式完成告警信息的推送即成功（目前站內(nèi)提供了網(wǎng)站彈窗以及郵箱推送的功能)。

四、寫在最后

在第一期的設(shè)計(jì)中，我們針對(duì)TDengine Database提供的告警模塊實(shí)現(xiàn)了一些內(nèi)部的封裝以及功能的拓展，該項(xiàng)目在12月初已經(jīng)交付使用且在年后將轉(zhuǎn)入第二階段的開發(fā)。

二期中對(duì)于系統(tǒng)的拆分有著比較清晰的要求，在完善對(duì)外SDK的同時(shí)，需要將一些非核心領(lǐng)域的相關(guān)能力做一定的剝離，可能會(huì)將封裝的告警組件通過Java SDK的版本暴露出去。后續(xù)平臺(tái)使用穩(wěn)定后會(huì)通過GitHub、Gitee將其進(jìn)行開源，希望可以幫助有同樣需求的同仁，快速擴(kuò)展并設(shè)計(jì)出基于平臺(tái)特色的告警組件。