孟超英 張雪彬 陳紅茜 李 輝

(1.中國(guó)農(nóng)業(yè)大學(xué)信息與電氣工程學(xué)院， 北京 100083； 2.中國(guó)農(nóng)業(yè)大學(xué)網(wǎng)絡(luò)中心， 北京 100083)

0 引言

隨著物聯(lián)網(wǎng)、云計(jì)算、互聯(lián)網(wǎng)技術(shù)等的不斷發(fā)展，信息化水平不斷提高，各行業(yè)數(shù)據(jù)爆炸式增長(zhǎng)[1]。我國(guó)是農(nóng)業(yè)大國(guó)，農(nóng)業(yè)大數(shù)據(jù)對(duì)農(nóng)業(yè)現(xiàn)代化具有重要意義[2]。而蛋雞產(chǎn)業(yè)是國(guó)內(nèi)養(yǎng)殖業(yè)的主導(dǎo)產(chǎn)業(yè)之一，近年來其整合速度、規(guī)?；俣日诩铀侔l(fā)展[3]。在避免人為干擾的情況下，獲取生產(chǎn)養(yǎng)殖、環(huán)境監(jiān)測(cè)數(shù)據(jù)并進(jìn)行處理分析得到了廣泛深入研究。目前蛋雞養(yǎng)殖企業(yè)采用物聯(lián)網(wǎng)系統(tǒng)，通過傳感器實(shí)時(shí)采集數(shù)據(jù)并進(jìn)行展示已經(jīng)得到應(yīng)用[4-5]。對(duì)采集到的數(shù)據(jù)進(jìn)行自動(dòng)化處理和分析也已經(jīng)得到小規(guī)模示范實(shí)施[6]。隨著系統(tǒng)的常年運(yùn)行、數(shù)據(jù)不斷積累，產(chǎn)生的海量數(shù)據(jù)存儲(chǔ)、查詢及分析處理問題亟待解決。對(duì)于海量環(huán)境監(jiān)測(cè)數(shù)據(jù)，傳統(tǒng)數(shù)據(jù)庫的處理能力無法滿足實(shí)時(shí)數(shù)據(jù)查詢的需求。對(duì)于海量視頻數(shù)據(jù)，由于格式不同，視頻統(tǒng)一管理、實(shí)時(shí)查看較為困難，后續(xù)基于視頻的蛋雞行為分析[7]也將更加復(fù)雜。

在前期物聯(lián)網(wǎng)數(shù)據(jù)采集系統(tǒng)的基礎(chǔ)上，本文設(shè)計(jì)基于Hadoop的規(guī)模化蛋雞設(shè)施養(yǎng)殖智能監(jiān)測(cè)管理系統(tǒng)，使用Hadoop框架及其生態(tài)系統(tǒng)對(duì)規(guī)?；半u養(yǎng)殖產(chǎn)生的生產(chǎn)環(huán)境數(shù)據(jù)、生產(chǎn)過程數(shù)據(jù)及現(xiàn)場(chǎng)監(jiān)控視頻數(shù)據(jù)進(jìn)行高效存儲(chǔ)、處理和分析，從而進(jìn)行實(shí)時(shí)監(jiān)測(cè)、統(tǒng)一管理。

1 Hadoop及其生態(tài)系統(tǒng)

Hadoop是Apache基金會(huì)開發(fā)的分布式計(jì)算框架，可以對(duì)海量數(shù)據(jù)進(jìn)行分布式存儲(chǔ)及并行運(yùn)算[8]。Hadoop是當(dāng)前熱門的云平臺(tái)之一，具有靈活可擴(kuò)展、經(jīng)濟(jì)可靠等優(yōu)勢(shì)。目前，Hadoop已經(jīng)形成一套包括分布式文件系統(tǒng)(Hadoop distributed file system，HDFS)、MapReduce、HBase、Zoo-keeper、Hive、Pig等在內(nèi)的生態(tài)系統(tǒng)，并在不斷發(fā)展擴(kuò)充[9]。Hadoop2.0生態(tài)系統(tǒng)如圖1所示。

圖1 Hadoop2.0生態(tài)系統(tǒng)Fig.1 Hadoop2.0 ecosystem

Hadoop框架由2個(gè)核心設(shè)計(jì)組成：分布式文件系統(tǒng)HDFS和分布式并行計(jì)算框架MapReduce[10-12]。HDFS[13-14]作為Hadoop的數(shù)據(jù)存儲(chǔ)核心，具有高容錯(cuò)性、高吞吐量等特點(diǎn)?？梢愿咝Т鎯?chǔ)蛋雞生產(chǎn)養(yǎng)殖中所產(chǎn)生的異構(gòu)數(shù)據(jù)。MapReduce[15]用于海量數(shù)據(jù)的并行運(yùn)算，為蛋雞舍監(jiān)控視頻的并行處理提供了支撐。而Hadoop生態(tài)系統(tǒng)中的HBase[16-17]是一個(gè)基于HDFS的分布式非關(guān)系型數(shù)據(jù)庫，支持?jǐn)?shù)據(jù)的隨機(jī)查找，能夠處理大規(guī)模數(shù)據(jù)，適合海量環(huán)境監(jiān)測(cè)數(shù)據(jù)的實(shí)時(shí)查詢。

2 系統(tǒng)設(shè)計(jì)

2.1 系統(tǒng)總體架構(gòu)

