基于Solr的農(nóng)田數(shù)據(jù)索引方法與大數(shù)據(jù)平臺(tái)構(gòu)建

苑嚴(yán)偉 冀福華 趙 博 姜含露 王 猛 樊學(xué)謙

(中國(guó)農(nóng)業(yè)機(jī)械化科學(xué)研究院土壤植物機(jī)器系統(tǒng)技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室， 北京 100083)

0 引言

農(nóng)田是農(nóng)業(yè)生產(chǎn)的載體[1-4]，我國(guó)農(nóng)田呈現(xiàn)數(shù)量多、田塊小、形態(tài)各異、信息多樣化等特點(diǎn)，農(nóng)田信息的多元異構(gòu)、海量等特性已成為現(xiàn)代農(nóng)業(yè)信息化發(fā)展的難題，為提高我國(guó)農(nóng)業(yè)數(shù)字化與信息化程度，有必要構(gòu)建面向精準(zhǔn)農(nóng)業(yè)的農(nóng)田大數(shù)據(jù)平臺(tái)，以實(shí)時(shí)、動(dòng)態(tài)、高效地管理農(nóng)田信息。

隨著物聯(lián)網(wǎng)、云計(jì)算、大數(shù)據(jù)等信息技術(shù)的發(fā)展，農(nóng)田數(shù)字化已成為現(xiàn)代農(nóng)業(yè)發(fā)展的主要方向之一。國(guó)外關(guān)于農(nóng)田數(shù)據(jù)的研究較早，到目前為止，國(guó)外已有成熟的農(nóng)田信息管理系統(tǒng)[5-7]，如：美國(guó)凱斯公司的AFS系統(tǒng)、約翰迪爾公司的GreenStar系統(tǒng)以及AgLeader的PF(Precision Farming), 這些都是相對(duì)規(guī)范且成熟的農(nóng)田數(shù)據(jù)模型。另外，國(guó)外研發(fā)了與農(nóng)田數(shù)據(jù)相關(guān)的智能農(nóng)業(yè)決策系統(tǒng)，如Farmeron公司[8]在2011 年推出了基于Web 端的農(nóng)場(chǎng)管理平臺(tái)，提供相對(duì)可靠的生產(chǎn)分析報(bào)告，以指導(dǎo)農(nóng)民進(jìn)行生產(chǎn)規(guī)劃；VitalFields公司[9]以氣象預(yù)測(cè)、病蟲(chóng)害、成本投入為研究對(duì)象，提供農(nóng)作物種植階段的相關(guān)服務(wù)，使得管理農(nóng)場(chǎng)更加高效；2017年OneSoil公司[10]通過(guò)歐洲空間局的衛(wèi)星影像和Mapbox的數(shù)據(jù)，利用人工智能的算法，推出了包括歐洲和美國(guó)超過(guò)5 700萬(wàn)塊農(nóng)田的交互式數(shù)字地圖，用于自動(dòng)檢測(cè)地塊、識(shí)別作物類(lèi)型和監(jiān)測(cè)作物發(fā)育。國(guó)外的地塊大多為標(biāo)準(zhǔn)農(nóng)場(chǎng)，而且在作物生產(chǎn)管理的方法和習(xí)慣方面與國(guó)內(nèi)存在較大差異，國(guó)外的農(nóng)田田塊數(shù)據(jù)模型不適合我國(guó)復(fù)雜農(nóng)情與多元經(jīng)營(yíng)模式。因此，國(guó)內(nèi)仍需開(kāi)發(fā)符合我國(guó)國(guó)情的農(nóng)田數(shù)據(jù)模型與大數(shù)據(jù)平臺(tái)。

