基于Hadoop的蛋雞設施養殖智能監測管理系統研究

孟超英 張雪彬 陳紅茜 李 輝

(1.中國農業大學信息與電氣工程學院， 北京 100083； 2.中國農業大學網絡中心， 北京 100083)

0 引言

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

在前期物聯網數據采集系統的基礎上，本文設計基于Hadoop的規?；半u設施養殖智能監測管理系統，使用Hadoop框架及其生態系統對規模化蛋雞養殖產生的生產環境數據、生產過程數據及現場監控視頻數據進行高效存儲、處理和分析，從而進行實時監測、統一管理。

1 Hadoop及其生態系統

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

圖1 Hadoop2.0生態系統Fig.1 Hadoop2.0 ecosystem

Hadoop框架由2個核心設計組成：分布式文件系統HDFS和分布式并行計算框架MapReduce[10-12]。HDFS[13-14]作為Hadoop的數據存儲核心，具有高容錯性、高吞吐量等特點。可以高效存儲蛋雞生產養殖中所產生的異構數據。MapReduce[15]用于海量數據的并行運算，為蛋雞舍監控視頻的并行處理提供了支撐。而Hadoop生態系統中的HBase[16-17]是一個基于HDFS的分布式非關系型數據庫，支持數據的隨機查找，能夠處理大規模數據，適合海量環境監測數據的實時查詢。

2 系統設計

2.1 系統總體架構

基于Hadoop的規?；半u設施養殖智能監測管理系統運行于多地不同蛋雞養殖場，使用物聯網、云存儲、異步傳輸等多項技術構建，向用戶提供數據的智能處理、實時展示。系統綜合物聯網[18]及云平臺架構[19]，系統總體架構如圖2所示。自下而上包括感知層、傳輸層、基礎設施層、中間層及應用層。

圖2 系統總體架構Fig.2 Overall architecture of system

感知層集成了攝像頭、拾音器及各種環境傳感器，負責進行數據采集。采集到的數據由傳輸層通過有線網絡及無線網絡傳入基礎設施層。基礎設施層提供底層的服務器等硬件資源，負責存儲數據并向中間層提供數據支撐。中間層負責數據的統一規劃，進而分布式存儲數據。同時，中間層提供了基于MapReduce的分布式轉碼模塊，為異構視頻數據的展示下載提供了支持。應用層則向用戶提供環境的實時監測、音視頻分析、生產過程管理、數據圖表分析等相關用戶感興趣的服務。

2.2 系統總體拓撲

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

圖3 系統總體拓撲結構Fig.3 Overall topology of system

2.3 系統功能設計

根據對不同蛋雞場的調研、綜合分析，設計系統主要功能模塊包括實時信息、歷史信息、基礎設施、生產過程管理、統計分析、環境警報、系統管理7個模塊。具體功能模塊如圖4所示。

圖4 系統功能模塊Fig.4 Function module of system

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

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

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

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

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

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

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

3 系統數據存儲設計與實現

3.1 系統數據存儲設計

規?；半u場的現場數據分別存儲于現場服務器與數據中心的集群服務器中。

現場服務器存儲近期的數據，數據量較小，日常所產生的結構化數據存儲于MySQL數據庫中。非結構化數據存儲于現場服務器的本地文件系統中。

現場服務器通過Kafka集群將數據打包發送給數據中心，存儲于MySQL數據庫、Hadoop集群及搭載在其上的HBase數據庫中。針對不同數據類型，數據中心對結構化及非結構化數據的存儲采用不同設計。

結構化數據指蛋雞養殖中的生產數據與環境監測數據。由于生產數據的數據量不大，傳統的結構化數據庫即可滿足其存儲與檢索，因此，生產數據存儲在MySQL數據庫中。而環境監測數據每分鐘采集一次，每個采集點每天約采集1 500條數據，每日雞場所產生的環境數據達上萬條，日積月累，傳統的結構化數據庫在查詢數據時需要較長時間, 無法滿足實時查詢需求。由于HBase適合存儲處理大規模數據，并可進行快速隨機訪問，而MySQL在存儲、查詢數據量較小時實時訪問速度優勢明顯。因此，選擇MySQL + HBase作為環境數據的存儲數據庫。

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

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

3.2 基于MySQL+HBase的環境監測數據存儲設計

