文/陳娟 劉偉康 堯港東

0 引言

隨著信息化技術(shù)的發(fā)展以及傳感器技術(shù) 的進(jìn)步，信息化技術(shù)在農(nóng)業(yè)中的應(yīng)用越來越廣泛，國(guó)內(nèi)越來越多的果園正在使用基于農(nóng)業(yè)信息化技術(shù)構(gòu)建農(nóng)情信息采集系統(tǒng)、灌溉控制系統(tǒng)等，數(shù)字果園技術(shù)取得了巨大的進(jìn)展，久而久之，這些系統(tǒng)上儲(chǔ)存的數(shù)據(jù)量也將越來越大，超出了單臺(tái)機(jī)器能夠存儲(chǔ)和處理的能力，因此，如何高效存儲(chǔ)和管理這些數(shù)據(jù)成為了當(dāng)前農(nóng)情信息數(shù)據(jù)存 儲(chǔ)研究的核心問題。

果園農(nóng)情信息中存在海量小文件，包括圖片、視頻及傳感器文本等格式。隨著智慧農(nóng)業(yè)的發(fā)展，小文件存儲(chǔ)逐漸成為農(nóng)情信息存儲(chǔ)的主要方式，小文件數(shù)量的累計(jì)以及目前的存儲(chǔ)方式大多存在容災(zāi)性能差、數(shù)據(jù)讀取寫入緩慢等問題，難以支持大數(shù)據(jù)的海量寫入與讀取。

基于上述現(xiàn)狀，本文通過分析試驗(yàn)提出一種基于Hadoop的果園農(nóng)情信息大數(shù)據(jù)平臺(tái)，以期解決三方面問題：一是利用Hadoop生態(tài)系統(tǒng)中的高可用機(jī)制解決傳統(tǒng)數(shù)據(jù)存儲(chǔ)系統(tǒng)容災(zāi)性能差的問題；二是采用MySQL+HBase的混合存儲(chǔ)方式解決系統(tǒng)數(shù)據(jù)讀取寫入緩慢的問題；三是設(shè)計(jì)基于貪心算法的 多級(jí)處理框架解決系統(tǒng)小文件存儲(chǔ)的問題。

1 材料與方法

1.1 試驗(yàn)材料

設(shè)置果園農(nóng)情信息大數(shù)據(jù)平臺(tái)系統(tǒng)（以下簡(jiǎn)稱“系統(tǒng)”）的硬件環(huán)境為3臺(tái)虛擬機(jī)的Hadoop集群，采用該集群進(jìn)行分析試驗(yàn)。其中，1臺(tái)作為主節(jié)點(diǎn)、2臺(tái)為從節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)分配2GB內(nèi)存，硬盤40G，搭載64位的Centos7操作系統(tǒng)，Hadoop版本為Hadoop2.6.0，HBase版本為HBase1.1.12。

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

1.2.1 總體結(jié)構(gòu)設(shè)計(jì)

基于Hadoop的果園農(nóng)情信息大數(shù)據(jù)平臺(tái)可用于管理多個(gè)果園，使用無(wú)線傳感器網(wǎng)絡(luò)、大數(shù)據(jù)等技術(shù)構(gòu)建。從果園農(nóng)情信息數(shù)據(jù)的特征出發(fā)，結(jié)合Hadoop生態(tài)系統(tǒng)，考慮系統(tǒng)的高容災(zāi)性、高效讀寫、小文件處理等因素，自上而下將系統(tǒng)分為應(yīng)用層、服務(wù)層以及存儲(chǔ)層。系統(tǒng)總體架構(gòu)如圖1所示。

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

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

系統(tǒng)功能可根據(jù)需求而不同，以試驗(yàn)中所涉及的果園為例，系統(tǒng)主要功能包括實(shí)時(shí)信息、歷史信息、設(shè)備狀態(tài)、統(tǒng)計(jì)分析、環(huán)境警報(bào)、系統(tǒng)管理（見圖2）。

圖2 系統(tǒng)功能模塊

