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

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

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

0 引言

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

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

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

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

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

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

基于Hadoop的農(nóng)田大數(shù)據(jù)平臺可用于分布在全國各地的農(nóng)業(yè)合作社農(nóng)田田塊信息管理。該平臺將大數(shù)據(jù)、物聯(lián)網(wǎng)、WebGIS等技術(shù)進行深度融合，向用戶提供農(nóng)田田塊數(shù)據(jù)的快速檢索、處理和動態(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è)計

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

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

(1)角色管理

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

(2)地塊管理

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

(3)設(shè)備管理

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

(4)作業(yè)管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(3)通過HDFS(Hadoop distributed files system)讀取存儲在磁盤上的數(shù)據(jù)。

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

2.3 行鍵

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

2.4 列族

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

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

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

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

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

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

3 實驗結(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型號為Intel 酷睿i7 8700K， 3.7 GHz主頻，32 GB內(nèi)存，20 TB硬盤，千兆以太網(wǎng)，各個節(jié)點配置信息如表2所示。

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

3.2 數(shù)據(jù)來源

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)論

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

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

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