基于Hadoop的葡萄種植環(huán)境數(shù)據(jù)處理及性能測試

袁偉　羅麗瓊　趙路等

摘要：隨著農(nóng)業(yè)大數(shù)據(jù)時(shí)代的來臨，傳統(tǒng)串行程序及關(guān)系數(shù)據(jù)庫已經(jīng)不能滿足對大數(shù)據(jù)處理的需求，使用分布式平臺對數(shù)據(jù)進(jìn)行處理逐漸取代傳統(tǒng)的數(shù)據(jù)處理技術(shù)。本文使用Hadoop分布式平臺，結(jié)合非關(guān)系型數(shù)據(jù)庫Hbase和并行編程模型MapReduce，對香格里拉地區(qū)釀酒葡萄種植區(qū)的環(huán)境數(shù)據(jù)的存儲和計(jì)算進(jìn)行了設(shè)計(jì)，測試了Hbase對數(shù)據(jù)的存儲性能以及MapReduce用于回歸分析的性能，并將MapReduce并行計(jì)算程序與單機(jī)串行程序進(jìn)行了性能對比。結(jié)果表明，通過對Hbase進(jìn)行合適的配置，數(shù)據(jù)寫入時(shí)間隨著節(jié)點(diǎn)的增加而減少，存儲性能具有良好的擴(kuò)展性；MapReduce在處理少量數(shù)據(jù)時(shí)效率低于串行程序，但隨著數(shù)據(jù)量增加，其計(jì)算效率明顯優(yōu)于串行程序。

關(guān)鍵詞：Hadoop；Hbase；MapReduce；性能測試；農(nóng)業(yè)大數(shù)據(jù)

中圖分類號：S126+S663.104+.4 文獻(xiàn)標(biāo)識號：A 文章編號：1001-4942（2015）08-0119-05

Abstract With the advent of the era of agricultural big data， the traditional serial program and relational data base could not meet the need for processing big data， which was gradually replaced by the distributed computing platform. In this paper， the Hadoop distributed platform combined with the non-relational data base Hbase and the parallel programming model MapReduce was used to study the storage and calculation of environmental data from Shangri-la grape growing region. The performance of Hbase for data storage and MapReduce for regression analysis was tested， and the property of parallel calculating of MapReduce was compared with that of the traditional calculating method of serial storage. The results showed that the data writing time of Hbase decreased with the increase of node through appropriate configuration， and its storage property possessed better expansibility； the processing efficiency of MapReduce was lower for a few data， while that was obviously superior to the serial program for large amounts of data.

Key words Hadoop； Hbase； MapReduce； Performance test； Agricultural big data

近年來，大數(shù)據(jù)一詞越來越多的被提及，被用來描述和定義信息爆炸時(shí)代產(chǎn)生的海量數(shù)據(jù)。數(shù)據(jù)已經(jīng)成為與自然資源、人力資源同樣重要的戰(zhàn)略資源。目前，我國大數(shù)據(jù)已經(jīng)運(yùn)用到醫(yī)療業(yè)、制造業(yè)、交通業(yè)等不同行業(yè)[1，2]。農(nóng)業(yè)數(shù)據(jù)由結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)構(gòu)成，數(shù)據(jù)量大、涵蓋領(lǐng)域廣、數(shù)據(jù)類型多，屬于典型的大數(shù)據(jù)[3]?，F(xiàn)階段，大量的科研人員也已經(jīng)意識到農(nóng)業(yè)大數(shù)據(jù)的研究價(jià)值，投入到農(nóng)業(yè)大數(shù)據(jù)分析、處理過程的優(yōu)化中?；诖髷?shù)據(jù)的背景下，傳統(tǒng)的關(guān)系數(shù)據(jù)庫以及串行程序已不能滿足對大數(shù)據(jù)處理的需求[4]。隨著Google提出云計(jì)算這一技術(shù)概念，其三大核心技術(shù)GFS、MapReduce和Bigtable為大數(shù)據(jù)的管理提供了解決方案[5]。