基于Hadoop的規(guī)?；半u設(shè)施養(yǎng)殖智能監(jiān)測(cè)管理系統(tǒng)運(yùn)行于多地不同蛋雞養(yǎng)殖場(chǎng)，使用物聯(lián)網(wǎng)、云存儲(chǔ)、異步傳輸?shù)榷囗?xiàng)技術(shù)構(gòu)建，向用戶提供數(shù)據(jù)的智能處理、實(shí)時(shí)展示。系統(tǒng)綜合物聯(lián)網(wǎng)[18]及云平臺(tái)架構(gòu)[19]，系統(tǒng)總體架構(gòu)如圖2所示。自下而上包括感知層、傳輸層、基礎(chǔ)設(shè)施層、中間層及應(yīng)用層。

圖2 系統(tǒng)總體架構(gòu)Fig.2 Overall architecture of system

感知層集成了攝像頭、拾音器及各種環(huán)境傳感器，負(fù)責(zé)進(jìn)行數(shù)據(jù)采集。采集到的數(shù)據(jù)由傳輸層通過有線網(wǎng)絡(luò)及無線網(wǎng)絡(luò)傳入基礎(chǔ)設(shè)施層?；A(chǔ)設(shè)施層提供底層的服務(wù)器等硬件資源，負(fù)責(zé)存儲(chǔ)數(shù)據(jù)并向中間層提供數(shù)據(jù)支撐。中間層負(fù)責(zé)數(shù)據(jù)的統(tǒng)一規(guī)劃，進(jìn)而分布式存儲(chǔ)數(shù)據(jù)。同時(shí)，中間層提供了基于MapReduce的分布式轉(zhuǎn)碼模塊，為異構(gòu)視頻數(shù)據(jù)的展示下載提供了支持。應(yīng)用層則向用戶提供環(huán)境的實(shí)時(shí)監(jiān)測(cè)、音視頻分析、生產(chǎn)過程管理、數(shù)據(jù)圖表分析等相關(guān)用戶感興趣的服務(wù)。

2.2 系統(tǒng)總體拓?fù)?/h3>

系統(tǒng)的數(shù)據(jù)來源為各地不同養(yǎng)殖場(chǎng)中由生產(chǎn)養(yǎng)殖人員填寫的生產(chǎn)流程數(shù)據(jù)，以及各雞舍部署的環(huán)境傳感器采集的環(huán)境數(shù)據(jù)，如溫濕度、光照強(qiáng)度、二氧化碳濃度、二氧化硫濃度、氨氣濃度等；通過拾音器錄制的蛋雞舍舍內(nèi)音頻數(shù)據(jù)；使用攝像頭拍攝的蛋雞舍監(jiān)控圖像、視頻數(shù)據(jù)。數(shù)據(jù)經(jīng)采集后，暫存于現(xiàn)場(chǎng)服務(wù)器中。在現(xiàn)場(chǎng)服務(wù)器中部署監(jiān)控程序監(jiān)控?cái)?shù)據(jù)庫及采集到的音視頻及圖像文件。采集到數(shù)據(jù)后，Kafka集群將更改的數(shù)據(jù)按類型分為環(huán)境(Environment)、生產(chǎn)(Production)、音頻(Audio)、視頻(Video)、圖像(Image) 5個(gè)主題發(fā)送給數(shù)據(jù)中心機(jī)房的遠(yuǎn)端服務(wù)器集群，數(shù)據(jù)中心在接收到數(shù)據(jù)后進(jìn)行解析，將環(huán)境、生產(chǎn)數(shù)據(jù)存入數(shù)據(jù)庫，將音視頻及圖像存入HDFS分布式文件系統(tǒng)中，并更新其在數(shù)據(jù)庫中的文件路徑[20]。用戶可通過Web網(wǎng)頁端及手機(jī)APP對(duì)數(shù)據(jù)實(shí)時(shí)訪問。系統(tǒng)總體拓?fù)浣Y(jié)構(gòu)如圖3所示。

圖3 系統(tǒng)總體拓?fù)浣Y(jié)構(gòu)Fig.3 Overall topology of system

2.3 系統(tǒng)功能設(shè)計(jì)

根據(jù)對(duì)不同蛋雞場(chǎng)的調(diào)研、綜合分析，設(shè)計(jì)系統(tǒng)主要功能模塊包括實(shí)時(shí)信息、歷史信息、基礎(chǔ)設(shè)施、生產(chǎn)過程管理、統(tǒng)計(jì)分析、環(huán)境警報(bào)、系統(tǒng)管理7個(gè)模塊。具體功能模塊如圖4所示。

圖4 系統(tǒng)功能模塊Fig.4 Function module of system

(1)實(shí)時(shí)信息模塊：主要負(fù)責(zé)展示雞舍的舍內(nèi)外環(huán)境、音視頻等實(shí)時(shí)信息。監(jiān)測(cè)數(shù)據(jù)通過環(huán)境監(jiān)測(cè)傳感器、拾音器、攝像頭進(jìn)行采集，并通過部署于現(xiàn)場(chǎng)的采集程序存入數(shù)據(jù)庫中，生產(chǎn)數(shù)據(jù)由生產(chǎn)人員填報(bào)。實(shí)時(shí)數(shù)據(jù)經(jīng)過分析處理，通過Web端與手機(jī)APP實(shí)時(shí)向用戶展示，便于用戶了解現(xiàn)場(chǎng)情況。

(2)歷史信息模塊：主要包括歷史音視頻及圖像數(shù)據(jù)的展示。歷史數(shù)據(jù)用于圖像分割、視頻追蹤等，將原始數(shù)據(jù)與經(jīng)算法處理后的數(shù)據(jù)存入系統(tǒng)，用戶可下載查看。

