基于Hadoop的蛋雞設(shè)施養(yǎng)殖智能監(jiān)測管理系統(tǒng)研究

孟超英 張雪彬 陳紅茜 李 輝

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

0 引言

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

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

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

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

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

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

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

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

基于Hadoop的規(guī)模化蛋雞設(shè)施養(yǎng)殖智能監(jiān)測管理系統(tǒng)運行于多地不同蛋雞養(yǎng)殖場，使用物聯(lián)網(wǎng)、云存儲、異步傳輸?shù)榷囗椉夹g(shù)構(gòu)建，向用戶提供數(shù)據(jù)的智能處理、實時展示。系統(tǒng)綜合物聯(lián)網(wǎng)[18]及云平臺架構(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)境傳感器，負責進行數(shù)據(jù)采集。采集到的數(shù)據(jù)由傳輸層通過有線網(wǎng)絡(luò)及無線網(wǎng)絡(luò)傳入基礎(chǔ)設(shè)施層?；A(chǔ)設(shè)施層提供底層的服務(wù)器等硬件資源，負責存儲數(shù)據(jù)并向中間層提供數(shù)據(jù)支撐。中間層負責數(shù)據(jù)的統(tǒng)一規(guī)劃，進而分布式存儲數(shù)據(jù)。同時，中間層提供了基于MapReduce的分布式轉(zhuǎn)碼模塊，為異構(gòu)視頻數(shù)據(jù)的展示下載提供了支持。應(yīng)用層則向用戶提供環(huán)境的實時監(jiān)測、音視頻分析、生產(chǎn)過程管理、數(shù)據(jù)圖表分析等相關(guān)用戶感興趣的服務(wù)。

2.2 系統(tǒng)總體拓撲

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

圖3 系統(tǒng)總體拓撲結(jié)構(gòu)Fig.3 Overall topology of system

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

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

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

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

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

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

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

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

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

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

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

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

規(guī)模化蛋雞場的現(xiàn)場數(shù)據(jù)分別存儲于現(xiàn)場服務(wù)器與數(shù)據(jù)中心的集群服務(wù)器中。

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

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

結(jié)構(gòu)化數(shù)據(jù)指蛋雞養(yǎng)殖中的生產(chǎn)數(shù)據(jù)與環(huán)境監(jiān)測數(shù)據(jù)。由于生產(chǎn)數(shù)據(jù)的數(shù)據(jù)量不大，傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)庫即可滿足其存儲與檢索，因此，生產(chǎn)數(shù)據(jù)存儲在MySQL數(shù)據(jù)庫中。而環(huán)境監(jiān)測數(shù)據(jù)每分鐘采集一次，每個采集點每天約采集1 500條數(shù)據(jù)，每日雞場所產(chǎn)生的環(huán)境數(shù)據(jù)達上萬條，日積月累，傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)庫在查詢數(shù)據(jù)時需要較長時間, 無法滿足實時查詢需求。由于HBase適合存儲處理大規(guī)模數(shù)據(jù)，并可進行快速隨機訪問，而MySQL在存儲、查詢數(shù)據(jù)量較小時實時訪問速度優(yōu)勢明顯。因此，選擇MySQL + HBase作為環(huán)境數(shù)據(jù)的存儲數(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ù)讀取及多副本存放模式，適合存儲海量數(shù)據(jù)，為圖像數(shù)據(jù)及音視頻數(shù)據(jù)的存儲提供了方便，同時HDFS自身具有副本存儲及機架感知策略，可以保證數(shù)據(jù)的安全性。

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

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

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

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

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

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

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

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

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

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

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

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

3.3 實驗與結(jié)果分析

系統(tǒng)遠端數(shù)據(jù)中心位于中國農(nóng)業(yè)大學網(wǎng)絡(luò)中心，系統(tǒng)硬件環(huán)境為4臺服務(wù)器的Hadoop集群，采用該集群進行分析實驗。其中一臺主節(jié)點，3臺從節(jié)點。每個節(jié)點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)過前期運行，已經(jīng)采集到超過5 000萬條數(shù)據(jù)。將數(shù)據(jù)同時存入MySQL及HBase數(shù)據(jù)庫中，查詢數(shù)據(jù)結(jié)果及分析如下：

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

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

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

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

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

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

圖6 不同查詢量耗時對比Fig.6 Comparison of MySQL and HBase query time for different query scales

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 結(jié)論

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

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

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