國(guó)內(nèi)關(guān)于農(nóng)田數(shù)據(jù)的理論研究起步較晚。近年來(lái)，在國(guó)家十三五規(guī)劃的帶動(dòng)下，與農(nóng)田數(shù)據(jù)相關(guān)的技術(shù)發(fā)展較快，主要表現(xiàn)為多平臺(tái)、多用途、多方法面向個(gè)性化的農(nóng)田信息存儲(chǔ)技術(shù)研究與實(shí)現(xiàn)。文獻(xiàn)[11]利用1957—2007年河南省30個(gè)縣、市的氣象、土壤、作物等數(shù)據(jù)信息，構(gòu)建了基于元數(shù)據(jù)的農(nóng)田信息的存儲(chǔ)、管理和共享模型；文獻(xiàn)[12]以土地所有者、種植管理者、施肥管理、殺蟲(chóng)噴藥等信息作為屬性信息，構(gòu)建了基于圖的農(nóng)田數(shù)據(jù)模型；文獻(xiàn)[13]以土壤信息、環(huán)境信息、田間信息、GPS定位信息等作為屬性信息，構(gòu)建了基于GDAL的農(nóng)田信息數(shù)據(jù)模型；文獻(xiàn)[14]以河南省鞏義市吳溝村為例, 以衛(wèi)星遙感圖像為建庫(kù)數(shù)字化參照依據(jù), 采用目視解譯方法, 利用ERDAS Imagine 8.6和MapInfo Professional 7.0 SCP為數(shù)據(jù)庫(kù)平臺(tái)，依次提取旱地梯田、旱坡地、菜地、退耕還林地等不同田塊圖層，設(shè)計(jì)了基于RS、GIS的村域農(nóng)田數(shù)據(jù)庫(kù)。文獻(xiàn)[15]以無(wú)線傳感器采集平臺(tái)的空氣溫濕度、風(fēng)速、風(fēng)向、光照為依據(jù)，建立了基于無(wú)線傳感網(wǎng)的農(nóng)田數(shù)據(jù)管理系統(tǒng)。國(guó)內(nèi)研究大都基于傳統(tǒng)的數(shù)據(jù)模型進(jìn)行數(shù)據(jù)的儲(chǔ)存和查詢(xún)[16]。而隨著數(shù)據(jù)量的增大，大數(shù)據(jù)的海量、非結(jié)構(gòu)化的特性導(dǎo)致了傳統(tǒng)數(shù)據(jù)庫(kù)難以滿足大數(shù)據(jù)的存儲(chǔ)與高并發(fā)的訪問(wèn)需求，海量異構(gòu)農(nóng)田數(shù)據(jù)多樣性、龐雜導(dǎo)致信息無(wú)法有效重構(gòu)，農(nóng)田田塊大數(shù)據(jù)處理過(guò)程中易產(chǎn)生云端運(yùn)算負(fù)擔(dān)大、響應(yīng)時(shí)間慢等問(wèn)題。另外，傳統(tǒng)的數(shù)據(jù)單機(jī)處理模式很難提供相對(duì)高效的計(jì)算資源整合，導(dǎo)致大量的硬件資源浪費(fèi)。

針對(duì)上述問(wèn)題，本文在前期農(nóng)機(jī)深松監(jiān)測(cè)系統(tǒng)的基礎(chǔ)上，對(duì)農(nóng)田數(shù)據(jù)在解析、存儲(chǔ)與處理過(guò)程中的技術(shù)細(xì)節(jié)進(jìn)行研究，建立基于Hadoop的農(nóng)田大數(shù)據(jù)平臺(tái)，對(duì)農(nóng)田田塊在作物的耕、種、管、收等過(guò)程中產(chǎn)生的海量農(nóng)田數(shù)據(jù)進(jìn)行動(dòng)態(tài)管理。

1 大數(shù)據(jù)平臺(tái)的設(shè)計(jì)與構(gòu)建

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

基于Hadoop的農(nóng)田大數(shù)據(jù)平臺(tái)可用于分布在全國(guó)各地的農(nóng)業(yè)合作社農(nóng)田田塊信息管理。該平臺(tái)將大數(shù)據(jù)、物聯(lián)網(wǎng)、WebGIS等技術(shù)進(jìn)行深度融合，向用戶提供農(nóng)田田塊數(shù)據(jù)的快速檢索、處理和動(dòng)態(tài)展示。其總體架構(gòu)如圖1所示，主要包括感知層、網(wǎng)絡(luò)層、中間層和應(yīng)用層。

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

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