(3)基礎(chǔ)設(shè)施模塊：由于各地雞場(chǎng)情況各不相同，設(shè)置基礎(chǔ)設(shè)施模塊。用于存儲(chǔ)和展示各地蛋雞場(chǎng)的雞場(chǎng)、雞舍及舍內(nèi)外采集點(diǎn)的詳細(xì)信息，由雞場(chǎng)管理人員填寫，便于根據(jù)不同雞場(chǎng)做出不同的分析管理。

(4)生產(chǎn)過程管理模塊：主要負(fù)責(zé)對(duì)生產(chǎn)過程中自動(dòng)采集、用戶填寫的數(shù)據(jù)進(jìn)行統(tǒng)一記錄管理。包括日?qǐng)?bào)表、日盈虧表、水電消耗、蛋雞轉(zhuǎn)群、免疫記錄、藥品投入以及各項(xiàng)檢測(cè)。由雞場(chǎng)生產(chǎn)人員錄入，管理人員進(jìn)行審核，提高了工作效率，同時(shí)積累數(shù)據(jù)為后續(xù)分析提供支持。

(5)統(tǒng)計(jì)分析模塊：主要負(fù)責(zé)對(duì)收集到的生產(chǎn)數(shù)據(jù)、環(huán)境數(shù)據(jù)進(jìn)行分析，允許相關(guān)人員通過時(shí)間、雞舍號(hào)等進(jìn)行查詢，并通過曲線圖表進(jìn)行個(gè)性化展示，便于雞場(chǎng)管理人員直觀地了解雞舍的環(huán)境變化趨勢(shì)、生產(chǎn)資料消耗以及生產(chǎn)盈虧趨勢(shì)，指導(dǎo)生產(chǎn)。

(6)環(huán)境警報(bào)模塊：主要負(fù)責(zé)對(duì)環(huán)境參數(shù)進(jìn)行警報(bào)。管理人員可根據(jù)不同雞舍設(shè)置不同環(huán)境閾值，采集到的數(shù)據(jù)經(jīng)過處理與閾值進(jìn)行實(shí)時(shí)對(duì)比，超出閾值的系統(tǒng)將通過手機(jī)APP推送警報(bào)信息，便于管理人員及時(shí)查看舍內(nèi)情況，做出應(yīng)對(duì)。

(7)系統(tǒng)管理模塊：主要負(fù)責(zé)對(duì)系統(tǒng)用戶、系統(tǒng)推送信息查看管理。用戶管理即管理員可以添加、刪除用戶，并對(duì)用戶權(quán)限進(jìn)行管理，控制不同類別的用戶訪問不同模塊。推送信息管理可以查看預(yù)警信息推送情況，同時(shí)提供推送消息頁面方便通過手機(jī)APP對(duì)指定用戶或批量用戶進(jìn)行消息推送。

3 系統(tǒng)數(shù)據(jù)存儲(chǔ)設(shè)計(jì)與實(shí)現(xiàn)

3.1 系統(tǒng)數(shù)據(jù)存儲(chǔ)設(shè)計(jì)

規(guī)?；半u場(chǎng)的現(xiàn)場(chǎng)數(shù)據(jù)分別存儲(chǔ)于現(xiàn)場(chǎng)服務(wù)器與數(shù)據(jù)中心的集群服務(wù)器中。

現(xiàn)場(chǎng)服務(wù)器存儲(chǔ)近期的數(shù)據(jù)，數(shù)據(jù)量較小，日常所產(chǎn)生的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)于MySQL數(shù)據(jù)庫中。非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)于現(xiàn)場(chǎng)服務(wù)器的本地文件系統(tǒng)中。

現(xiàn)場(chǎng)服務(wù)器通過Kafka集群將數(shù)據(jù)打包發(fā)送給數(shù)據(jù)中心，存儲(chǔ)于MySQL數(shù)據(jù)庫、Hadoop集群及搭載在其上的HBase數(shù)據(jù)庫中。針對(duì)不同數(shù)據(jù)類型，數(shù)據(jù)中心對(duì)結(jié)構(gòu)化及非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)采用不同設(shè)計(jì)。

結(jié)構(gòu)化數(shù)據(jù)指蛋雞養(yǎng)殖中的生產(chǎn)數(shù)據(jù)與環(huán)境監(jiān)測(cè)數(shù)據(jù)。由于生產(chǎn)數(shù)據(jù)的數(shù)據(jù)量不大，傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)庫即可滿足其存儲(chǔ)與檢索，因此，生產(chǎn)數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫中。而環(huán)境監(jiān)測(cè)數(shù)據(jù)每分鐘采集一次，每個(gè)采集點(diǎn)每天約采集1 500條數(shù)據(jù)，每日雞場(chǎng)所產(chǎn)生的環(huán)境數(shù)據(jù)達(dá)上萬條，日積月累，傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)庫在查詢數(shù)據(jù)時(shí)需要較長(zhǎng)時(shí)間, 無法滿足實(shí)時(shí)查詢需求。由于HBase適合存儲(chǔ)處理大規(guī)模數(shù)據(jù)，并可進(jìn)行快速隨機(jī)訪問，而MySQL在存儲(chǔ)、查詢數(shù)據(jù)量較小時(shí)實(shí)時(shí)訪問速度優(yōu)勢(shì)明顯。因此，選擇MySQL + HBase作為環(huán)境數(shù)據(jù)的存儲(chǔ)數(shù)據(jù)庫。