其中，實(shí)時(shí)信息模塊主要負(fù)責(zé)展示果園內(nèi)土壤的溫濕度、光照強(qiáng)度以及現(xiàn)場(chǎng)視頻等實(shí)時(shí)信息；歷 史信息模塊主要用于存儲(chǔ)果園中歷史數(shù)據(jù)，如歷史環(huán)境數(shù)據(jù)及歷史圖像采集數(shù)據(jù)；設(shè)備狀態(tài)信息主要包括果園中各個(gè)電磁閥狀態(tài)信息以及各個(gè)節(jié)點(diǎn)的電池電量信息，可以方便地查看果園中各個(gè)采集節(jié)點(diǎn)的在線狀態(tài)；統(tǒng)計(jì)分析模塊主要負(fù)責(zé)對(duì)采集到的環(huán)境數(shù)據(jù)進(jìn)行分析，允許用戶進(jìn)行多點(diǎn)查詢以及多日查詢，而且數(shù)據(jù)可通過曲線圖表進(jìn)行個(gè)性化展示，使得果農(nóng)可以直觀地了解果園的環(huán)境變化趨勢(shì)，一定程度上為果農(nóng)管理果園提供了便捷；環(huán)境警報(bào)模塊主要負(fù)責(zé)監(jiān)控果園環(huán)境是否出現(xiàn)異常情況，當(dāng)某項(xiàng)環(huán)境數(shù)據(jù)不在預(yù)設(shè)好的閾值空間時(shí)，該模塊將直接通過手機(jī)APP推送報(bào)警信息；系統(tǒng)管理模塊主要負(fù)責(zé)設(shè)計(jì)用戶的登錄信息以及果園的基本信息，用戶的登錄信息包括用戶賬號(hào)密碼的存儲(chǔ)設(shè)計(jì)以及新增用戶的功能設(shè)計(jì)，果園基本信息主要負(fù)責(zé)描述果樹的基本信息。

1.3 關(guān)鍵技術(shù)設(shè)計(jì)

1.3.1 基于MySQL+HBase的混合存儲(chǔ)方式設(shè)計(jì)

系統(tǒng)采取雙數(shù)據(jù)庫(kù)互補(bǔ)的存儲(chǔ)方式存儲(chǔ)結(jié)構(gòu)化的數(shù)據(jù)。其中，MySQL數(shù)據(jù)庫(kù)負(fù)責(zé)存儲(chǔ)短期內(nèi)的數(shù)據(jù)；HBase數(shù)據(jù)庫(kù)負(fù)責(zé)存儲(chǔ)采集的所有數(shù)據(jù)。將實(shí)時(shí)數(shù)據(jù)同時(shí)存儲(chǔ)在MySQL和HBase，近期數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中，并提供實(shí)時(shí)的訪問接口；當(dāng)MySQL數(shù)據(jù)庫(kù)中的數(shù)據(jù)超過一定的閾值時(shí)，對(duì)數(shù)據(jù)進(jìn)行更新。

1.3.2 MySQL數(shù)據(jù)庫(kù)存儲(chǔ)表設(shè)計(jì)

為方便環(huán)境數(shù)據(jù)的查詢及存儲(chǔ)，同時(shí)考慮到果農(nóng)對(duì)于環(huán)境數(shù)據(jù)的查詢多為根據(jù)具體采集點(diǎn)及采集時(shí)間進(jìn)行單項(xiàng)或多項(xiàng)參數(shù)值的范圍查詢，因此根據(jù)需求，在MySQL數(shù)據(jù)庫(kù)中設(shè)計(jì)并實(shí)現(xiàn)二維數(shù)據(jù)表如表1所示。具體需要采集的環(huán)境數(shù)據(jù)包括網(wǎng)關(guān)號(hào)、節(jié)點(diǎn)號(hào)、節(jié)點(diǎn)經(jīng)緯度坐標(biāo)、采集時(shí)間及各種環(huán)境參數(shù)值。

表1 NySQL環(huán)境監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)表

1.3.3 HBase數(shù)據(jù)庫(kù)存儲(chǔ)表設(shè)計(jì)

