苑嚴偉 冀福華 趙 博 姜含露 王 猛 樊學謙
(中國農業(yè)機械化科學研究院土壤植物機器系統(tǒng)技術國家重點實驗室, 北京 100083)
農田是農業(yè)生產的載體[1-4],我國農田呈現(xiàn)數(shù)量多、田塊小、形態(tài)各異、信息多樣化等特點,農田信息的多元異構、海量等特性已成為現(xiàn)代農業(yè)信息化發(fā)展的難題,為提高我國農業(yè)數(shù)字化與信息化程度,有必要構建面向精準農業(yè)的農田大數(shù)據(jù)平臺,以實時、動態(tài)、高效地管理農田信息。
隨著物聯(lián)網、云計算、大數(shù)據(jù)等信息技術的發(fā)展,農田數(shù)字化已成為現(xiàn)代農業(yè)發(fā)展的主要方向之一。國外關于農田數(shù)據(jù)的研究較早,到目前為止,國外已有成熟的農田信息管理系統(tǒng)[5-7],如:美國凱斯公司的AFS系統(tǒng)、約翰迪爾公司的GreenStar系統(tǒng)以及AgLeader的PF(Precision Farming), 這些都是相對規(guī)范且成熟的農田數(shù)據(jù)模型。另外,國外研發(fā)了與農田數(shù)據(jù)相關的智能農業(yè)決策系統(tǒng),如Farmeron公司[8]在2011 年推出了基于Web 端的農場管理平臺,提供相對可靠的生產分析報告,以指導農民進行生產規(guī)劃;VitalFields公司[9]以氣象預測、病蟲害、成本投入為研究對象,提供農作物種植階段的相關服務,使得管理農場更加高效;2017年OneSoil公司[10]通過歐洲空間局的衛(wèi)星影像和Mapbox的數(shù)據(jù),利用人工智能的算法,推出了包括歐洲和美國超過5 700萬塊農田的交互式數(shù)字地圖,用于自動檢測地塊、識別作物類型和監(jiān)測作物發(fā)育。國外的地塊大多為標準農場,而且在作物生產管理的方法和習慣方面與國內存在較大差異,國外的農田田塊數(shù)據(jù)模型不適合我國復雜農情與多元經營模式。因此,國內仍需開發(fā)符合我國國情的農田數(shù)據(jù)模型與大數(shù)據(jù)平臺。
國內關于農田數(shù)據(jù)的理論研究起步較晚。近年來,在國家十三五規(guī)劃的帶動下,與農田數(shù)據(jù)相關的技術發(fā)展較快,主要表現(xiàn)為多平臺、多用途、多方法面向個性化的農田信息存儲技術研究與實現(xiàn)。文獻[11]利用1957—2007年河南省30個縣、市的氣象、土壤、作物等數(shù)據(jù)信息,構建了基于元數(shù)據(jù)的農田信息的存儲、管理和共享模型;文獻[12]以土地所有者、種植管理者、施肥管理、殺蟲噴藥等信息作為屬性信息,構建了基于圖的農田數(shù)據(jù)模型;文獻[13]以土壤信息、環(huán)境信息、田間信息、GPS定位信息等作為屬性信息,構建了基于GDAL的農田信息數(shù)據(jù)模型;文獻[14]以河南省鞏義市吳溝村為例, 以衛(wèi)星遙感圖像為建庫數(shù)字化參照依據(jù), 采用目視解譯方法, 利用ERDAS Imagine 8.6和MapInfo Professional 7.0 SCP為數(shù)據(jù)庫平臺,依次提取旱地梯田、旱坡地、菜地、退耕還林地等不同田塊圖層,設計了基于RS、GIS的村域農田數(shù)據(jù)庫。文獻[15]以無線傳感器采集平臺的空氣溫濕度、風速、風向、光照為依據(jù),建立了基于無線傳感網的農田數(shù)據(jù)管理系統(tǒng)。國內研究大都基于傳統(tǒng)的數(shù)據(jù)模型進行數(shù)據(jù)的儲存和查詢[16]。而隨著數(shù)據(jù)量的增大,大數(shù)據(jù)的海量、非結構化的特性導致了傳統(tǒng)數(shù)據(jù)庫難以滿足大數(shù)據(jù)的存儲與高并發(fā)的訪問需求,海量異構農田數(shù)據(jù)多樣性、龐雜導致信息無法有效重構,農田田塊大數(shù)據(jù)處理過程中易產生云端運算負擔大、響應時間慢等問題。另外,傳統(tǒng)的數(shù)據(jù)單機處理模式很難提供相對高效的計算資源整合,導致大量的硬件資源浪費。
針對上述問題,本文在前期農機深松監(jiān)測系統(tǒng)的基礎上,對農田數(shù)據(jù)在解析、存儲與處理過程中的技術細節(jié)進行研究,建立基于Hadoop的農田大數(shù)據(jù)平臺,對農田田塊在作物的耕、種、管、收等過程中產生的海量農田數(shù)據(jù)進行動態(tài)管理。
基于Hadoop的農田大數(shù)據(jù)平臺可用于分布在全國各地的農業(yè)合作社農田田塊信息管理。該平臺將大數(shù)據(jù)、物聯(lián)網、WebGIS等技術進行深度融合,向用戶提供農田田塊數(shù)據(jù)的快速檢索、處理和動態(tài)展示。其總體架構如圖1所示,主要包括感知層、網絡層、中間層和應用層。
圖1 系統(tǒng)總體架構Fig.1 Overall architecture of system
基于Hadoop的農田大數(shù)據(jù)平臺的功能設計如圖2所示,主要包括角色管理、地塊管理、設備管理、農資管理、作業(yè)管理、統(tǒng)計管理,其主要面向對象為各種用戶。
圖2 系統(tǒng)功能設計Fig.2 Function module of system
(1)角色管理
平臺的用戶主要分為管理員和普通用戶兩種類型,不同類型的用戶會分配不同的使用權限,如政府機關具備所管轄合作社的瀏覽權限、任務分配權限等;合作社具備本合作社業(yè)務的日常維護權限。另外為了便于系統(tǒng)的維護,設置了管理員角色作為最高權限。
(2)地塊管理
地塊管理是整個大數(shù)據(jù)平臺最重要的環(huán)節(jié),它負責管理地塊的位置信息、作業(yè)信息、氣象信息、附著物信息,為地塊的精細化管理提供了豐富的數(shù)據(jù)支持,具備地塊信息的錄入與檢索,并通過WebGIS技術,將部分數(shù)據(jù)可視化。
(3)設備管理
設備管理主要有兩個作用:獲取田塊信息和進行田塊作業(yè)。設備管理的內容主要為設備的基本信息、工作詳情。其中包括錄入設備基本信息和設備工作詳情,設備工作詳情主要指用戶在客戶端可實時查詢設備的位置及機手信息,其中設備位置信息可調用天地圖API實時獲取。
(4)作業(yè)管理
作業(yè)管理主要包括作業(yè)類型、作業(yè)詳情、作業(yè)記錄、作業(yè)時間4部分。其中作業(yè)類型為農機作業(yè)的基本類型,如:深松、打捆、籽粒直收、植保等;作業(yè)詳情為實時展示作業(yè)現(xiàn)場并抓拍作業(yè)場景;作業(yè)完成情況是指作業(yè)軌跡、作業(yè)的完成率,已作業(yè)面積;作業(yè)記錄是指作業(yè)的歷史信息,這些信息包括作業(yè)軌跡、作業(yè)面積、機手信息、作業(yè)時間、作業(yè)時隨機抓拍的圖像。
(5)農資管理
農資管理是對地塊的使用資源(化肥、農藥等)的統(tǒng)一整合,可對地塊的農資使用情況提供較為詳盡的記錄。另外,可記錄地塊的產出數(shù)據(jù),這些數(shù)據(jù)都能為農作物科學管理及分析決策提供數(shù)據(jù)源支持。
(6)統(tǒng)計管理
統(tǒng)計管理是在農資管理、設備管理、地塊管理的基礎上,對農田數(shù)據(jù)進行深層次的加工,比如:統(tǒng)計造成不同地塊產量差異性的原因,探究農機作業(yè)、農資使用與農作物產量之間關系。
本文以農田田塊為研究對象進行農田數(shù)據(jù)的分析,農田田塊數(shù)據(jù)包括田塊的位置信息、氣象信息、作業(yè)信息及附著物信息等。位置信息包含田塊經度、緯度、海拔及坡度等地理信息,氣象信息包括歷年的溫度、濕度、光照、風速、風向等;作業(yè)信息主要是不同農業(yè)機械的歷年與實時作業(yè)信息,如深松機作業(yè)深度、播種機播種施肥量、植保機噴藥量、收獲機產量分布信息等;附著物信息是指對農業(yè)生產影響較大的信息,如水井、電線桿、農舍的經緯度和局部輪廓等。數(shù)據(jù)結構如圖3所示。由于數(shù)據(jù)量大,為了便于檢索和存儲,現(xiàn)有的農田田塊大數(shù)據(jù)平臺將數(shù)據(jù)進行分表保存處理。
圖3 農田數(shù)據(jù)結構Fig.3 Data structure of farmland
農田田塊數(shù)據(jù)類型復雜,不僅有常見的結構化數(shù)據(jù),而且還有半結構化數(shù)據(jù)。 HBase[17]作為高性能、列存儲、可伸縮、實時讀寫的分布式數(shù)據(jù)庫,可支持集群存儲海量數(shù)據(jù)。目前由于對農田數(shù)據(jù)的存儲多選用傳統(tǒng)的數(shù)據(jù)庫,如Mysql、PostgreSql等,這些數(shù)據(jù)庫在解決事務性問題上有其獨特的優(yōu)勢,然而隨著數(shù)據(jù)量的增加,數(shù)據(jù)存儲的因素主要從數(shù)據(jù)檢索性能來考量。
數(shù)據(jù)庫Hbase的檢索過程如下:
(1)客戶端從ZooKeeper找到存放在Master上的Region服務器的位置信息、Region的元數(shù)據(jù)信息以及Region與Region服務器的映射關系。
(2)通過Region服務器檢索存儲在Region的數(shù)據(jù)。
(3)通過HDFS(Hadoop distributed files system)讀取存儲在磁盤上的數(shù)據(jù)。
Hbase[18]的部署服從主從原則,依附于Hadoop集群。本文部署的Hbase的所有協(xié)調工作均由ZooKeeper來執(zhí)行,來實現(xiàn)HMater的選舉與主備的切換、系統(tǒng)容錯、任務管理。而且Hbase與ZooKeeper為獨立部署,這樣可避免二者發(fā)生強耦合,便于后期集群的升級與維護,由于ZooKeeper具備輕量化的特性,部署的ZooKeeper仍構建于HDFS之上,此外,它還提供了整個大數(shù)據(jù)集群的負載均衡。
Hbase表主要由行鍵(Rowkey)、列族、列限定符和時間戳等組成。行鍵是其主鍵,在滿足行鍵設計長度原則、散列原則、唯一原則的前提下,為提高數(shù)據(jù)對內存的使用率,對于64位操作系統(tǒng)的行鍵設計應為8字節(jié)的倍數(shù),本設計中選擇16字節(jié)行鍵設計。將行鍵的高位作為散列字段,低位作為時間值,可以使得數(shù)據(jù)相對均衡地分布在Region服務器中。由于Hbase的行鍵按字典順序增加,為了避免寫熱點,設計Rowkey需使不同行的數(shù)據(jù)放在同一個Region中,如果沒有散列字段,直接存放時間值將可能產生所有新數(shù)據(jù)都在一個Region服務器上堆積的熱點現(xiàn)象,導致數(shù)據(jù)檢索時負載將會集中在個別Region服務器,降低查詢效率。在農田大數(shù)據(jù)平臺中,由于地塊編號、設備號、作業(yè)人及作業(yè)時間等字段使用較為頻繁,所以在設計行鍵時包含了上述信息。同時,由于地塊編號采用字母+數(shù)字的格式,將地塊編號寫入開端可以避免寫入數(shù)據(jù)時行鍵的順序遞增的問題。因此,本系統(tǒng)行鍵設計為:Rowkey=“地塊編號+歸屬人+作業(yè)人+時間”。
農田田塊數(shù)據(jù)主要字段包括:地塊編號、地塊位置、地塊面積、地塊歸屬人、地塊管理人、作業(yè)類型、設備號、車牌號、作業(yè)時間、溫度、濕度、光照強度、風速等128個字段。對于作業(yè)時間要求精確到分鐘,采用8位占位符進行存儲。對于位置信息采用獨立的幾何屬性列族存儲;其他字符均采用字符型。各字段長度不一,由于列族少時,底層的I/O開銷就會降低,因此所有非幾何字段構成一個唯一的列族,其具體設計如表1所示。
表1 農田數(shù)據(jù)表結構Tab.1 Structure of land data
Solr[19]是Apache基金會下的一款基于Lucene的全文搜索服務器。用戶可通過Http協(xié)議獲得該系統(tǒng)對外提供的類似于java-web的API,并向該系統(tǒng)提交生成索引的XML文件,最后可通過Get請求獲取索引結果。另外,Solr的搜索引擎采用Java5開發(fā),而本文的大數(shù)據(jù)平臺也采用了Java開發(fā),可以使得大數(shù)據(jù)平臺很好地兼容Solr。因此,本文選取了Solr進行系統(tǒng)二級索引。
根據(jù)表1添加了4個索引字段,分別為:地塊類型(landType)、地塊面積(landArea)、地塊產量(landOutput)和地塊作業(yè)類型(workType)。其配置信息中name表示字段名;type表示定義的字段的屬性,一般情況下integer字段的索引效果更好;indexed表示是否索引,作為索引字段必需設置為true;stored表示是否被存儲,為了改進性能,對于不需要作為結果存儲的均設為false;multiValued表示是否包含多個值,對于可能存在多值的字段全部設為true,從而避免構建索引時報錯,索引字段的類型與配置信息具體如下
〈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〉
構建二級非主鍵索引后,數(shù)據(jù)傳輸過程為:采集到的農田數(shù)據(jù)分別存儲在采集終端和大數(shù)據(jù)集群服務器上。采集終端可以存儲近期內一部分數(shù)據(jù),主要是為防止采集終端野外作業(yè)時由于信號丟失等引起短時間內數(shù)據(jù)無法正常傳輸?shù)椒掌鞫说膯栴}。采集終端采集到的數(shù)據(jù)(生產者)會通過kafka將數(shù)據(jù)打包發(fā)送到數(shù)據(jù)中心(消費者),數(shù)據(jù)中心解析之后存儲在構建于HDFS之上的Hbase數(shù)據(jù)庫中。系統(tǒng)的元數(shù)據(jù)信息存儲在Master結點的內存中,元數(shù)據(jù)信息主要包括維護文件系統(tǒng)的FsImage和記錄操作日志的EditLog。當客戶端發(fā)出數(shù)據(jù)請求時,數(shù)據(jù)處理相關模塊首先判斷是否存在主鍵索引,若存在則直接通過Hbase的主鍵索引檢索數(shù)據(jù),若檢索條件涉及二級非主鍵索引字段,則通過多條件查詢到相關主鍵值,最后通過主鍵在Hbase里進行檢索。該索引模塊設計在一定程度上可提高檢索速度。
系統(tǒng)部署在阿里云服務器,軟件環(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內存,20 TB硬盤,千兆以太網,各個節(jié)點配置信息如表2所示。
表2 服務器各節(jié)點信息Tab.2 Server nodes information
實驗數(shù)據(jù)選取了某省農機深松、植保、保護性耕作等8種作業(yè)類型產生的100 TB作業(yè)數(shù)據(jù),該數(shù)據(jù)集記錄了某省2015—2018年的作業(yè)情況,每條記錄不等長,數(shù)據(jù)信息的類型包括文字、圖像、視頻等,數(shù)據(jù)存儲結構如圖3所示。本文用于對比實驗的數(shù)據(jù)是通過Sqoop[20]工具導入,硬件環(huán)境與上述Hadoop集群保持一致。
3.3.1多條件檢索、性能分析及其優(yōu)化
檢索數(shù)據(jù)仍采用上述數(shù)據(jù),檢索條件依次增加,本文設定的檢索條件的個數(shù)(n)分別為2、3、4;檢索次數(shù)為10次,檢索時間取其平均值。其檢索性能對比如圖4所示。
圖4 n為2、3、4多條件檢索性能對比Fig.4 Contrast graphs of retrieval performance
由圖4可知,隨著數(shù)據(jù)量的增加,Hbase的響應速度降低較為明顯,當數(shù)據(jù)規(guī)模達到千萬級時,響應時間大于3 s。從理論層面上分析Hbase是一種面向列的數(shù)據(jù)庫,其底層在行鍵上建立了基于行鍵的類B+樹索引,可以相對高效地支持基于行鍵的數(shù)據(jù)檢索;對于多條件查詢的非行鍵數(shù)據(jù)的檢索,系統(tǒng)需要調用全表掃描的功能,數(shù)據(jù)的整體檢索效率低下。隨著數(shù)據(jù)量的不斷增加,優(yōu)化后的索引方法的優(yōu)勢越來越明顯,當數(shù)據(jù)量達到5×107條時,響應時間小于1 s,優(yōu)化的性能與原生Hbase相比提高了3倍,能滿足用戶的需求。
為了更好地說明問題,本文對檢索數(shù)據(jù)做了縱向對比,選取檢索規(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ù)在減少,相當于減少了數(shù)據(jù)的并發(fā)量,因此,檢索時間持續(xù)下降。
3.3.2系統(tǒng)壓力測試
為了驗證系統(tǒng)架構的合理性與安全性,本文選取了請求次數(shù)較多的大數(shù)據(jù)平臺首頁進行了壓力測試,首頁界面如圖5所示。選用YCSB[21]作為系統(tǒng)的壓力測試工具,選取每秒查詢率(QPS)、吞吐量(TPS)和響應時間(RT)等作為系統(tǒng)性能度量的主要參數(shù)。本文通過多線程并發(fā)的方式模擬不同角色的用戶,表3為5×105次并發(fā)用戶壓力測試結果,測試時間為5 min。實驗結果取5次實驗的平均值。
圖5 大數(shù)據(jù)平臺首頁Fig.5 Home page of big data platform
參數(shù) Hbase二級索引Hbase每秒查詢率(QPS)233821424211每秒吞吐量(TPS)46588657響應時間(RT)/ms643183
通過測試結果,可以得出在高并發(fā)量(5×105次)時,優(yōu)化后系統(tǒng)的RT提高了2.5倍。系統(tǒ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ù)的結果,每組實驗進行5次,結果取5次插入的平均值。
由表4可知,在二級索引情況下,插入數(shù)據(jù)需要消耗的時間更多一些,這是由于二級索引需要觸發(fā)協(xié)處理器將索引數(shù)據(jù)不斷存入Solr中,隨著數(shù)據(jù)量增多,與原生Hbase相比二級索引插入性能不斷降低。從實驗結果來看,3組實驗的插入性能平均降低了13.3%。降低的插入性能與提高的檢索性能相比,可忽略。
表4 插入響應時間測試結果Tab.4 Results of testing for insert performance ms
(1)研究了負載均衡大規(guī)模集群數(shù)據(jù)處理技術,實現(xiàn)了農田田間耕、種、管、收及農田田塊自身產生的多源異構海量數(shù)據(jù)的存儲與檢索,保證了海量農田田塊數(shù)據(jù)存儲的安全性與檢索的高效性。
(2)針對Hbase數(shù)據(jù)庫在農田田間數(shù)據(jù)進行多條件檢索時性能不佳的問題,研究了面向列數(shù)據(jù)庫高效索引技術,提出了基于Solr二級非主鍵索引的檢索方法,在數(shù)據(jù)規(guī)模達到5×107條時,響應時間小于1 s,農田田塊數(shù)據(jù)多條件關聯(lián)檢索時,相對原生Hbase數(shù)據(jù)庫優(yōu)化性能提高了3倍,大大提高了數(shù)據(jù)庫的檢索性能。
(3)研發(fā)了基于Hadoop的農田大數(shù)據(jù)平臺,并對該平臺進行了壓力測試,測試結果表明,該平臺在高并發(fā)量(5×105次)時,優(yōu)化后系統(tǒng)的RT提高了2.5倍,平均響應時間為183 ms、系統(tǒng)的QPS及TPS提高了1倍左右,可保持系統(tǒng)的安全與穩(wěn)定。目前該平臺已具備農田田間管理功能,能對農田田塊的大數(shù)據(jù)進行高效整合與處理,對指導大規(guī)模農田的安全生產與分析決策具有重大意義。