非結(jié)構(gòu)化數(shù)據(jù)主要包括養(yǎng)殖過程中產(chǎn)生的監(jiān)控圖像數(shù)據(jù)及音視頻數(shù)據(jù)，每日每間雞舍所產(chǎn)生的數(shù)據(jù)超過100 GB。而HDFS文件系統(tǒng)因其具有高效的數(shù)據(jù)讀取及多副本存放模式，適合存儲(chǔ)海量數(shù)據(jù)，為圖像數(shù)據(jù)及音視頻數(shù)據(jù)的存儲(chǔ)提供了方便，同時(shí)HDFS自身具有副本存儲(chǔ)及機(jī)架感知策略，可以保證數(shù)據(jù)的安全性。

通過分析，現(xiàn)場(chǎng)服務(wù)器的數(shù)據(jù)存儲(chǔ)采用MySQL數(shù)據(jù)庫及本地文件系統(tǒng)。數(shù)據(jù)中心系統(tǒng)選擇采用Hadoop框架，接收各個(gè)數(shù)據(jù)采集節(jié)點(diǎn)所采集的數(shù)據(jù)，分類后存儲(chǔ)于MySQL、HBase數(shù)據(jù)庫及HDFS文件系統(tǒng)中，最終用戶可通過Web頁面端及手機(jī)APP對(duì)數(shù)據(jù)中心數(shù)據(jù)查詢分析。

3.2 基于MySQL+HBase的環(huán)境監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)設(shè)計(jì)

系統(tǒng)在環(huán)境監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)時(shí)選擇MySQL+HBase的混合存儲(chǔ)模式。MySQL存儲(chǔ)近一段時(shí)期的數(shù)據(jù)，HBase存儲(chǔ)采集到的所有數(shù)據(jù)。當(dāng)MySQL存儲(chǔ)數(shù)據(jù)超過閾值后，刪除歷史記錄。

當(dāng)數(shù)據(jù)中心集群接收到來自Kafka集群的消息后，獲取主題為環(huán)境(Environment)的消息，將消息解析后獲取環(huán)境數(shù)據(jù)，同時(shí)插入MySQL及HBase數(shù)據(jù)庫中，查詢不同的數(shù)據(jù)庫均可獲得實(shí)時(shí)數(shù)據(jù)，確保了數(shù)據(jù)查詢的實(shí)時(shí)性。

在系統(tǒng)中，采集的環(huán)境數(shù)據(jù)包括采集點(diǎn)信息(場(chǎng)區(qū)號(hào)、雞舍號(hào)、采集點(diǎn)號(hào))、采集時(shí)間及各種環(huán)境參數(shù)值，對(duì)于環(huán)境數(shù)據(jù)的查詢多為根據(jù)具體采集點(diǎn)及采集時(shí)間進(jìn)行單項(xiàng)或多項(xiàng)參數(shù)值的范圍查詢。根據(jù)需求，在MySQL數(shù)據(jù)庫中設(shè)計(jì)并實(shí)現(xiàn)二維數(shù)據(jù)表如表1所示。

表1 MySQL環(huán)境監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)表Tab.1 MySQL environment monitoring data storage

為保證查詢效率，本系統(tǒng)設(shè)置MySQL數(shù)據(jù)存儲(chǔ)時(shí)間為30 d，每個(gè)月數(shù)據(jù)記錄約為30萬條。30 d之前的數(shù)據(jù)則存入HBase中。

HBase提供了基于RowKey的單行掃描查詢、基于RowKey的范圍掃描查詢和全表掃描查詢。通過RowKey查詢效率較高，而通過列族進(jìn)行查詢則會(huì)進(jìn)行全表掃描，效率低下。因此，設(shè)計(jì)良好的RowKey對(duì)查詢性能影響極大。

HBase中的表由Region存儲(chǔ)，每個(gè)Region由StartKey和EndKey表示其范圍。而HBase初建表默認(rèn)生成一個(gè)Region，所有數(shù)據(jù)均寫入該Region中，直至數(shù)據(jù)不斷增加至一定閾值后進(jìn)行分裂(Region-split)，Region-split會(huì)消耗較多時(shí)間和資源，所以可以對(duì)HBase表進(jìn)行預(yù)分區(qū)，提前創(chuàng)建多個(gè)空Region，確定其StartKey和EndKey，從而減少Region-split，降低資源消耗。提前預(yù)分區(qū)處理的Region中，僅有一個(gè)Region無上界，不存在Endkey。新數(shù)據(jù)會(huì)根據(jù)其RowKey所在范圍被插入不同Region中。由于HBase中Rowkey按字典順序遞增，若設(shè)計(jì)的RowKey同樣按照字典順序增加，新插入的數(shù)據(jù)會(huì)被不斷寫入無上界Region中，造成寫熱點(diǎn)問題，同時(shí)預(yù)分區(qū)也無法得到有效使用。為解決這一問題，在設(shè)計(jì)RowKey時(shí)應(yīng)避免其按字母順序遞增。