基于Hadoop的農(nóng)田大數(shù)據(jù)平臺(tái)的功能設(shè)計(jì)如圖2所示，主要包括角色管理、地塊管理、設(shè)備管理、農(nóng)資管理、作業(yè)管理、統(tǒng)計(jì)管理，其主要面向?qū)ο鬄楦鞣N用戶。

圖2 系統(tǒng)功能設(shè)計(jì)Fig.2 Function module of system

(1)角色管理

平臺(tái)的用戶主要分為管理員和普通用戶兩種類(lèi)型，不同類(lèi)型的用戶會(huì)分配不同的使用權(quán)限，如政府機(jī)關(guān)具備所管轄合作社的瀏覽權(quán)限、任務(wù)分配權(quán)限等；合作社具備本合作社業(yè)務(wù)的日常維護(hù)權(quán)限。另外為了便于系統(tǒng)的維護(hù)，設(shè)置了管理員角色作為最高權(quán)限。

(2)地塊管理

地塊管理是整個(gè)大數(shù)據(jù)平臺(tái)最重要的環(huán)節(jié)，它負(fù)責(zé)管理地塊的位置信息、作業(yè)信息、氣象信息、附著物信息，為地塊的精細(xì)化管理提供了豐富的數(shù)據(jù)支持，具備地塊信息的錄入與檢索，并通過(guò)WebGIS技術(shù)，將部分?jǐn)?shù)據(jù)可視化。

(3)設(shè)備管理

設(shè)備管理主要有兩個(gè)作用：獲取田塊信息和進(jìn)行田塊作業(yè)。設(shè)備管理的內(nèi)容主要為設(shè)備的基本信息、工作詳情。其中包括錄入設(shè)備基本信息和設(shè)備工作詳情，設(shè)備工作詳情主要指用戶在客戶端可實(shí)時(shí)查詢(xún)?cè)O(shè)備的位置及機(jī)手信息，其中設(shè)備位置信息可調(diào)用天地圖API實(shí)時(shí)獲取。

(4)作業(yè)管理

作業(yè)管理主要包括作業(yè)類(lèi)型、作業(yè)詳情、作業(yè)記錄、作業(yè)時(shí)間4部分。其中作業(yè)類(lèi)型為農(nóng)機(jī)作業(yè)的基本類(lèi)型，如：深松、打捆、籽粒直收、植保等；作業(yè)詳情為實(shí)時(shí)展示作業(yè)現(xiàn)場(chǎng)并抓拍作業(yè)場(chǎng)景；作業(yè)完成情況是指作業(yè)軌跡、作業(yè)的完成率，已作業(yè)面積；作業(yè)記錄是指作業(yè)的歷史信息，這些信息包括作業(yè)軌跡、作業(yè)面積、機(jī)手信息、作業(yè)時(shí)間、作業(yè)時(shí)隨機(jī)抓拍的圖像。

(5)農(nóng)資管理

農(nóng)資管理是對(duì)地塊的使用資源(化肥、農(nóng)藥等)的統(tǒng)一整合，可對(duì)地塊的農(nóng)資使用情況提供較為詳盡的記錄。另外，可記錄地塊的產(chǎn)出數(shù)據(jù)，這些數(shù)據(jù)都能為農(nóng)作物科學(xué)管理及分析決策提供數(shù)據(jù)源支持。

(6)統(tǒng)計(jì)管理

統(tǒng)計(jì)管理是在農(nóng)資管理、設(shè)備管理、地塊管理的基礎(chǔ)上，對(duì)農(nóng)田數(shù)據(jù)進(jìn)行深層次的加工，比如：統(tǒng)計(jì)造成不同地塊產(chǎn)量差異性的原因，探究農(nóng)機(jī)作業(yè)、農(nóng)資使用與農(nóng)作物產(chǎn)量之間關(guān)系。