眾多企業(yè)及科研單位已經(jīng)開展了農(nóng)業(yè)大數(shù)據(jù)研究工作。土壤抽樣分析服務(wù)商Solum致力于使用數(shù)據(jù)分析技術(shù)來確定化肥的投入量問題，通過對農(nóng)業(yè)大數(shù)據(jù)的分析來幫助農(nóng)民提高產(chǎn)出、降低成本[2]；跨國農(nóng)業(yè)生物技術(shù)公司Monsanto通過分析海量的天氣數(shù)據(jù)來預(yù)測未來可能對農(nóng)業(yè)生產(chǎn)造成破壞的各種天氣，農(nóng)民可以根據(jù)這種預(yù)測來選擇相應(yīng)的農(nóng)業(yè)保險(xiǎn)，以降低惡劣天氣對農(nóng)業(yè)生產(chǎn)造成的影響[6]；2013年6月，國內(nèi)第一個(gè)農(nóng)業(yè)大數(shù)據(jù)產(chǎn)業(yè)技術(shù)創(chuàng)新戰(zhàn)略聯(lián)盟在山東農(nóng)業(yè)大學(xué)成立，校長溫孚江指出，目前國內(nèi)的大數(shù)據(jù)研究雖然剛剛起步，但“農(nóng)業(yè)大數(shù)據(jù)”的研究已經(jīng)十分領(lǐng)先[1]。

Apache軟件基金會借鑒GFS和MapReduce設(shè)計(jì)思想開發(fā)了Hadoop分布式系統(tǒng)基礎(chǔ)架構(gòu)，作為GFS和Google MapReduce的開源實(shí)現(xiàn)。本文結(jié)合香格里拉地區(qū)釀酒葡萄8個(gè)種植點(diǎn)的環(huán)境數(shù)據(jù)，運(yùn)用Hadoop下的Hbase作為數(shù)據(jù)庫對數(shù)據(jù)進(jìn)行存儲、MapReduce編程模型對數(shù)據(jù)進(jìn)行計(jì)算，對其數(shù)據(jù)存儲及計(jì)算性能進(jìn)行測試，并與傳統(tǒng)串行解決方案進(jìn)行對比，以探討分布式計(jì)算相對于傳統(tǒng)串行計(jì)算的優(yōu)勢。

1 相關(guān)理論基礎(chǔ)

1.1 HDFS分布式文件系統(tǒng)

Hadoop作為一種開源架構(gòu)，適合在廉價(jià)機(jī)器上對各種資源數(shù)據(jù)進(jìn)行分布式存儲和分布式管理[5]。其核心架構(gòu)為HDFS與MapReduce。Hadoop集群包括一個(gè)Namenode節(jié)點(diǎn)和多個(gè)Datanode節(jié)點(diǎn)，Namenode在HDFS內(nèi)部提供元數(shù)據(jù)服務(wù)，Datanode為HDFS提供存儲塊。存儲在HDFS中的文件被分成塊，然后將這些塊分布到集群中的各個(gè)節(jié)點(diǎn)。HDFS的主要目的是支持以流的形式訪問寫入的大型文件。endprint

1.2 MapReduce計(jì)算模型及Hbase數(shù)據(jù)庫

MapReduce是用于并行處理大數(shù)據(jù)集（基于HDFS之上）的軟件框架，借用了函數(shù)式編程思想，把海量數(shù)據(jù)集的常見操作抽象為Map和Reduce兩種集合操作[4]，當(dāng)MapReduce在運(yùn)行處理大數(shù)據(jù)集任務(wù)時(shí)，由JobTracker確定如何創(chuàng)建其他TaskTracker從屬任務(wù)，為特定節(jié)點(diǎn)的每個(gè)文件塊指派唯一的子任務(wù)，當(dāng)每個(gè)子任務(wù)運(yùn)行完成后由TaskTracker將狀態(tài)和完成信息報(bào)告給JobTracker[8]。

Hbase作為Hadoop的一個(gè)子項(xiàng)目，是一個(gè)分布式的、面向列的開源數(shù)據(jù)庫[9]。Hbase數(shù)據(jù)表中的數(shù)據(jù)由行鍵（RowKey）、時(shí)間戳（Timestamp）、列族（ColumnFamily）組成。行鍵用來標(biāo)識某個(gè)表中唯一的一條記錄，列族可以由任意多個(gè)列組成，數(shù)據(jù)插入時(shí)每條數(shù)據(jù)會獲得一個(gè)時(shí)間戳，用來標(biāo)識某條數(shù)據(jù)的版本號，創(chuàng)建表時(shí)毋須指定列的個(gè)數(shù)，即Hbase支持對列的動態(tài)擴(kuò)展，因此Hbase非常適合于存儲非結(jié)構(gòu)化數(shù)據(jù)。

2 數(shù)據(jù)存儲及性能測試