根據(jù)HBase的特點(diǎn)，若按照MySQL數(shù)據(jù)庫中將雞舍號(hào)、采集點(diǎn)編號(hào)、采集時(shí)間等分別作為列族存儲(chǔ)，則在查詢一段時(shí)間的監(jiān)控?cái)?shù)據(jù)時(shí)需要進(jìn)行全表掃描，查詢耗時(shí)較長(zhǎng)，效率較低。因此，選擇將“場(chǎng)區(qū)號(hào)+雞舍號(hào)+采集點(diǎn)號(hào)_采集時(shí)間”作為RowKey，并保證RowKey中各個(gè)字段長(zhǎng)度一定，以提高查詢速度。同時(shí)，由于場(chǎng)區(qū)號(hào)采用字母+數(shù)字的格式，將場(chǎng)區(qū)號(hào)寫在開端也可避免寫入數(shù)據(jù)時(shí)RowKey的順序遞增問題。環(huán)境參數(shù)中的溫度、濕度、光照強(qiáng)度、二氧化碳濃度、氨氣濃度、粉塵濃度、氣流、氣壓等作為不同的列族，查詢時(shí)即可避免加載無關(guān)數(shù)據(jù)，從而提升速度。在建表前，根據(jù)RowKey中場(chǎng)區(qū)號(hào)及雞舍號(hào)作為預(yù)分區(qū)邊界值，調(diào)用HBase提供的API中的HBaseAdmin.creatTable(tableDescriptor,splitKeys)即可進(jìn)行預(yù)分區(qū)建表。同時(shí)，由于HBase進(jìn)行Region-split時(shí)舊Region下線，占用大量IO資源，而HBase默認(rèn)的自動(dòng)Region-split會(huì)在Region數(shù)據(jù)量到達(dá)閾值時(shí)進(jìn)行，無法控制進(jìn)行Region-split的時(shí)間。因此，系統(tǒng)選擇關(guān)閉自動(dòng)Region-split，并設(shè)置在IO資源占用較少的固定時(shí)間執(zhí)行RegionSplitter類的滾動(dòng)拆分，從而降低系統(tǒng)在高IO需求時(shí)由于Region-split占用資源而導(dǎo)致的時(shí)間消耗。

查詢數(shù)據(jù)時(shí)，如果需要查詢場(chǎng)區(qū)號(hào)為AH01，雞舍號(hào)為FD01， 采集點(diǎn)號(hào)為01， 采集時(shí)間為2017年12月，可以設(shè)置起始的RowKey為“AH01FD0101_20171201000000”，結(jié)束的RowKey為“AH01FD0101_20171231246060”，HBase會(huì)根據(jù)RowKey進(jìn)行范圍掃描查詢，從而使查詢速度得到保證。

由于MySQL在數(shù)據(jù)量較小時(shí)實(shí)時(shí)查詢能力較強(qiáng)，因此，MySQL負(fù)責(zé)近30 d數(shù)據(jù)的查詢。而查詢數(shù)據(jù)量較大或需要查詢歷史數(shù)據(jù)時(shí)，則選擇HBase進(jìn)行查詢。用戶查詢數(shù)據(jù)時(shí)需要輸入查詢起止時(shí)間，系統(tǒng)判斷輸入的起止時(shí)間是否在近30 d內(nèi)，若屬于最近30 d，則在MySQL數(shù)據(jù)庫中進(jìn)行查詢。若起止時(shí)間超出最近30 d，則在HBase數(shù)據(jù)庫中查詢。通過Java語言編程，可實(shí)現(xiàn)對(duì)MySQL及HBase的訪問控制，對(duì)MySQL的查詢通過對(duì)JDBC進(jìn)行控制，對(duì)HBase的查詢通過HBase的API進(jìn)行操作。

3.3 實(shí)驗(yàn)與結(jié)果分析

系統(tǒng)遠(yuǎn)端數(shù)據(jù)中心位于中國(guó)農(nóng)業(yè)大學(xué)網(wǎng)絡(luò)中心，系統(tǒng)硬件環(huán)境為4臺(tái)服務(wù)器的Hadoop集群，采用該集群進(jìn)行分析實(shí)驗(yàn)。其中一臺(tái)主節(jié)點(diǎn)，3臺(tái)從節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)CPU均為Intel E5-2609，主頻1.90 GHz，內(nèi)存32 GB，8 TB硬盤，操作系統(tǒng)為Ubuntu 16.04，Hadoop版本為Hadoop 2.6.5，HBase版本為HBase 1.1.12。

系統(tǒng)經(jīng)過前期運(yùn)行，已經(jīng)采集到超過5 000萬條數(shù)據(jù)。將數(shù)據(jù)同時(shí)存入MySQL及HBase數(shù)據(jù)庫中，查詢數(shù)據(jù)結(jié)果及分析如下：

(1)在MySQL及HBase中存入不同存儲(chǔ)規(guī)模的相同數(shù)據(jù)，選取不同時(shí)間段、不同蛋雞舍及不同采集點(diǎn)，對(duì)MySQL及HBase同時(shí)進(jìn)行查詢數(shù)據(jù)量為存儲(chǔ)規(guī)模20%、40%、60%、80%、100%的5次查詢，將查詢結(jié)果進(jìn)行平均，得到查詢時(shí)間如表2所示，繪制存儲(chǔ)規(guī)模為25萬至100萬條的折線圖，如圖5所示。

表2 不同存儲(chǔ)規(guī)模MySQL及HBase查詢耗時(shí)Tab.2 MySQL and HBase query time for different storage scales ms

圖5 不同存儲(chǔ)規(guī)模查詢耗時(shí)對(duì)比Fig.5 Comparison of MySQL and HBase query time for different storage scales

由表2、圖5可知，隨著存儲(chǔ)規(guī)模的增加，MySQL數(shù)據(jù)庫查詢耗時(shí)也不斷增加。存儲(chǔ)規(guī)模在500萬條時(shí)，無索引查詢已經(jīng)超過10 s，不再適合實(shí)時(shí)查詢。帶索引MySQL查詢?cè)跀?shù)據(jù)規(guī)模較小時(shí)表現(xiàn)出了良好的查詢性能，而當(dāng)存儲(chǔ)數(shù)據(jù)量接近50萬條時(shí)，其查詢速度被HBase趕超。HBase查詢時(shí)間隨存儲(chǔ)規(guī)模增加也逐漸增加，但其增長(zhǎng)較為緩和。因此，在MySQL中存儲(chǔ)約30萬條記錄較為合理。