2 農(nóng)田數(shù)據(jù)關(guān)鍵技術(shù)設(shè)計(jì)

2.1 數(shù)據(jù)結(jié)構(gòu)

本文以農(nóng)田田塊為研究對(duì)象進(jìn)行農(nóng)田數(shù)據(jù)的分析，農(nóng)田田塊數(shù)據(jù)包括田塊的位置信息、氣象信息、作業(yè)信息及附著物信息等。位置信息包含田塊經(jīng)度、緯度、海拔及坡度等地理信息，氣象信息包括歷年的溫度、濕度、光照、風(fēng)速、風(fēng)向等；作業(yè)信息主要是不同農(nóng)業(yè)機(jī)械的歷年與實(shí)時(shí)作業(yè)信息，如深松機(jī)作業(yè)深度、播種機(jī)播種施肥量、植保機(jī)噴藥量、收獲機(jī)產(chǎn)量分布信息等；附著物信息是指對(duì)農(nóng)業(yè)生產(chǎn)影響較大的信息，如水井、電線桿、農(nóng)舍的經(jīng)緯度和局部輪廓等。數(shù)據(jù)結(jié)構(gòu)如圖3所示。由于數(shù)據(jù)量大，為了便于檢索和存儲(chǔ)，現(xiàn)有的農(nóng)田田塊大數(shù)據(jù)平臺(tái)將數(shù)據(jù)進(jìn)行分表保存處理。

圖3 農(nóng)田數(shù)據(jù)結(jié)構(gòu)Fig.3 Data structure of farmland

2.2 數(shù)據(jù)庫(kù)選取與部署

農(nóng)田田塊數(shù)據(jù)類(lèi)型復(fù)雜，不僅有常見(jiàn)的結(jié)構(gòu)化數(shù)據(jù)，而且還有半結(jié)構(gòu)化數(shù)據(jù)。 HBase[17]作為高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫(xiě)的分布式數(shù)據(jù)庫(kù),可支持集群存儲(chǔ)海量數(shù)據(jù)。目前由于對(duì)農(nóng)田數(shù)據(jù)的存儲(chǔ)多選用傳統(tǒng)的數(shù)據(jù)庫(kù)，如Mysql、PostgreSql等，這些數(shù)據(jù)庫(kù)在解決事務(wù)性問(wèn)題上有其獨(dú)特的優(yōu)勢(shì)，然而隨著數(shù)據(jù)量的增加，數(shù)據(jù)存儲(chǔ)的因素主要從數(shù)據(jù)檢索性能來(lái)考量。

數(shù)據(jù)庫(kù)Hbase的檢索過(guò)程如下：

(1)客戶端從ZooKeeper找到存放在Master上的Region服務(wù)器的位置信息、Region的元數(shù)據(jù)信息以及Region與Region服務(wù)器的映射關(guān)系。

(2)通過(guò)Region服務(wù)器檢索存儲(chǔ)在Region的數(shù)據(jù)。

(3)通過(guò)HDFS(Hadoop distributed files system)讀取存儲(chǔ)在磁盤(pán)上的數(shù)據(jù)。

Hbase[18]的部署服從主從原則，依附于Hadoop集群。本文部署的Hbase的所有協(xié)調(diào)工作均由ZooKeeper來(lái)執(zhí)行，來(lái)實(shí)現(xiàn)HMater的選舉與主備的切換、系統(tǒng)容錯(cuò)、任務(wù)管理。而且Hbase與ZooKeeper為獨(dú)立部署，這樣可避免二者發(fā)生強(qiáng)耦合，便于后期集群的升級(jí)與維護(hù)，由于ZooKeeper具備輕量化的特性，部署的ZooKeeper仍構(gòu)建于HDFS之上，此外，它還提供了整個(gè)大數(shù)據(jù)集群的負(fù)載均衡。

2.3 行鍵

