作者介紹

葉紅(hong)偉，北(bei)京云洋物聯技術有限公司軟件研(yan)發經理，主要(yao)從事智慧農業平臺(tai)開發及(ji)應(ying)用，負責平臺(tai)的架(jia)構設計以及(ji)主要(yao)業務代碼開發工作。

關于云洋物聯

作為(wei)國內領先的(de)數(shu)(shu)字農(nong)(nong)(nong)(nong)業(ye)(ye)產品與解決方案(an)服務(wu)商，云洋(yang)物聯(lian)自成立(li)以(yi)(yi)來便始終(zhong)致力(li)于(yu)推動三農(nong)(nong)(nong)(nong)新基建的(de)發(fa)展(zhan)，以(yi)(yi)數(shu)(shu)據賦能(neng)農(nong)(nong)(nong)(nong)業(ye)(ye)建設，以(yi)(yi)科技(ji)振興鄉(xiang)村作為(wei)使命初心(xin)，加速農(nong)(nong)(nong)(nong)業(ye)(ye)農(nong)(nong)(nong)(nong)村的(de)轉型升級。同(tong)時，科學運(yun)用互聯(lian)網、物聯(lian)網、大數(shu)(shu)據、區(qu)塊鏈等(deng)新興技(ji)術，將AloT技(ji)術與農(nong)(nong)(nong)(nong)業(ye)(ye)生產技(ji)術深度(du)融(rong)合，在政策與科技(ji)的(de)融(rong)匯交(jiao)集(ji)、疊加備力(li)下，助(zhu)力(li)行業(ye)(ye)企業(ye)(ye)實現降本增效、提質增收。 業(ye)(ye)務(wu)快速發(fa)展(zhan)之余，云洋(yang)物聯(lian)不(bu)可避免地也遇到(dao)了一些棘(ji)手的(de)難題(ti)，如元數(shu)(shu)據的(de)存儲模(mo)式導致空間(jian)占用率加速膨脹，查詢分析(xi)操作響應時間(jian)達不(bu)到(dao)要求，系統(tong)復雜度(du)越(yue)來越(yue)高等(deng)等(deng)。

在此背景下，云洋物聯決定采用時序數據庫（Time-Series Database），并經過(guo)一(yi)系(xi)列測試和對比分(fen)析后得出選(xuan)型結論——基(ji)于(yu)全表(biao)和單個設備進行統(tong)計查(cha)詢，TDengine對比MongoDB分(fen)別(bie)快了(le)3倍、10倍。于(yu)是，云洋物聯決定將(jiang)系(xi)統(tong)從(cong)原有架(jia)構遷移到(dao)TDengine Database。

業務架構詳解

云洋(yang)物(wu)聯(lian)(lian)智(zhi)慧農業平臺是一(yi)家基于農業物(wu)聯(lian)(lian)網設(she)(she)備(bei)(bei)和AI種(zhong)植(zhi)模型(xing)(xing)，為(wei)溫(wen)室大棚、大田提供(gong)標準化智(zhi)能種(zhong)植(zhi)方案的技(ji)術服務商(shang)。在(zai)實(shi)際生產種(zhong)植(zhi)環境(jing)(jing)中(zhong)，云洋(yang)物(wu)聯(lian)(lian)以每個大棚、大田為(wei)基準點，根據(ju)作物(wu)的不同茬口(kou)及生育期，匹配出(chu)適宜(yi)作物(wu)生長的環境(jing)(jing)參數，并以此建立合(he)適的智(zhi)能種(zhong)植(zhi)方案。 具體而言，云洋(yang)系統會(hui)通(tong)過物(wu)聯(lian)(lian)網采集設(she)(she)備(bei)(bei)實(shi)時上報的數據(ju)，判斷棚內(nei)(nei)環境(jing)(jing)是否適宜(yi)種(zhong)植(zhi)作物(wu)生長。當(dang)棚內(nei)(nei)環境(jing)(jing)觸發(fa)設(she)(she)備(bei)(bei)設(she)(she)置對應閾值時，關(guan)聯(lian)(lian)狀態下的手機等電子(zi)設(she)(she)備(bei)(bei)將(jiang)會(hui)啟動告警通(tong)知(zhi)，或觸發(fa)控(kong)制(zhi)設(she)(she)備(bei)(bei)的自(zi)動控(kong)制(zhi)開關(guan)。此外，通(tong)過模型(xing)(xing)算(suan)法還(huan)能計算(suan)出(chu)大棚、大田積溫(wen)情(qing)況，利用空氣(qi)溫(wen)度(du)、濕度(du)等環境(jing)(jing)要素來(lai)預(yu)測是否會(hui)觸發(fa)蟲害(hai)、病害(hai)等危(wei)害(hai)。