(2)選擇不同查詢數(shù)據(jù)量，對(duì)存儲(chǔ)規(guī)模為5 000萬條的MySQL及HBase分別隨機(jī)進(jìn)行查詢，每個(gè)數(shù)據(jù)量查詢5次并將結(jié)果取平均，得到查詢時(shí)間如表3所示， 將10萬至50萬條查詢量耗時(shí)繪制折線圖，如圖6所示。

表3 不同查詢規(guī)模MySQL及HBase查詢耗時(shí)Tab.3 MySQL and HBase query time for different query scales ms

圖6 不同查詢量耗時(shí)對(duì)比Fig.6 Comparison of MySQL and HBase query time for different query scales

由圖6、表3可知，在存儲(chǔ)數(shù)據(jù)量達(dá)到5 000萬時(shí)，無索引MySQL即使在小數(shù)據(jù)量查詢時(shí)，時(shí)間也已超過50 s，在查詢500萬條數(shù)據(jù)時(shí)發(fā)生查詢連接超時(shí)。在小規(guī)模數(shù)據(jù)查詢時(shí)，由于HBase查詢需要將數(shù)據(jù)加載入內(nèi)存，總體查詢時(shí)間比帶索引MySQL查詢長(zhǎng)。隨著查詢量的增加，帶索引MySQL查詢及HBase查詢耗時(shí)均不斷增加，但HBase查詢時(shí)間增加較緩。而在查詢數(shù)據(jù)量超過20萬條時(shí)，HBase查詢?nèi)〉脙?yōu)勢(shì)，查詢性能高于帶索引MySQL。因此，選擇使用MySQL存儲(chǔ)近期數(shù)據(jù)，HBase存儲(chǔ)歷史數(shù)據(jù)，查詢數(shù)據(jù)時(shí)根據(jù)不同時(shí)間段選擇查詢不同數(shù)據(jù)庫較合理。

4 視頻分布式轉(zhuǎn)碼設(shè)計(jì)與實(shí)現(xiàn)

4.1 基于MapReduce視頻分布式轉(zhuǎn)碼設(shè)計(jì)與實(shí)現(xiàn)

系統(tǒng)需要對(duì)多個(gè)異地雞場(chǎng)進(jìn)行統(tǒng)一管理，因此需要一致的數(shù)據(jù)類型，完成對(duì)視頻數(shù)據(jù)的分布式存儲(chǔ)。由于各地雞場(chǎng)采用不同種類攝像頭，所采集到的視頻類型并不一致，包括H.264及MP4，而H.264格式視頻所占比重較大。H.264格式的視頻無法通過通用播放器播放，需要先使用專用解碼器進(jìn)行解碼，不利于集中展示[21]。另一方面也無法直接實(shí)現(xiàn)數(shù)據(jù)的分析，增加了后續(xù)視頻算法處理的復(fù)雜程度。因此，需要對(duì)視頻提前轉(zhuǎn)碼為MP4，使格式一致。運(yùn)行在各地雞場(chǎng)的系統(tǒng)根據(jù)監(jiān)控需求，視頻數(shù)據(jù)每30 min存儲(chǔ)一次，每份視頻為1.5 GB。

目前視頻的轉(zhuǎn)碼模式一般分為單點(diǎn)、分布式、面向移動(dòng)端以及基于云的轉(zhuǎn)碼[22]。單點(diǎn)轉(zhuǎn)碼使用單個(gè)服務(wù)器，實(shí)現(xiàn)簡(jiǎn)單，但速度慢，效率較低，大規(guī)模轉(zhuǎn)碼限制較大。分布式轉(zhuǎn)碼采用多臺(tái)服務(wù)器進(jìn)行轉(zhuǎn)碼，轉(zhuǎn)碼完成后再進(jìn)行合并，減少了轉(zhuǎn)碼整體時(shí)間，但實(shí)現(xiàn)復(fù)雜。面向移動(dòng)端的轉(zhuǎn)碼降低了視頻分辨率及碼率，應(yīng)用性較強(qiáng)，但降低了轉(zhuǎn)碼后視頻質(zhì)量，會(huì)對(duì)之后的視頻追蹤等算法造成影響，并不適合本系統(tǒng)?；谠频霓D(zhuǎn)碼利用企業(yè)云轉(zhuǎn)碼，減少了需要的資源，但穩(wěn)定性較難保證。因此，需要設(shè)計(jì)實(shí)現(xiàn)簡(jiǎn)單、高效、不損失視頻質(zhì)量且較為穩(wěn)定的視頻轉(zhuǎn)碼模塊。

視頻數(shù)據(jù)存儲(chǔ)于容錯(cuò)性較高、穩(wěn)定性良好的Hadoop文件系統(tǒng)HDFS上。而Hadoop的另一核心MapReduce適合對(duì)數(shù)據(jù)進(jìn)行并行處理。MapReduce使用簡(jiǎn)單，Map函數(shù)并行處理數(shù)據(jù)，Reduce函數(shù)規(guī)約數(shù)據(jù)，設(shè)計(jì)良好的Map及Reduce函數(shù)，可以實(shí)現(xiàn)視頻的分布式轉(zhuǎn)碼。