選取云南省迪慶藏族自治州香格里拉縣和德欽縣8個(gè)葡萄種植點(diǎn)作為研究對象，每個(gè)種植點(diǎn)通過已安裝的數(shù)據(jù)采集設(shè)備進(jìn)行環(huán)境數(shù)據(jù)采集，采集的環(huán)境數(shù)據(jù)包括溫度、濕度、光照度、降雨量、輻射量、紫外線強(qiáng)度共6個(gè)環(huán)境因子。

2.1 數(shù)據(jù)在Hbase中的存儲設(shè)計(jì)

向Hbase數(shù)據(jù)表寫入數(shù)據(jù)時(shí)，Hbase默認(rèn)的寫緩存區(qū)大小為2 M，AutoFlush屬性為True。不作更改時(shí)，當(dāng)調(diào)用Hbase的put方法插入數(shù)據(jù)時(shí)，每執(zhí)行一條put命令，數(shù)據(jù)表就執(zhí)行一次更新，嚴(yán)重影響插入效率。需設(shè)置合適的寫緩存區(qū)大小（setWriteBufferSize屬性）并將setAutoFlush屬性設(shè)置為false，這樣只有當(dāng)put填滿客戶端寫緩存時(shí)，才向Hbase服務(wù)端發(fā)起寫請求，能極大提高寫效率。

影響Hbase插入性能的另一個(gè)重要因素是Region的預(yù)分區(qū)。當(dāng)創(chuàng)建一個(gè)新表時(shí)，Hbase默認(rèn)只有一個(gè)Region[10]，只有當(dāng)數(shù)據(jù)量增長到一定程度才會調(diào)用split方法將Region分裂，由于split方法非常耗時(shí)耗資源，并且會使服務(wù)端有一段時(shí)間的停頓，所以這也會極大影響寫入效率。為解決這一問題，需要對表的行鍵進(jìn)行設(shè)計(jì)（表1）。Region有兩個(gè)重要屬性StartKey和EndKey，表示此Region所維護(hù)的RowKey的范圍，寫入的數(shù)據(jù)首先判斷屬于哪個(gè)Region，然后進(jìn)行對應(yīng)的寫入操作。因此為了使寫數(shù)據(jù)過程中每個(gè)節(jié)點(diǎn)提供的請求處理數(shù)量盡可能均等，行鍵的前面用LocalID（1～8）填充，后面連接格式化后的時(shí)間參數(shù)。并根據(jù)行鍵的特點(diǎn)，創(chuàng)建表時(shí)預(yù)分8個(gè)Region。行鍵的組成如下：

2.2 Hbase寫入數(shù)據(jù)性能測試

本測試在云南農(nóng)業(yè)大學(xué)基礎(chǔ)與信息工程學(xué)院計(jì)算機(jī)公共實(shí)驗(yàn)室進(jìn)行，云計(jì)算環(huán)境配置有9個(gè)節(jié)點(diǎn)的Hadoop集群。每個(gè)節(jié)點(diǎn)所用的操作系統(tǒng)均為Ubuntu14.04，JDK版本1.8，Hadoop版本2.2.0，Hbase版本0.96.2，所用CPU為IntelcoreI3370型號。集群中各個(gè)節(jié)點(diǎn)IP、主機(jī)名如圖1所示，Master為主節(jié)點(diǎn)，Node1～8為從節(jié)點(diǎn)。

選取8個(gè)監(jiān)測點(diǎn)5～11月份采集到的全部環(huán)境數(shù)據(jù)進(jìn)行寫入Hbase測試，數(shù)據(jù)量為100萬條。分別采用Hbase默認(rèn)配置（簡稱“默認(rèn)”）、未預(yù)分Region但設(shè)置緩存區(qū)為6 M且設(shè)置AutoFlush為false（簡稱“未預(yù)分Region”）、預(yù)分8個(gè)Region并設(shè)置緩存區(qū)為6 M且設(shè)置AutoFlush為false（簡稱“預(yù)分Region”）三種實(shí)驗(yàn)方案，分別運(yùn)行于3、5、7、9個(gè)節(jié)點(diǎn)的Hadoop集群中，得出節(jié)點(diǎn)個(gè)數(shù)與寫入時(shí)間的折線圖（圖2），可見，使用默認(rèn)配置寫入效率較低，設(shè)置自動Flush為false后，插入效率有明顯提升，但這兩種方案隨著節(jié)點(diǎn)的增加，寫入效率無明顯提升；第三種方案通過預(yù)分配Region，寫入效率較前兩種方案效率更高，且隨著節(jié)點(diǎn)數(shù)的增加，所用的時(shí)間逐漸減少。結(jié)果表明，在實(shí)際寫入數(shù)據(jù)過程中，根據(jù)RowKey范圍設(shè)置合適的Region個(gè)數(shù)，可不斷提高數(shù)據(jù)寫入效率，同時(shí)也表明了Hbase集群具有良好的擴(kuò)展性。