HBase數(shù)據(jù)庫(kù)存儲(chǔ)表的設(shè)計(jì)主要分為行鍵（RowKey）的設(shè)計(jì)以及列族的設(shè)計(jì)。RowKey的設(shè)計(jì)是指HBase中的存儲(chǔ)表位于Region塊中，Region的范圍由StartKey和EndKey確定，當(dāng)一個(gè)Region中的空間存儲(chǔ)不了整個(gè)表時(shí)，會(huì)自動(dòng)進(jìn)行分裂產(chǎn)生下一個(gè)Region塊，但是每個(gè)自動(dòng)分裂會(huì)消耗很多時(shí)間，所以需要對(duì)存儲(chǔ)表進(jìn)行預(yù)分區(qū)，規(guī)劃好多個(gè)Region塊給用來存儲(chǔ)一個(gè)表的數(shù)據(jù)。預(yù)分區(qū)后的Region塊中沒有EndKey，數(shù)據(jù)會(huì)根據(jù)HBase中RowKey的位置插入不同的Region。但是，RowKey的默認(rèn)設(shè)計(jì)是按照字典順序進(jìn)行遞增，F(xiàn)lume監(jiān)聽的數(shù)據(jù)會(huì)不斷地插入Region中，造成寫熱點(diǎn)問題。為了解決這個(gè)問題，本文所用RowKey格式為“果園ID+網(wǎng)關(guān)號(hào)+節(jié)點(diǎn)號(hào)+采集時(shí)間”，既能保證RowKey的唯一性，又能保證RowKey的固定長(zhǎng)度。

列族的設(shè)計(jì)：根據(jù)遠(yuǎn)程服務(wù)器中的數(shù)據(jù)表設(shè)計(jì)，HBase的列族包括用戶信息、生長(zhǎng)環(huán)境信息、地理位置信息。列族用戶信息的列名包括用戶名稱、果園名稱等；列族生長(zhǎng)環(huán)境信息包括列名土壤溫度、土壤濕度等；列族地理位置信息包含列名經(jīng)度、緯度等。

1.4 基于貪心算法的小文件多級(jí)處理模塊設(shè)計(jì)

果園農(nóng)情信息大數(shù)據(jù)平臺(tái)在長(zhǎng)期運(yùn)行后積累了大量的小文件數(shù)據(jù)，嚴(yán)重影響了系統(tǒng)的性能。為了解決大量小文件存儲(chǔ)帶來的問題，Hadoop社區(qū)提出了三種解決方案：Hadoop Arichive、Sequence File、MapFile，但是這幾種方案的實(shí)現(xiàn)原理都是將小文件按照順序合并成大文件，再將合并后的大文件存放到HDFS中，盡管可以促使系統(tǒng)中文件數(shù)量大大減少，從而降低存儲(chǔ)文件所需要的節(jié)點(diǎn)內(nèi)存和元數(shù)據(jù)數(shù)量，以此實(shí)現(xiàn)提升系統(tǒng)性能的目的，但是目前的合并方式會(huì)導(dǎo)致諸多新的問題，例如跨塊儲(chǔ)存、合并效率不高等。針對(duì)這些問題，本文提出了一種新的小文件多級(jí)處理模塊。

1.4.1 基于貪心算法的文件合并方法設(shè)計(jì)

在傳統(tǒng)的文件合并方式中，文件大都按照順序合并，一旦合并后文件的大小超過了block塊的大小就停止合并，這種合并方式會(huì)使得每個(gè)block塊都沒有得到充分的利用。圖3（a）所示為傳統(tǒng)合并方式的效果，其中，淺色部分為一個(gè)空的block塊，深色部分A－G表示6個(gè)文件塊。按照順序合并的方式，最終可以將6個(gè)文件塊合并到4個(gè)block塊中，每個(gè)block塊都會(huì)有很大的空間沒有得到使用。

為了改善傳統(tǒng)合并方式的存儲(chǔ)性能，本文設(shè)計(jì)了基于貪心算法的文件合并方式。貪心算法是指在對(duì)一個(gè)問題進(jìn)行求解時(shí)，每一步都做作出在當(dāng)前看起來是最好的選擇。圖3（b）為基于貪心算法的文件合并方式，在存入文件A之后，計(jì)算A所在block塊剩余的內(nèi)存空間，然后尋找剩余文件中大小合適的文件存儲(chǔ)到該block塊中；同理依次完成其他文件的存儲(chǔ)。與傳統(tǒng)文件合并方式相比，基于貪心算法的文件合并方式用了更少的塊存儲(chǔ)同樣大小、數(shù)量的文件。