視頻數(shù)據(jù)在HDFS上通過Block進(jìn)行存儲(chǔ)，大于Block存儲(chǔ)量的視頻上傳后被分為多個(gè)塊由不同Block存儲(chǔ)。由于視頻由幀組成，Block上存儲(chǔ)的視頻可能會(huì)出現(xiàn)首尾幀不完整，而幀與幀之間具有關(guān)聯(lián)性，若直接使用Map函數(shù)通過操作視頻幀處理各Block上存儲(chǔ)的視頻塊，可能會(huì)由于幀的不完整以及與前一幀關(guān)聯(lián)而造成處理錯(cuò)誤。因此，為充分利用MapReduce的并行處理能力，需要提前對(duì)視頻數(shù)據(jù)進(jìn)行分割。視頻分割可以通過視頻處理工具FFmpeg完成。

FFmpeg[23]是一個(gè)可以運(yùn)行于Linux及Windows操作系統(tǒng)上的多媒體處理工具，可以完成音視頻的格式轉(zhuǎn)換及分割合并。FFmpeg支持mpeg、mpeg4、flv、div等多種解碼編碼。

經(jīng)過FFmpeg分割后的視頻分別由HDFS的不同Block存儲(chǔ)，同時(shí)存儲(chǔ)帶有原始文件及目標(biāo)文件路徑的文件。存儲(chǔ)完成后啟動(dòng)分布式轉(zhuǎn)碼程序，執(zhí)行Map及Reduce函數(shù)。Map函數(shù)的輸入為〈文件名，文件路徑〉，Map函數(shù)首先解析文件路徑并從HDFS中下載相應(yīng)視頻數(shù)據(jù)，然后調(diào)用FFmpeg進(jìn)行轉(zhuǎn)碼，完成后將視頻存入HDFS文件系統(tǒng)中。Map函數(shù)的輸出為〈轉(zhuǎn)碼后視頻片段的文件名，轉(zhuǎn)碼后視頻片段的文件路徑〉，被傳遞給Reduce函數(shù)進(jìn)行規(guī)約處理。Reduce函數(shù)通過Map函數(shù)傳遞的鍵值對(duì)解析出轉(zhuǎn)碼完成的視頻文件路徑并下載視頻數(shù)據(jù)至本地，然后調(diào)用FFmpeg進(jìn)行合并，合并后再將視頻數(shù)據(jù)寫入HDFS中。Map及Reduce函數(shù)流程圖如圖7所示。

圖7 Map函數(shù)、Reduce函數(shù)流程圖Fig.7 Flow chart of Map function and Reduce function

分布式轉(zhuǎn)碼模塊利用數(shù)據(jù)中心已搭建的MySQL服務(wù)器及Hadoop集群實(shí)現(xiàn)，數(shù)據(jù)中心存儲(chǔ)轉(zhuǎn)碼視頻具體流程圖如圖8所示。

圖8 數(shù)據(jù)中心視頻存儲(chǔ)轉(zhuǎn)碼流程圖Fig.8 Flow chart of transcoding

當(dāng)數(shù)據(jù)中心接收到來自Kafka集群的視頻后檢查視頻格式，若為MP4則直接存儲(chǔ)于HDFS中并將視頻編碼和存儲(chǔ)路徑等詳細(xì)信息寫入MySQL數(shù)據(jù)庫的視頻表中。若格式為H.264則將視頻分割為視頻段，然后將視頻段存儲(chǔ)于HDFS中。存儲(chǔ)完成后開始調(diào)用分布式視頻轉(zhuǎn)碼模塊，由Hadoop集群中的NameNode負(fù)責(zé)調(diào)度，執(zhí)行Map函數(shù)轉(zhuǎn)碼及Reduce函數(shù)合并，完成后再將視頻上傳至HDFS，并將信息寫入MySQL數(shù)據(jù)庫。此時(shí)系統(tǒng)中歷史視頻列表即可顯示該視頻。用戶請(qǐng)求視頻時(shí)，點(diǎn)擊歷史視頻列表中的視頻名稱，即可獲取視頻位置，從而播放或下載視頻。

4.2 分布式轉(zhuǎn)碼性能測(cè)試

實(shí)驗(yàn)在已搭建好的Hadoop集群上進(jìn)行。單點(diǎn)轉(zhuǎn)碼使用與集群中節(jié)點(diǎn)相同配置的服務(wù)器，轉(zhuǎn)碼大小為1.5 GB、格式為H.264的視頻，所需時(shí)間為193.257 s。對(duì)不同整體大小、不同分割大小的視頻進(jìn)行轉(zhuǎn)碼，分析如下：

(1)將1.5 GB的視頻分割為不同大小的片段，在集群中進(jìn)行分布式轉(zhuǎn)碼，分割片段大小及轉(zhuǎn)碼消耗的時(shí)間如圖9所示。

圖9 1.5 GB視頻不同分割大小分布式轉(zhuǎn)碼消耗時(shí)間Fig.9 Distributed transcoding time of 1.5 GB video with different segmenting sizes

由圖9可知，轉(zhuǎn)碼消耗時(shí)間隨分割視頻段大小增加不斷降低，直至分割為與HDFS的Block大小相同的128 MB時(shí)，轉(zhuǎn)碼時(shí)間最少，為94.73 s，效率較高，遠(yuǎn)小于單機(jī)轉(zhuǎn)碼時(shí)間。而在分割視頻段大于128 MB后，轉(zhuǎn)碼時(shí)間開始增加。