Hbase表主要由行鍵(Rowkey)、列族、列限定符和時(shí)間戳等組成。行鍵是其主鍵，在滿足行鍵設(shè)計(jì)長(zhǎng)度原則、散列原則、唯一原則的前提下，為提高數(shù)據(jù)對(duì)內(nèi)存的使用率，對(duì)于64位操作系統(tǒng)的行鍵設(shè)計(jì)應(yīng)為8字節(jié)的倍數(shù)，本設(shè)計(jì)中選擇16字節(jié)行鍵設(shè)計(jì)。將行鍵的高位作為散列字段，低位作為時(shí)間值，可以使得數(shù)據(jù)相對(duì)均衡地分布在Region服務(wù)器中。由于Hbase的行鍵按字典順序增加，為了避免寫(xiě)熱點(diǎn)，設(shè)計(jì)Rowkey需使不同行的數(shù)據(jù)放在同一個(gè)Region中，如果沒(méi)有散列字段，直接存放時(shí)間值將可能產(chǎn)生所有新數(shù)據(jù)都在一個(gè)Region服務(wù)器上堆積的熱點(diǎn)現(xiàn)象，導(dǎo)致數(shù)據(jù)檢索時(shí)負(fù)載將會(huì)集中在個(gè)別Region服務(wù)器，降低查詢(xún)效率。在農(nóng)田大數(shù)據(jù)平臺(tái)中，由于地塊編號(hào)、設(shè)備號(hào)、作業(yè)人及作業(yè)時(shí)間等字段使用較為頻繁，所以在設(shè)計(jì)行鍵時(shí)包含了上述信息。同時(shí)，由于地塊編號(hào)采用字母+數(shù)字的格式，將地塊編號(hào)寫(xiě)入開(kāi)端可以避免寫(xiě)入數(shù)據(jù)時(shí)行鍵的順序遞增的問(wèn)題。因此，本系統(tǒng)行鍵設(shè)計(jì)為：Rowkey=“地塊編號(hào)+歸屬人+作業(yè)人+時(shí)間”。

2.4 列族

農(nóng)田田塊數(shù)據(jù)主要字段包括：地塊編號(hào)、地塊位置、地塊面積、地塊歸屬人、地塊管理人、作業(yè)類(lèi)型、設(shè)備號(hào)、車(chē)牌號(hào)、作業(yè)時(shí)間、溫度、濕度、光照強(qiáng)度、風(fēng)速等128個(gè)字段。對(duì)于作業(yè)時(shí)間要求精確到分鐘，采用8位占位符進(jìn)行存儲(chǔ)。對(duì)于位置信息采用獨(dú)立的幾何屬性列族存儲(chǔ)；其他字符均采用字符型。各字段長(zhǎng)度不一，由于列族少時(shí)，底層的I/O開(kāi)銷(xiāo)就會(huì)降低，因此所有非幾何字段構(gòu)成一個(gè)唯一的列族，其具體設(shè)計(jì)如表1所示。

表1 農(nóng)田數(shù)據(jù)表結(jié)構(gòu)Tab.1 Structure of land data

2.5 基于Solr二級(jí)非主鍵索引的設(shè)計(jì)

Solr[19]是Apache基金會(huì)下的一款基于Lucene的全文搜索服務(wù)器。用戶可通過(guò)Http協(xié)議獲得該系統(tǒng)對(duì)外提供的類(lèi)似于java-web的API，并向該系統(tǒng)提交生成索引的XML文件，最后可通過(guò)Get請(qǐng)求獲取索引結(jié)果。另外，Solr的搜索引擎采用Java5開(kāi)發(fā)，而本文的大數(shù)據(jù)平臺(tái)也采用了Java開(kāi)發(fā)，可以使得大數(shù)據(jù)平臺(tái)很好地兼容Solr。因此，本文選取了Solr進(jìn)行系統(tǒng)二級(jí)索引。