圖3 系統(tǒng)內(nèi)的文件合并方式

利用貪心算法的思想，在對(duì)文件進(jìn)行合并時(shí)，先獲取所有文件的大小作為value值與文件序列號(hào)組成key-value對(duì)緩存在Redis數(shù)據(jù)庫(kù)中，當(dāng)一個(gè)block即將填滿，對(duì)后續(xù)的小文件進(jìn)行遍歷，找到最適合該block塊存儲(chǔ)的文件。

1.4.2 小文件多級(jí)處理模塊設(shè)計(jì)

小文件多級(jí)處理模塊的作用是在把文件存進(jìn)Hadoop的分布式文件系統(tǒng)（HDFS）前，對(duì)文件所進(jìn)行的多級(jí)處理。主要有以下幾個(gè)部分組成（見圖4）。

圖4 加入了小文件處理模塊的HDFS系統(tǒng)架構(gòu)

（1）文件預(yù)處理模塊。該模塊主要對(duì)文件進(jìn)行預(yù)處理操作：以4.3MB為分界線，將文件分成小文件和非小文件，并將小文件按照文件大小進(jìn)行排序。

（2）文件合并模塊。引入基于貪心算法的文件合并方式對(duì)文件進(jìn)行合并，使得HDFS上的每個(gè)塊文件能夠得到最大程度的利用，避免塊文件留下太多空白區(qū)間。

（3）文件二級(jí)索引模塊。以文件存儲(chǔ)日期為依據(jù)設(shè)置一級(jí)索引，以文件名和文件大小設(shè)置二級(jí)索引。與HAR歸檔不同的是，二級(jí)索引存儲(chǔ)在DataNode節(jié)點(diǎn)上，減小NameNode內(nèi)存的占用。

（4）緩存模塊。在用戶進(jìn)行文件的讀取操作時(shí)，為了加快讀取速度，設(shè)置緩存模塊。這部分統(tǒng)計(jì)用戶操作文件的次數(shù)，并按次數(shù)從高到低將文件存儲(chǔ)在緩存區(qū)。

1.4.3 小文件多級(jí)處理模塊文件讀寫流程設(shè)計(jì)

由于在原生的HDFS架構(gòu)前增加了新的文件處理層，原始的HDFS讀寫流程對(duì)于新的系統(tǒng)架構(gòu)不再適用，本文針對(duì)新的系統(tǒng)架構(gòu)設(shè)計(jì)了文件讀寫流程。

文件讀取的具體操作步驟包括從用戶執(zhí)行讀取文件操作到文件讀取結(jié)果返回給用戶等，直到讀取文件操作完成，相應(yīng)數(shù)據(jù)流關(guān)閉。操作流程見圖5（a）。

文件寫入具體操作步驟包括從用戶執(zhí)行寫入文件操作、發(fā)出文件寫入請(qǐng)求到文件處理層到文件寫入結(jié)果返回給用戶等，直至寫入文件操作完成，相應(yīng)數(shù)據(jù)流關(guān)閉。操作流程見圖5（b）。

圖5 系統(tǒng)內(nèi)的文件操作流程

1.5 試驗(yàn)方法

在果園農(nóng)情信息大數(shù)據(jù)平臺(tái)中存儲(chǔ)了從網(wǎng)站http://www.meteomanz.com/上爬取的果園當(dāng)?shù)貧庀髷?shù)據(jù)，爬取的數(shù)據(jù)是2017年1月1日至2020年1月1日廣西壯族自治區(qū)梧州市昭平縣北陀鎮(zhèn)的氣象數(shù)據(jù)，以及廣東省惠州市龍門縣的氣象數(shù)據(jù)，共約70000個(gè)文件做存儲(chǔ)試驗(yàn)，對(duì)比HDFS原生存儲(chǔ)方式、Hadoop社區(qū)提出的三種改進(jìn)方案以及本文提出的小文件多級(jí)處理設(shè)計(jì)方案(MFM)在不同文件數(shù)量存儲(chǔ)時(shí)所占用的NameNode內(nèi)存、小文件合并后大文件的個(gè)數(shù)。