為進(jìn)一步研究預(yù)分配Region與未分配Region寫入數(shù)據(jù)的效率差異，在原數(shù)據(jù)基礎(chǔ)上通過生成隨機(jī)數(shù)據(jù)增加數(shù)據(jù)量，測試的數(shù)據(jù)量分別為100萬、300萬、500萬、700萬條，運(yùn)行于9個(gè)節(jié)點(diǎn)的Hadoop集群中，得出數(shù)據(jù)量與運(yùn)行時(shí)間的折線圖（圖3），可見，當(dāng)不進(jìn)行Region的預(yù)分配時(shí)，隨著數(shù)據(jù)量的增加，曲線的斜率相差很小，說明寫入數(shù)據(jù)的時(shí)間隨數(shù)據(jù)量的增加呈線性增長，數(shù)據(jù)寫入性能基本沒有提高；而使用預(yù)分配Region方式寫入數(shù)據(jù)，曲線斜率逐漸減小，即時(shí)間的增長率降低，說明寫入的數(shù)據(jù)量越大，Hbase寫入性能越高。

3 數(shù)據(jù)計(jì)算及性能測試

3.1 基于MapReduce的線性回歸分析原理

回歸分析是確定兩種或兩種以上變量間聯(lián)系的一種統(tǒng)計(jì)分析方法，可分析變量之間相關(guān)性的具體形式，并用數(shù)學(xué)模型來表現(xiàn)。按照自變量的多少可分為一元回歸分析和多元回歸分析。其中一元回歸分析方程可表示為y=bx+a形式，根據(jù)最小二乘法原理[11]估計(jì)參數(shù)a、b的公式如（2）式：

MapReduce的核心是Map過程和Reduce過程，兩過程中的數(shù)據(jù)傳遞都是以鍵值對形式存在。使用MapReduce編程模型計(jì)算回歸方程，Map過程讀取Hbase表中數(shù)據(jù)，形成鍵值對，其中Key1表示行鍵，Value1表示相應(yīng)環(huán)境因子。Map函數(shù)對進(jìn)行切分生成所需日期格式的Key2，形成并傳遞給Reduce函數(shù)，Reduce函數(shù)對具有相同Key2的一組list執(zhí)行一次Reduce過程，計(jì)算出（2）式中相關(guān)參數(shù)并存放到Result表中，再利用串行程序得出相應(yīng)回歸方程。

3.2 MapReduce回歸分析性能測試

本測試以溫度與果實(shí)大小的回歸分析為例。其中溫度數(shù)據(jù)存于Temper表中，果實(shí)數(shù)據(jù)存于Fruit表中。以天為單位，使用MapReduce程序讀取Temper表中溫度數(shù)據(jù)并計(jì)算每天平均氣溫和有效積溫，將生成的結(jié)果存入Test表中；再使用MapReduce程序根據(jù)Test和Fruit表中數(shù)據(jù)計(jì)算（2）式中未知參數(shù)，得出a、b的數(shù)值進(jìn)而得出回歸方程。

Temper表中初始數(shù)據(jù)為100萬條，以100萬條為單位遞增生成8組測試數(shù)據(jù)，分別在3節(jié)點(diǎn)集群和6節(jié)點(diǎn)集群中分析不同數(shù)據(jù)量對運(yùn)行時(shí)間的影響，結(jié)果如圖4所示，可見，曲線增長的趨勢一直減小，即所用時(shí)間增長率減小，說明MapReduce更擅長處理較大的數(shù)據(jù)量；當(dāng)數(shù)據(jù)量達(dá)到400萬條時(shí)，6節(jié)點(diǎn)集群比3節(jié)點(diǎn)集群對數(shù)據(jù)的處理時(shí)間明顯減小，也說明了MapReduce具有較好的擴(kuò)展性。

