作者：喻東 東莞中融數(shù)字

小T導(dǎo)讀：當(dāng)下我國養(yǎng)殖企業(yè)普遍采用傳統(tǒng)塑料耳標(biāo)+人工定期分析+獸醫(yī)現(xiàn)場診斷來做牲畜異常預(yù)防，雖然市面上有固定攝像頭、滑軌追蹤攝像頭、電信NB卡等方案，但這種方式依舊會存在牲畜識別錯誤、高延遲等問題，無法做到實時監(jiān)控每一頭牲畜。基于此，我們利用新興技術(shù)打造了牲畜“特征采集+AI分析”的AIoT平臺，來實現(xiàn)牲畜異常的早發(fā)現(xiàn)、早報警、早預(yù)防。

具體場景如下：使用APP提前錄入采集器編號，再將采集器固定在牲畜身上（耳朵、頸部、腿部等），采集器每分鐘會采集20次特征數(shù)據(jù)，采集數(shù)據(jù)種類包括溫度、流汗情況、經(jīng)緯度、運動、脈搏、環(huán)境溫濕度等。將采集到的數(shù)據(jù)進行邊緣計算，再將匯總結(jié)果通過4G網(wǎng)絡(luò)發(fā)送至云端服務(wù)器，之后云端會根據(jù)經(jīng)緯度等要求獲取到所對應(yīng)的天氣、風(fēng)量等變量，結(jié)合采集器數(shù)據(jù)，AI會綜合評估出牲畜當(dāng)前的健康情況，例如是否有食欲不振、癱坐不動、發(fā)燒趨勢等。

一、架構(gòu)和具體實現(xiàn)

與傳統(tǒng)物聯(lián)網(wǎng)項目一樣，本平臺對數(shù)據(jù)的寫入性能有較高的要求，同時也有一定的聚合查詢需求，具體操作上寫多讀少，是典型的高并發(fā)寫入場景。我們之前采用的是MongoDB的方案，還做了月份分表，但是進行聚合查詢的效率并不高，而且也不便利，之后我們又嘗試引入Cassandra，但使用上依舊不夠便利。

偶然的機會下，我們了解到InfluxDB和TDengine這類時序數(shù)據(jù)庫（Time-Series Database），在搭建測試環(huán)境后對兩者分別進行了測試，最終敲定TDengine。除了兩者直接的性能差距外，TDengine提供的表數(shù)據(jù)TTL機制、數(shù)據(jù)壓縮、流式計算等功能也讓我們更加青睞于它。

基于超級表的設(shè)計原理，我們將牲畜的業(yè)務(wù)關(guān)聯(lián)信息作為tag，方便關(guān)聯(lián)MySQL，同時一個采集器就作為一個子表存在，采集器測點作為子表的列。

表結(jié)構(gòu)分別如下圖所示：圖一為牲畜所佩戴的采集器表，也可以認(rèn)為是牲畜表，其與采集器一一綁定，圖二與圖三則為安裝在養(yǎng)殖場固定位置的環(huán)境溫濕度表，此外還有存儲原始報文數(shù)據(jù)的表等，就不在此一一列舉了。

目前我司的所有物聯(lián)網(wǎng)數(shù)據(jù)表都是基于TDengine超級表設(shè)計的，針對核心的牲畜超級表，其關(guān)聯(lián)的tag會比其他表更多一些。需要注意的是，為了保證TDengine中tag與MySQL一致，每當(dāng)業(yè)務(wù)中修改了牲畜的基本屬性，也需要同步執(zhí)行tag修改操作。

這種表設(shè)計方便我們追溯可能出現(xiàn)的處理延時等問題，表中的collect_time為采集時間，insert_time為數(shù)據(jù)落盤時間，如果兩者的時間差較大，則可能就出現(xiàn)了網(wǎng)絡(luò)差、采集器故障、服務(wù)端吞吐量不夠等問題，此時就需要排查下原因了。

牲畜數(shù)據(jù)采集到數(shù)據(jù)落盤的全流程如下圖所示，通過采集器采集到的數(shù)據(jù)經(jīng)過4G網(wǎng)絡(luò)上報，由設(shè)備網(wǎng)關(guān)初步處理數(shù)據(jù)并推送至MQ，提升吞吐量，之后傳輸給消費者，最終落盤到TDengine。

二、數(shù)據(jù)遷移和實際效果

因為我們之前使用的是其他數(shù)據(jù)庫，更換新的數(shù)據(jù)庫時會產(chǎn)生數(shù)據(jù)遷移的操作，具體遷移步驟如下：

• 新產(chǎn)生的采集器數(shù)據(jù)分別寫入MongoDB和TDengine，即一份數(shù)據(jù)寫兩份，舊數(shù)據(jù)查MongoDB，新數(shù)據(jù)查TDengine，以便出現(xiàn)問題后能及時挽救；
• 逐步將歷史數(shù)據(jù)格式化導(dǎo)入到TDengine；
• AI分析的數(shù)據(jù)源由MySQL數(shù)倉改為TDengine。

在遷移過程中我們也遇到了一些小問題，主要有兩點：

• 由于此前使用的是MySQL+MongoDB的方案，所有MongoDB的語句都得改寫為TDengine的SQL，而TDengine的語法雖然接近SQL，但細(xì)節(jié)部分區(qū)別卻不少，不過也并不是大問題，適應(yīng)之后就好了。
• 由于我司的服務(wù)比較多，起初我有考慮做一個中間件來提供給系統(tǒng)內(nèi)的其他服務(wù)做數(shù)據(jù)查詢，但由于TDengine是一個較新的開源項目，因此最終還是使用傳統(tǒng)的方式：涉及到了物聯(lián)網(wǎng)數(shù)據(jù)調(diào)用的服務(wù)全部自行連接taos，在遷移運行穩(wěn)定后再做整合。 

遷移之后的效果也非常明顯，我們在使用MongoDB時，自建集群是使用了6臺4核32G機器，遷移到TDengine之后，自建集群僅使用了2臺8核32G機器，在成本上有顯著下降。

在性能的具體表現(xiàn)上，我模擬了6000多個采集器的數(shù)據(jù)，表數(shù)據(jù)合計約三億條。我司大部分查詢都是基于子表，僅部分業(yè)務(wù)需要查看聚合操作。對超級表做group by+last_row(*)查詢時，能在1.5s內(nèi)返回數(shù)據(jù)，對子表做查詢在0.1秒左右（select * from son_table limit 10），可以滿足業(yè)務(wù)要求。

三、寫在最后

隨著物聯(lián)網(wǎng)、人工智能等新興科技的發(fā)展，AIot已經(jīng)是個不可忽視的大趨勢，而計算環(huán)節(jié)往往少不了數(shù)倉，但在需求不復(fù)雜的產(chǎn)品中或許可以節(jié)省掉這一步，某種意義上，TDengine Database提供的流式計算和高性能的查詢，也幫助我們在一定程度上省掉了不少中間步驟，達(dá)到了降本增效的結(jié)果。

現(xiàn)在TDengine Database在成本管控和性能提升方面所帶來的效果已經(jīng)很突出，如果其能夠在未來某個版本支持與模型之間的調(diào)用并直接輸出結(jié)果，那可就太完美了！