根據(jù)表1添加了4個(gè)索引字段，分別為：地塊類(lèi)型(landType)、地塊面積(landArea)、地塊產(chǎn)量(landOutput)和地塊作業(yè)類(lèi)型(workType)。其配置信息中name表示字段名；type表示定義的字段的屬性，一般情況下integer字段的索引效果更好；indexed表示是否索引，作為索引字段必需設(shè)置為true；stored表示是否被存儲(chǔ)，為了改進(jìn)性能，對(duì)于不需要作為結(jié)果存儲(chǔ)的均設(shè)為false；multiValued表示是否包含多個(gè)值，對(duì)于可能存在多值的字段全部設(shè)為true，從而避免構(gòu)建索引時(shí)報(bào)錯(cuò)，索引字段的類(lèi)型與配置信息具體如下

〈fields〉

〈field name = "Rowkey" type = "string" indexed = "true" stored = "true" multiValued = "false" / 〉

〈field name = "landType" type = "integer" indexed = "true" stored = "false" multiValued = "false" /〉

〈field name = "landArea" type = "string" indexed = "true" stored = "false" multiValued = "false" /〉

〈field name = "landOutput" type = "integer" indexed = "true" stored = "false" multiValued = "false" / 〉

〈field name = "workType" type = "string" indexed ="true" stored = "false" multiValued = "false" /〉

〈/fields〉

構(gòu)建二級(jí)非主鍵索引后，數(shù)據(jù)傳輸過(guò)程為：采集到的農(nóng)田數(shù)據(jù)分別存儲(chǔ)在采集終端和大數(shù)據(jù)集群服務(wù)器上。采集終端可以存儲(chǔ)近期內(nèi)一部分?jǐn)?shù)據(jù)，主要是為防止采集終端野外作業(yè)時(shí)由于信號(hào)丟失等引起短時(shí)間內(nèi)數(shù)據(jù)無(wú)法正常傳輸?shù)椒?wù)器端的問(wèn)題。采集終端采集到的數(shù)據(jù)(生產(chǎn)者)會(huì)通過(guò)kafka將數(shù)據(jù)打包發(fā)送到數(shù)據(jù)中心(消費(fèi)者)，數(shù)據(jù)中心解析之后存儲(chǔ)在構(gòu)建于HDFS之上的Hbase數(shù)據(jù)庫(kù)中。系統(tǒng)的元數(shù)據(jù)信息存儲(chǔ)在Master結(jié)點(diǎn)的內(nèi)存中，元數(shù)據(jù)信息主要包括維護(hù)文件系統(tǒng)的FsImage和記錄操作日志的EditLog。當(dāng)客戶端發(fā)出數(shù)據(jù)請(qǐng)求時(shí)，數(shù)據(jù)處理相關(guān)模塊首先判斷是否存在主鍵索引，若存在則直接通過(guò)Hbase的主鍵索引檢索數(shù)據(jù)，若檢索條件涉及二級(jí)非主鍵索引字段，則通過(guò)多條件查詢(xún)到相關(guān)主鍵值，最后通過(guò)主鍵在Hbase里進(jìn)行檢索。該索引模塊設(shè)計(jì)在一定程度上可提高檢索速度。

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

3.1 集群部署

系統(tǒng)部署在阿里云服務(wù)器，軟件環(huán)境為：Hadoop 2.7.1、Hbase 2.0.X、JDK 1.8、ZooKeeper 3.4.6、操作系統(tǒng)為CentOS7.0；硬件配置信息：CPU型號(hào)為Intel 酷睿i7 8700K， 3.7 GHz主頻，32 GB內(nèi)存，20 TB硬盤(pán)，千兆以太網(wǎng)，各個(gè)節(jié)點(diǎn)配置信息如表2所示。

表2 服務(wù)器各節(jié)點(diǎn)信息Tab.2 Server nodes information

3.2 數(shù)據(jù)來(lái)源