圖1 云洋系統的(de)(de)運營監控大屏，圖2為(wei)云洋系統的(de)(de)業務架構(gou)圖，其(qi)中最下層設備層為(wei)邊緣硬件設備，通過設備數(shu)據分發(fa)網關對設備實時數(shu)據進行(xing)定向分發(fa)。

業務架構中幾(ji)個重要模板(ban)的分工(gong)為(wei)：

• 設備控制服務負責下發設備控制及響應、設備運維處理、設備遠程升級、日志讀取等功能；
• 設備數據分析告警按照定義的規則對實時數據進行分析告警；
• 設備存儲服務負責對設備數據進行解析入庫，提供設備數據查詢功能；
• 業務層則是對實際業務的抽象，結合用戶園區地塊及綁定的物聯網設備、設備產生的數據，結合標準化種植模型進行方案推薦及病害蟲害的預測。

元數據存儲模式導致數據表空間占用率膨脹十幾倍

眾(zhong)所周(zhou)知(zhi)，農業(ye)物聯網(wang)設(she)備(bei)主(zhu)要分為環(huan)境(jing)數據采集(ji)與控制(zhi)兩大類。其中環(huan)境(jing)數據采集(ji)型(xing)設(she)備(bei)，細分的話(hua)又有各(ge)類單品(pin)傳(chuan)感(gan)器、多合(he)一傳(chuan)感(gan)器和氣象站等(deng)，而這些設(she)備(bei)采集(ji)環(huan)境(jing)要素指標往(wang)往(wang)也具有多樣性(xing)。

下(xia)圖為不同設備(bei)的采集信息情(qing)況：

發展至今，平(ping)臺上在(zai)線設(she)備已(yi)經有一萬多臺，設(she)備每日上報的數(shu)據量達到上百萬條。 這(zhe)些(xie)數(shu)據基(ji)于MySQL、Redis、MongoDB實現多級存(cun)儲 ，而(er)在(zai)設(she)備采(cai)集參(can)數(shu)的不確定性問(wen)題(ti)上，我們(men)采(cai)用基(ji)于元數(shu)據的范式，增加對設(she)備統(tong)一集中管理配(pei)置(zhi)的靈活性。

但元數據的(de)設(she)計存(cun)儲(chu)(chu)模式(shi)(shi)(shi)在靈活便捷之余，也存(cun)在一些缺陷。舉(ju)例來說，如(ru)(ru)果(guo)我們將(jiang)5個(ge)(ge)采集要(yao)素的(de)設(she)備(bei)數據進行存(cun)儲(chu)(chu)，則會生(sheng)成5條數據，對(dui)比(bi)單表存(cun)儲(chu)(chu)數據量(liang)膨(peng)脹了5倍(bei)。此時針對(dui)一些客戶的(de)需求，比(bi)如(ru)(ru)給潮(chao)州佳寶(bao)產業園定(ding)制的(de)導管式(shi)(shi)(shi)土壤監測站(zhan)，有(you)十幾個(ge)(ge)環境要(yao)素，基于上述(shu)的(de)存(cun)儲(chu)(chu)模式(shi)(shi)(shi)，表空間占用率將(jiang)膨(peng)脹達十幾倍(bei)。