試驗(yàn)步驟如下：首先啟動(dòng)Hadoop集群，在HDFS上創(chuàng)建一個(gè)空目錄，記錄此時(shí)的NameNode內(nèi)存占用storage00，然后存入1000個(gè)小文件，記錄NameNode內(nèi) 存 占 用storage01，storage01與storage00相減得到大致的HDFS原生存儲(chǔ)方式的內(nèi)存消耗。

然后在虛擬機(jī)中執(zhí)行HAR歸檔的命令，得到歸檔后的文件，記錄此時(shí)NameNode內(nèi)存占用storage02，與storage01相減得到HAR歸檔方式下NameNode的內(nèi)存消耗。在虛擬機(jī)中執(zhí)行SequenceFile、Map-File、MFM的Jar包程序，以存儲(chǔ)小文件的目錄作為輸入，輸出到新的目錄下面，記錄兩個(gè)Jar包執(zhí)行后的NameNode內(nèi)存，最終得到SequenceFile、MapFile、MFM方式下NameNode的內(nèi)存消耗。

當(dāng)在HDFS上依次存儲(chǔ)1000、5000、10000、20000個(gè)文件時(shí)，重復(fù)試驗(yàn)步驟，記錄試驗(yàn)數(shù)據(jù)。

2 結(jié)果與分析

2.1 數(shù)據(jù)查詢?cè)囼?yàn)結(jié)果與分析

將系統(tǒng)前期運(yùn)行所采集的5000萬(wàn)條數(shù)據(jù)同時(shí)存入MySQL及HBase數(shù)據(jù)庫(kù)中，對(duì)其進(jìn)行數(shù)據(jù)查詢并分析。

（1）在MySQL及HBase中存入1萬(wàn)條到200萬(wàn)條不同規(guī)模的相同數(shù)據(jù)，在兩種數(shù)據(jù)庫(kù)中對(duì)同一種數(shù)據(jù)查詢5次，將查詢時(shí)間進(jìn)行平均，得到查詢時(shí)間如表2所示，繪制存儲(chǔ)規(guī)模為1萬(wàn)條至200萬(wàn)條的折線圖，如圖6所示。

由表2、圖6可知，隨著存儲(chǔ)數(shù)據(jù)量的增加，MySQL數(shù)據(jù)庫(kù)查詢耗時(shí)也不斷增加，當(dāng)存儲(chǔ)的數(shù)據(jù)量大于50萬(wàn)條時(shí)，MySQL的查詢速度已經(jīng)遠(yuǎn)遠(yuǎn)地慢于HBase的查詢速度。MySQL查詢?cè)跀?shù)據(jù)規(guī)模較小時(shí)表現(xiàn)出了良好的查詢性能，而當(dāng)存儲(chǔ)數(shù)據(jù)量接近50萬(wàn)條時(shí)，其查詢速度被HBase趕超。HBase查詢時(shí)間隨存儲(chǔ)規(guī)模增加也逐漸增加，但增長(zhǎng)較為緩和。

表2 不同存儲(chǔ)規(guī)模下NySQL及HBase查詢耗時(shí)

圖6 系統(tǒng)不同存儲(chǔ)規(guī)模查詢耗時(shí)對(duì)比

（2）選擇不同查詢結(jié)果數(shù)據(jù)量，考慮到查詢結(jié)果可能也存在數(shù)據(jù)量的差異，對(duì)存儲(chǔ)規(guī)模為200萬(wàn)條的MySQL及HBase分別隨機(jī)進(jìn)行查詢，每個(gè)數(shù)據(jù)量查詢5次并將結(jié)果取平均，得到查詢時(shí)間如表3所示，1千條至50萬(wàn)條查詢量耗時(shí)情況如圖7所示。

表3 不同查詢規(guī)模下NySQL及HBase查詢耗時(shí)

圖7 系統(tǒng)不同查詢量耗時(shí)對(duì)比

