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

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

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

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

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

一、為什么選擇TDengine Database

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

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

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

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

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

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

二、TDengine Database的具體實踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、寫在最后

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

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