實(shí)驗(yàn)數(shù)據(jù)選取了某省農(nóng)機(jī)深松、植保、保護(hù)性耕作等8種作業(yè)類(lèi)型產(chǎn)生的100 TB作業(yè)數(shù)據(jù)，該數(shù)據(jù)集記錄了某省2015—2018年的作業(yè)情況，每條記錄不等長(zhǎng)，數(shù)據(jù)信息的類(lèi)型包括文字、圖像、視頻等，數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)如圖3所示。本文用于對(duì)比實(shí)驗(yàn)的數(shù)據(jù)是通過(guò)Sqoop[20]工具導(dǎo)入，硬件環(huán)境與上述Hadoop集群保持一致。

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

3.3.1多條件檢索、性能分析及其優(yōu)化

檢索數(shù)據(jù)仍采用上述數(shù)據(jù)，檢索條件依次增加，本文設(shè)定的檢索條件的個(gè)數(shù)(n)分別為2、3、4；檢索次數(shù)為10次，檢索時(shí)間取其平均值。其檢索性能對(duì)比如圖4所示。

圖4 n為2、3、4多條件檢索性能對(duì)比Fig.4 Contrast graphs of retrieval performance

由圖4可知，隨著數(shù)據(jù)量的增加，Hbase的響應(yīng)速度降低較為明顯，當(dāng)數(shù)據(jù)規(guī)模達(dá)到千萬(wàn)級(jí)時(shí)，響應(yīng)時(shí)間大于3 s。從理論層面上分析Hbase是一種面向列的數(shù)據(jù)庫(kù)，其底層在行鍵上建立了基于行鍵的類(lèi)B+樹(shù)索引，可以相對(duì)高效地支持基于行鍵的數(shù)據(jù)檢索；對(duì)于多條件查詢(xún)的非行鍵數(shù)據(jù)的檢索，系統(tǒng)需要調(diào)用全表掃描的功能，數(shù)據(jù)的整體檢索效率低下。隨著數(shù)據(jù)量的不斷增加，優(yōu)化后的索引方法的優(yōu)勢(shì)越來(lái)越明顯，當(dāng)數(shù)據(jù)量達(dá)到5×107條時(shí)，響應(yīng)時(shí)間小于1 s，優(yōu)化的性能與原生Hbase相比提高了3倍，能滿足用戶的需求。

為了更好地說(shuō)明問(wèn)題，本文對(duì)檢索數(shù)據(jù)做了縱向?qū)Ρ?，選取檢索規(guī)模(C)為3×107條時(shí)，檢索條件個(gè)數(shù)n取2、3、4，Hbase檢索時(shí)間分別為3.576、2.887、2.458 s，二級(jí)索引Hbase檢索時(shí)間分別為0.742、0.582、0.421 s。

可知，二級(jí)索引的性能均優(yōu)于原生Hbase，而檢索時(shí)間隨著檢索條件的增多呈下降的趨勢(shì)。從理論上分析，由于檢索條件的增多，從數(shù)據(jù)庫(kù)中檢索出符合條件的數(shù)據(jù)在減少，相當(dāng)于減少了數(shù)據(jù)的并發(fā)量，因此，檢索時(shí)間持續(xù)下降。

3.3.2系統(tǒng)壓力測(cè)試

為了驗(yàn)證系統(tǒng)架構(gòu)的合理性與安全性，本文選取了請(qǐng)求次數(shù)較多的大數(shù)據(jù)平臺(tái)首頁(yè)進(jìn)行了壓力測(cè)試，首頁(yè)界面如圖5所示。選用YCSB[21]作為系統(tǒng)的壓力測(cè)試工具，選取每秒查詢(xún)率(QPS)、吞吐量(TPS)和響應(yīng)時(shí)間(RT)等作為系統(tǒng)性能度量的主要參數(shù)。本文通過(guò)多線程并發(fā)的方式模擬不同角色的用戶，表3為5×105次并發(fā)用戶壓力測(cè)試結(jié)果，測(cè)試時(shí)間為5 min。實(shí)驗(yàn)結(jié)果取5次實(shí)驗(yàn)的平均值。