(2)選擇以轉(zhuǎn)碼最快的128 MB作為視頻分割大小，不同大小的視頻單機(jī)轉(zhuǎn)碼耗時(shí)及分布式轉(zhuǎn)碼耗時(shí)如圖10所示。

圖10 以128 MB分割不同大小視頻轉(zhuǎn)碼時(shí)間Fig.10 Transcoding time of different sizes of video with 128 MB segmentation

圖12 系統(tǒng)功能界面Fig.12 System application interface

由圖10分析可知，單機(jī)轉(zhuǎn)碼時(shí)間隨著視頻量增加而增加。在視頻文件較小時(shí)，分布式轉(zhuǎn)碼由于需要進(jìn)行文件的上傳、下載及集群間網(wǎng)絡(luò)通信，時(shí)間比單機(jī)轉(zhuǎn)碼長(zhǎng)，不具優(yōu)勢(shì)，當(dāng)視頻文件大于512 MB后，分布式轉(zhuǎn)碼時(shí)間開始低于單機(jī)轉(zhuǎn)碼時(shí)間。當(dāng)視頻文件達(dá)到1.4 GB時(shí)，分布式轉(zhuǎn)碼耗時(shí)達(dá)到最低，節(jié)約了56%的轉(zhuǎn)碼時(shí)間。在文件大小為1.5 GB時(shí)，節(jié)約時(shí)間為50%。因此，可以考慮在視頻存儲(chǔ)時(shí)適量降低時(shí)長(zhǎng)以減小視頻量，從而達(dá)到最佳轉(zhuǎn)碼速度。

5 系統(tǒng)應(yīng)用

系統(tǒng)Web端及手機(jī)APP客戶端已在中國(guó)農(nóng)業(yè)大學(xué)上莊試驗(yàn)站、德清源延慶生態(tài)園、德清源黃山生態(tài)園投入使用，中國(guó)農(nóng)業(yè)大學(xué)網(wǎng)絡(luò)中心作為數(shù)據(jù)中心對(duì)各養(yǎng)殖場(chǎng)數(shù)據(jù)進(jìn)行統(tǒng)一管理。用戶通過訪問Web端訪問系統(tǒng)，首先點(diǎn)擊首頁的標(biāo)注點(diǎn)選擇不同養(yǎng)殖場(chǎng)，如圖11a所示。各養(yǎng)殖場(chǎng)展示養(yǎng)殖場(chǎng)內(nèi)各雞舍信息，包括當(dāng)日的存欄數(shù)、死淘數(shù)、產(chǎn)蛋量、耗水耗料及實(shí)時(shí)溫度，如圖11b所示，點(diǎn)擊下方各菜單按鈕，可查看舍內(nèi)外環(huán)境數(shù)據(jù)及實(shí)時(shí)視頻。

圖11 Web端系統(tǒng)界面Fig.11 System interface of Web terminal

用戶進(jìn)入系統(tǒng)后臺(tái)后，可對(duì)統(tǒng)計(jì)分析數(shù)據(jù)及轉(zhuǎn)換后的視頻進(jìn)行查看，如圖12a、12b所示。用戶通過手機(jī)APP訪問系統(tǒng)，首先輸入用戶名、密碼、類別，系統(tǒng)確認(rèn)無誤后即可登錄。登錄后可查看實(shí)時(shí)環(huán)境數(shù)據(jù)，并對(duì)生產(chǎn)過程進(jìn)行管理，如圖12c、12d、12e所示。

蛋雞場(chǎng)的養(yǎng)殖人員及管理人員可以通過Web端和手機(jī)APP查看各地蛋雞舍的實(shí)時(shí)環(huán)境、生產(chǎn)信息、實(shí)時(shí)音視頻數(shù)據(jù)、統(tǒng)計(jì)分析數(shù)據(jù)，便于及時(shí)發(fā)現(xiàn)問題、做出決策，從而降低企業(yè)風(fēng)險(xiǎn)，提高動(dòng)物福利。

6 結(jié)論

(1)該智能監(jiān)測(cè)管理系統(tǒng)實(shí)現(xiàn)了對(duì)蛋雞生產(chǎn)養(yǎng)殖所產(chǎn)生的海量數(shù)據(jù)的高效存儲(chǔ)：采用MySQL + HBase數(shù)據(jù)庫的混合模式，保證了數(shù)據(jù)存儲(chǔ)和查詢的實(shí)時(shí)性，滿足大規(guī)模環(huán)境監(jiān)測(cè)數(shù)據(jù)的查詢需求。

(2)設(shè)計(jì)實(shí)現(xiàn)了基于MapReduce的分布式監(jiān)控視頻轉(zhuǎn)碼模塊，將其嵌入系統(tǒng)中，視頻傳輸完成后即可進(jìn)行轉(zhuǎn)碼，用戶無需關(guān)心各地?cái)z像頭的詳細(xì)信息即可獲得統(tǒng)一格式的監(jiān)控視頻。實(shí)驗(yàn)表明其效率高于單機(jī)轉(zhuǎn)碼，可為后續(xù)基于視頻的算法研究提供良好支持。

(3)該系統(tǒng)對(duì)蛋雞養(yǎng)殖生產(chǎn)過程進(jìn)行了數(shù)據(jù)分析，同時(shí)提供了多項(xiàng)功能，可以協(xié)助生產(chǎn)養(yǎng)殖人員實(shí)時(shí)、全方位監(jiān)控生產(chǎn)過程，對(duì)規(guī)?；半u場(chǎng)積累數(shù)據(jù)、分析決策具有重要意義。