除此(ci)之(zhi)外，因為使用(yong)的(de)(de)是傳統數(shu)(shu)據(ju)(ju)庫，所有(you)設備(bei)數(shu)(shu)據(ju)(ju)都是存(cun)(cun)儲(chu)(chu)(chu)在一張(zhang)表(biao)上(shang)。在這種存(cun)(cun)儲(chu)(chu)(chu)情況下，為了滿足實時(shi)(shi)性查詢的(de)(de)需求，對最新數(shu)(shu)據(ju)(ju)采用(yong)Redis進(jin)行存(cun)(cun)儲(chu)(chu)(chu)；為了滿足周期數(shu)(shu)據(ju)(ju)的(de)(de)范圍查詢，全量的(de)(de)歷史(shi)數(shu)(shu)據(ju)(ju)則通(tong)過MongoDB按時(shi)(shi)間線分表(biao)存(cun)(cun)儲(chu)(chu)(chu)，時(shi)(shi)段內(nei)變動的(de)(de)數(shu)(shu)據(ju)(ju)則存(cun)(cun)儲(chu)(chu)(chu)在MySQL。

設備歷(li)史數據查詢：

地塊環境走(zou)勢(shi)曲線：

隨著業務(wu)功能的(de)豐富細化及設(she)(she)備量的(de)日益增(zeng)加(jia)，對(dui)設(she)(she)備數據(ju)的(de)實時(shi)(shi)查(cha)詢、時(shi)(shi)間(jian)(jian)范圍分(fen)析(xi)的(de)需求增(zeng)加(jia)，基于(yu)MySQL和Mongo DB進(jin)行查(cha)詢分(fen)析(xi)操作響(xiang)應時(shi)(shi)間(jian)(jian)較長(chang)，系(xi)統(tong)復雜度也逐漸增(zeng)高。為了(le)滿(man)足對(dui)設(she)(she)備數據(ju)高效的(de)查(cha)詢分(fen)析(xi)，我們準備將設(she)(she)備數據(ju)存儲(chu)切(qie)換(huan)到時(shi)(shi)序數據(ju)庫。

為什么選擇 TDengine？

在實際的業務(wu)中，對一(yi)段(duan)時(shi)間(jian)(jian)內的數(shu)(shu)據進(jin)行分析是系統中很常見的一(yi)個操作(zuo)。我們在MongoDB（對時(shi)間(jian)(jian)和(he)設備編碼建立了索引）和(he)TDengine上都存(cun)儲了3000萬(wan)條數(shu)(shu)據，首先對全表(biao)進(jin)行時(shi)間(jian)(jian)區(qu)間(jian)(jian)數(shu)(shu)據分組統計查(cha)(cha)詢，兩種數(shu)(shu)據庫的查(cha)(cha)詢結果顯示如下：

MongoDB：

TDengine：

通過對比，基于全表進行時間區間數據分組統計查詢，TDengine比MongoDB快了3倍。

接下(xia)來對單個設備(bei)進行(xing)數(shu)據(ju)分組統計查詢(xun)操作，兩(liang)種數(shu)據(ju)庫的(de)查詢(xun)結果如下(xia)圖(tu)所示(shi)：

MongoDB：

TDengine：

基于單個設備數據的查詢統計，MongoDB是非本地查詢，存在一定的網絡開銷，響應速度在1秒以內，而TDengine對比MongoDB快了10倍以上。

通過上述的測試和應用實踐，我們發現TDengine具有諸多優勢特點，下面簡要列舉一下選擇它的五個理由：

• 數據模型：對比傳統數據庫，TDengine采用一個采集點一張表，動態靜態數據分離模式，對同一類型的采集點采用超級表進行數據統一查詢管理的設計
• 窗口查詢：對比MongoDB、MySQL進行時間范圍的函數操作，響應速度快了一個級別
• 支持標準SQL: 使用簡單，學習成本低
• 標簽查詢：基于給表定義標簽，可以方便地查詢統計分組設備
• 運維簡單：數據庫的安裝、副本擴容，通過簡單的配置即可完成

未來展望

這(zhe)是(shi)一個非(fei)常驚喜的(de)開始，云洋(yang)物聯(lian)和TDengine Database的(de)合作不止于此。未來我們將結合業務需求(qiu)，在更多(duo)場景下應(ying)用(yong)TDengine進(jin)行數據存(cun)儲(chu)，同時對TDengnie的(de)消息隊列、緩存(cun)、流式計(ji)算等功能進(jin)行學習應(ying)用(yong)。

此外，在調研和(he)(he)使用的落地過程中(zhong)，也非常感謝(xie)濤思(si)數據提供(gong)的專業性指導(dao)和(he)(he)建(jian)議，祝TDengine越來(lai)越好(hao)。