圖5 大數(shù)據(jù)平臺(tái)首頁(yè)Fig.5 Home page of big data platform

參數(shù) Hbase二級(jí)索引Hbase每秒查詢(xún)率(QPS)233821424211每秒吞吐量(TPS)46588657響應(yīng)時(shí)間(RT)/ms643183

通過(guò)測(cè)試結(jié)果，可以得出在高并發(fā)量(5×105次)時(shí)，優(yōu)化后系統(tǒng)的RT提高了2.5倍。系統(tǒng)平均響應(yīng)時(shí)間183 ms，系統(tǒng)的QPS、TPS提高了1倍左右，說(shuō)明該系統(tǒng)在高并發(fā)時(shí)可高效穩(wěn)定運(yùn)行。

此外，對(duì)系統(tǒng)的讀寫(xiě)能力進(jìn)行了壓力測(cè)試，表4描述了不同讀寫(xiě)操作情況下(分別插入1×105、1×106、1×107條數(shù)據(jù))系統(tǒng)插入數(shù)據(jù)的結(jié)果，每組實(shí)驗(yàn)進(jìn)行5次，結(jié)果取5次插入的平均值。

由表4可知，在二級(jí)索引情況下，插入數(shù)據(jù)需要消耗的時(shí)間更多一些，這是由于二級(jí)索引需要觸發(fā)協(xié)處理器將索引數(shù)據(jù)不斷存入Solr中，隨著數(shù)據(jù)量增多，與原生Hbase相比二級(jí)索引插入性能不斷降低。從實(shí)驗(yàn)結(jié)果來(lái)看,3組實(shí)驗(yàn)的插入性能平均降低了13.3%。降低的插入性能與提高的檢索性能相比，可忽略。

表4 插入響應(yīng)時(shí)間測(cè)試結(jié)果Tab.4 Results of testing for insert performance ms

4 結(jié)論

(1)研究了負(fù)載均衡大規(guī)模集群數(shù)據(jù)處理技術(shù)，實(shí)現(xiàn)了農(nóng)田田間耕、種、管、收及農(nóng)田田塊自身產(chǎn)生的多源異構(gòu)海量數(shù)據(jù)的存儲(chǔ)與檢索，保證了海量農(nóng)田田塊數(shù)據(jù)存儲(chǔ)的安全性與檢索的高效性。

(2)針對(duì)Hbase數(shù)據(jù)庫(kù)在農(nóng)田田間數(shù)據(jù)進(jìn)行多條件檢索時(shí)性能不佳的問(wèn)題，研究了面向列數(shù)據(jù)庫(kù)高效索引技術(shù)，提出了基于Solr二級(jí)非主鍵索引的檢索方法，在數(shù)據(jù)規(guī)模達(dá)到5×107條時(shí)，響應(yīng)時(shí)間小于1 s，農(nóng)田田塊數(shù)據(jù)多條件關(guān)聯(lián)檢索時(shí)，相對(duì)原生Hbase數(shù)據(jù)庫(kù)優(yōu)化性能提高了3倍，大大提高了數(shù)據(jù)庫(kù)的檢索性能。

(3)研發(fā)了基于Hadoop的農(nóng)田大數(shù)據(jù)平臺(tái)，并對(duì)該平臺(tái)進(jìn)行了壓力測(cè)試，測(cè)試結(jié)果表明，該平臺(tái)在高并發(fā)量(5×105次)時(shí)，優(yōu)化后系統(tǒng)的RT提高了2.5倍，平均響應(yīng)時(shí)間為183 ms、系統(tǒng)的QPS及TPS提高了1倍左右，可保持系統(tǒng)的安全與穩(wěn)定。目前該平臺(tái)已具備農(nóng)田田間管理功能，能對(duì)農(nóng)田田塊的大數(shù)據(jù)進(jìn)行高效整合與處理，對(duì)指導(dǎo)大規(guī)模農(nóng)田的安全生產(chǎn)與分析決策具有重大意義。