為了對比Hadoop集群和單機(jī)對數(shù)據(jù)處理的能力，分別使用50萬到3 000萬的數(shù)據(jù)運(yùn)行于單機(jī)和6節(jié)點(diǎn)的Hadoop集群上，結(jié)果如圖5所示，當(dāng)數(shù)據(jù)量小于300萬條時(shí)使用單機(jī)模式比集群模式效率更高，主要是因?yàn)榧撼跏蓟鳂I(yè)、中間文件生成、傳遞過程占用了大量的時(shí)間比例，此時(shí)MapReduce運(yùn)算性能的優(yōu)勢沒有得到發(fā)揮；當(dāng)數(shù)據(jù)量超過2 000萬條時(shí)，單機(jī)運(yùn)行時(shí)間有加大趨勢，此時(shí)主要受內(nèi)存大小影響；當(dāng)數(shù)據(jù)量超過800萬條時(shí)，MapReduce并行計(jì)算所需時(shí)間上升趨勢逐漸減少，并行計(jì)算的優(yōu)勢開始發(fā)揮，說明隨著數(shù)據(jù)量的增加，并行計(jì)算要優(yōu)于串行計(jì)算。

4 總結(jié)與展望

在Hadoop云環(huán)境下進(jìn)行數(shù)據(jù)的寫入和計(jì)算效率測試的結(jié)果表明，通過進(jìn)行合適的配置，Hbase的數(shù)據(jù)寫入及查詢計(jì)算具有了良好的擴(kuò)展性，且隨著數(shù)據(jù)量的增大，Hbase對數(shù)據(jù)的存儲能力也會增強(qiáng)。利用MapReduce編程模型對釀酒葡萄的環(huán)境因子與果實(shí)參數(shù)進(jìn)行回歸分析，在處理少量數(shù)據(jù)時(shí)，其效率低于串行程序；但隨著數(shù)據(jù)量的增大，MapReduce程序比串行程序具有更好的計(jì)算性能。

今后可根據(jù)具體需求開發(fā)可視化系統(tǒng)界面，實(shí)現(xiàn)對數(shù)據(jù)存儲、查詢、計(jì)算等功能的統(tǒng)一化管理，并研究多環(huán)境因子對葡萄果實(shí)生長發(fā)育的影響，以期綜合全面地為葡萄種植戶提供葡萄栽培合理化指導(dǎo)和科學(xué)的數(shù)據(jù)支持。

參 考 文 獻(xiàn)：

[1] 溫孚江.農(nóng)業(yè)大數(shù)據(jù)研究的戰(zhàn)略意義與協(xié)同機(jī)制[J].高等農(nóng)業(yè)教育，2013（11）：3-6.

[2] 張浩然，李中良，鄒騰飛，等.農(nóng)業(yè)大數(shù)據(jù)綜述[J].計(jì)算機(jī)科學(xué)，2014（S2）：387-392.

[3] 李秀峰，陳守合，郭雷風(fēng).大數(shù)據(jù)時(shí)代農(nóng)業(yè)信息服務(wù)的技術(shù)創(chuàng)新[J].中國農(nóng)業(yè)科技導(dǎo)報(bào)，2014（4）：10-15.

[4] 何清. 大數(shù)據(jù)與云計(jì)算[J].科技促進(jìn)發(fā)展，2014（1）：35-40.

[5] 謝桂蘭，羅省賢. 基于Hadoop MapReduce模型的應(yīng)用研究[J].微型機(jī)與應(yīng)用，2010（8）：4-7.

[6] Monsanto Acquires The Climate Corporation[EB/OL].[2014-03-19]. http：//www.monsanto.com/features/pages/monsanto-acquires-the-climate-corporation.aspx.

[7] 楊鋒，吳華瑞，朱華吉，等. 基于Hadoop的海量農(nóng)業(yè)數(shù)據(jù)資源管理平臺[J].計(jì)算機(jī)工程，2011（12）：242-244.

[8] 郝樹魁. Hadoop HDFS和MapReduce架構(gòu)淺析[J]. 郵電設(shè)計(jì)技術(shù)，2012（7）：37-42.

[9] 馮曉普. HBase存儲的研究與應(yīng)用[D].北京：北京郵電大學(xué)，2014.

[10]康毅. HBase大對象存儲方案的設(shè)計(jì)與實(shí)現(xiàn)[D].南京：南京大學(xué)，2013.

[11]鄒樂強(qiáng).最小二乘法原理及其簡單應(yīng)用[J].科技信息，2010（23）：282-283.endprint