系統在環境監測數據存儲時選擇MySQL+HBase的混合存儲模式。MySQL存儲近一段時期的數據，HBase存儲采集到的所有數據。當MySQL存儲數據超過閾值后，刪除歷史記錄。

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

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

表1 MySQL環境監測數據存儲表Tab.1 MySQL environment monitoring data storage

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

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

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

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

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

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

3.3 實驗與結果分析

系統遠端數據中心位于中國農業大學網絡中心，系統硬件環境為4臺服務器的Hadoop集群，采用該集群進行分析實驗。其中一臺主節點，3臺從節點。每個節點CPU均為Intel E5-2609，主頻1.90 GHz，內存32 GB，8 TB硬盤，操作系統為Ubuntu 16.04，Hadoop版本為Hadoop 2.6.5，HBase版本為HBase 1.1.12。

系統經過前期運行，已經采集到超過5 000萬條數據。將數據同時存入MySQL及HBase數據庫中，查詢數據結果及分析如下：

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

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

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

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

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

表3 不同查詢規模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可知，在存儲數據量達到5 000萬時，無索引MySQL即使在小數據量查詢時，時間也已超過50 s，在查詢500萬條數據時發生查詢連接超時。在小規模數據查詢時，由于HBase查詢需要將數據加載入內存，總體查詢時間比帶索引MySQL查詢長。隨著查詢量的增加，帶索引MySQL查詢及HBase查詢耗時均不斷增加，但HBase查詢時間增加較緩。而在查詢數據量超過20萬條時，HBase查詢取得優勢，查詢性能高于帶索引MySQL。因此，選擇使用MySQL存儲近期數據，HBase存儲歷史數據，查詢數據時根據不同時間段選擇查詢不同數據庫較合理。

4 視頻分布式轉碼設計與實現

4.1 基于MapReduce視頻分布式轉碼設計與實現

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

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

視頻數據存儲于容錯性較高、穩定性良好的Hadoop文件系統HDFS上。而Hadoop的另一核心MapReduce適合對數據進行并行處理。MapReduce使用簡單，Map函數并行處理數據，Reduce函數規約數據，設計良好的Map及Reduce函數，可以實現視頻的分布式轉碼。

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

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

經過FFmpeg分割后的視頻分別由HDFS的不同Block存儲，同時存儲帶有原始文件及目標文件路徑的文件。存儲完成后啟動分布式轉碼程序，執行Map及Reduce函數。Map函數的輸入為〈文件名，文件路徑〉，Map函數首先解析文件路徑并從HDFS中下載相應視頻數據，然后調用FFmpeg進行轉碼，完成后將視頻存入HDFS文件系統中。Map函數的輸出為〈轉碼后視頻片段的文件名，轉碼后視頻片段的文件路徑〉，被傳遞給Reduce函數進行規約處理。Reduce函數通過Map函數傳遞的鍵值對解析出轉碼完成的視頻文件路徑并下載視頻數據至本地，然后調用FFmpeg進行合并，合并后再將視頻數據寫入HDFS中。Map及Reduce函數流程圖如圖7所示。

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

分布式轉碼模塊利用數據中心已搭建的MySQL服務器及Hadoop集群實現，數據中心存儲轉碼視頻具體流程圖如圖8所示。

圖8 數據中心視頻存儲轉碼流程圖Fig.8 Flow chart of transcoding

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

4.2 分布式轉碼性能測試

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

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

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

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

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

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

圖12 系統功能界面Fig.12 System application interface

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

5 系統應用

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

圖11 Web端系統界面Fig.11 System interface of Web terminal

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

蛋雞場的養殖人員及管理人員可以通過Web端和手機APP查看各地蛋雞舍的實時環境、生產信息、實時音視頻數據、統計分析數據，便于及時發現問題、做出決策，從而降低企業風險，提高動物福利。

6 結論

(1)該智能監測管理系統實現了對蛋雞生產養殖所產生的海量數據的高效存儲：采用MySQL + HBase數據庫的混合模式，保證了數據存儲和查詢的實時性，滿足大規模環境監測數據的查詢需求。

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

(3)該系統對蛋雞養殖生產過程進行了數據分析，同時提供了多項功能，可以協助生產養殖人員實時、全方位監控生產過程，對規?；半u場積累數據、分析決策具有重要意義。