在存儲(chǔ)數(shù)據(jù)量達(dá)到200萬(wàn)條時(shí)，MySQL數(shù)據(jù)庫(kù)的查詢速度已經(jīng)整體差于HBase數(shù)據(jù)庫(kù)；當(dāng)數(shù)據(jù)查詢規(guī)模大于5萬(wàn)條時(shí)，兩者查詢速度差距迅速拉大。因此，對(duì)歷史數(shù)據(jù)存儲(chǔ)選用HBase比較合適。試驗(yàn)結(jié)果表明，在對(duì)數(shù)據(jù)存儲(chǔ)和查詢的問題上，50萬(wàn)條以下的數(shù)據(jù)量，MySQL數(shù)據(jù)庫(kù)優(yōu)于HBase數(shù)據(jù)庫(kù)；當(dāng)數(shù)據(jù)量大于50萬(wàn)條時(shí)，HBase數(shù)據(jù)庫(kù)更優(yōu)。在數(shù)據(jù)存儲(chǔ)前根據(jù)數(shù)據(jù)量大小選擇優(yōu)勢(shì)互補(bǔ)的混合存儲(chǔ)方式，而不采用單一數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)，通過此類方式可以更好地應(yīng)對(duì)數(shù)據(jù)量的增加，尤其是農(nóng)業(yè)生產(chǎn)中存在大量數(shù)據(jù)量的情況。

2.2 小文件存儲(chǔ)試驗(yàn)結(jié)果與分析

小文件存儲(chǔ)試驗(yàn)最終得到的結(jié)果如表4所示；不同存儲(chǔ)方案對(duì)應(yīng)在集群中NameNode消耗的內(nèi)存上如圖8所示。隨著集群上小文件數(shù)量成倍增加，HDFS原生存儲(chǔ)方式下NameNode內(nèi)存的消耗也成倍增加。Hadoop社區(qū)推出的小文件處理方案（HAR，SF，MF）在處理20000個(gè)小文件的存儲(chǔ)時(shí)，分別減小了內(nèi)存占用77.5%、77.8%、78.2%；而本研究所提出的小文件多級(jí)處理方案在處理20000個(gè)小文件的存儲(chǔ)時(shí)，減小80%內(nèi)存占用，內(nèi)存占用率明顯低于其他方案，更加適合農(nóng)業(yè)生產(chǎn)中海量小文件存儲(chǔ)的應(yīng)用場(chǎng)景。

表4 不同儲(chǔ)存方式下的NameNode內(nèi)存消耗

圖8 不同方案下的NameNode內(nèi)存消耗對(duì)比

3 結(jié)論與討論

為解決數(shù)字果園因海量數(shù)據(jù)衍生的問題，本文提出“MySQL+HBase”的混合存儲(chǔ)方式及基于貪心算法的小文件多級(jí)處理方案，并在廣西梧州柑橘園以及惠州龍門柑橘果園進(jìn)行了示范應(yīng)用，結(jié)論如下：

（1）在優(yōu)化數(shù)據(jù)存儲(chǔ)查詢方面，與傳統(tǒng)的MySQL數(shù)據(jù)庫(kù)存儲(chǔ)方式相比，“MySQL+HBase”的數(shù)據(jù)存儲(chǔ)方式能夠保持在百萬(wàn)條以下數(shù)據(jù)查詢速度變化不大的情況下有效地提升百萬(wàn)條級(jí)別以上的數(shù)據(jù)查詢速度達(dá)2倍以上。

（2）在小文件存儲(chǔ)方面，小文件多級(jí)處理方案能夠有效減小Namenode內(nèi)存占用80%以上。

綜上，本文認(rèn)為，大數(shù)據(jù)平臺(tái)致力于為果園信息的存儲(chǔ)及查詢服務(wù)只是果園生產(chǎn)、管理中的重要環(huán)節(jié)，尚不能達(dá)到智慧果園的全部要求，因此，下一步重點(diǎn)將大數(shù)據(jù)平臺(tái)與專家系統(tǒng)、決策系統(tǒng)等結(jié)合起來，建立果園大數(shù)據(jù)的模型，實(shí)現(xiàn)由大數(shù)據(jù)驅(qū)動(dòng)的智慧果園管理，為果園生產(chǎn)、管理提供可實(shí)際應(yīng)用的解決方案。