森林生態(tài)站大數(shù)據(jù)快速存儲與索引方法

王新陽 賈相宇 陳志泊 崔曉暉 許 福

(1.北京林業(yè)大學(xué)信息學(xué)院， 北京 100083； 2.國家林業(yè)和草原局林業(yè)智能信息處理工程技術(shù)研究中心， 北京 100083)

0 引言

為了更好地對森林生態(tài)系統(tǒng)的服務(wù)功能進(jìn)行評估，我國在各地建立了大量的森林生態(tài)定位觀測站，針對典型生態(tài)系統(tǒng)類型進(jìn)行了長期連續(xù)定位觀測[1-2]。迄今為止，中國已有180多個國家級森林生態(tài)定位觀測站(以下簡稱生態(tài)站)，分布在不同氣候區(qū)，覆蓋不同類型的生態(tài)系統(tǒng)[3-4]。生態(tài)觀測站點能夠進(jìn)行長期、連續(xù)地觀測并自動感知和獲取有關(guān)觀測區(qū)的水、土、氣、生等方面的生態(tài)因子數(shù)據(jù)，所累積的數(shù)據(jù)具有海量性、多樣性等特點[5-10]。然而，采用單一站點對生態(tài)數(shù)據(jù)進(jìn)行存儲和管理的模式已經(jīng)無法滿足海量異構(gòu)生態(tài)數(shù)據(jù)的存儲和管理需求，且各生態(tài)站點之間相互獨立，逐漸形成信息孤島，更不能滿足面向生態(tài)服務(wù)功能評價所需要的多站聯(lián)合分析、數(shù)據(jù)挖掘、實時檢索以及高并發(fā)的訪問需求，并且海量生態(tài)數(shù)據(jù)具有多樣性，龐雜且無法重構(gòu)，生態(tài)數(shù)據(jù)處理過程中容易產(chǎn)生運(yùn)算負(fù)擔(dān)大、檢索時間慢等問題[11-13]。因此，研究面向森林生態(tài)大數(shù)據(jù)的存儲和索引模型，并基于此建立海量生態(tài)數(shù)據(jù)管理平臺顯得非常有必要。目前大多數(shù)生態(tài)站存儲架構(gòu)以MySQL為代表的關(guān)系型數(shù)據(jù)庫為主，如文獻(xiàn)[14]提出通過MS-SQL Server復(fù)制技術(shù)實現(xiàn)數(shù)字化森林生態(tài)站的應(yīng)用，文獻(xiàn)[15]提出通過調(diào)用云平臺提供的REST Servce API來實現(xiàn)西天山森林生態(tài)站數(shù)據(jù)管理系統(tǒng)建設(shè)，可以保證事務(wù)的一致性，但在拓展性、容錯性和可用性方面都不能滿足海量異構(gòu)數(shù)據(jù)的存儲和管理。針對傳統(tǒng)關(guān)系型數(shù)據(jù)庫的劣勢，采用Hadoop[16-17]分布式平臺和HBase[18]分布式NoSQL數(shù)據(jù)庫，在擴(kuò)展性、容錯性和可用性方面具有巨大優(yōu)勢，如文獻(xiàn)[19]為解決海量GIS數(shù)據(jù)設(shè)計的基于Hadoop的GIS平臺，文獻(xiàn)[20]通過Hadoop構(gòu)建了森林資源信息平臺，為各級部門提供更加有效科學(xué)、準(zhǔn)確的數(shù)據(jù)參考。Hadoop和HBase技術(shù)的誕生為解決生態(tài)大數(shù)據(jù)高效存儲和快速索引奠定了重要技術(shù)的基礎(chǔ)，但原生Hadoop不能很好地處理小文件問題，原生HBase默認(rèn)只支持一級索引[21]。

以上這些平臺主要存在2個問題：①原生Hadoop在存儲方面沒有解決海量小圖像的存儲問題和沒有對海量數(shù)據(jù)進(jìn)行分區(qū)處理。②原生HBase在面對海量數(shù)據(jù)多維查詢時沒有提供很好的快速檢索方案。

生態(tài)站產(chǎn)生的大量小文件會導(dǎo)致NameNode內(nèi)存瓶頸和檢索性能低下，文獻(xiàn)[22]提出Harballing技術(shù)，通過一種打包技術(shù)將小文件打包成大文件,但預(yù)處理花費時間比較長。文獻(xiàn)[23]提出將相同類型的小文件合并為大文件，并建立小文件到合并大文件的索引關(guān)系，索引關(guān)系存儲于HashMap中，這種方式如果沒有命中緩存，讀取性能并不高。文獻(xiàn)[24]提出了利用SequenceFile技術(shù)實現(xiàn)海量物聯(lián)網(wǎng)圖像打包合并策略，這種方式可以解決NameNode內(nèi)存過大問題，但并未考慮圖像之間的關(guān)系，不利于關(guān)聯(lián)查詢；對于GIS數(shù)據(jù)，文獻(xiàn)[25]利用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫存儲，但該種架構(gòu)面臨生態(tài)站海量GIS數(shù)據(jù)時，會有拓展性差、存取效率低等問題。另外，對于海量生態(tài)數(shù)據(jù)應(yīng)用場景，如果沒有做到合理的預(yù)分區(qū)，將會造成數(shù)據(jù)傾斜，極端情況下，分布式存儲變成了單節(jié)點存儲。

直接利用HBase提供的列簇和主鍵(RowKey)機(jī)制組織和存儲生態(tài)數(shù)據(jù)會存在很多問題，如HBase并未提供對多維生態(tài)數(shù)據(jù)的原生支持，只支持對數(shù)據(jù)記錄的主鍵上建立一維索引，在對主鍵之外的其他屬性信息進(jìn)行查詢時，效率極低。根據(jù)實現(xiàn)方式的不同，目前比較主流的方式可以分為雙層索引、全局分布式索引、位圖索引和基于Hadoop框架的索引[26]。雙層索引的代表是RT-CAN[27]和A-Tree[28]，但這種索引維護(hù)起來代價高，實現(xiàn)很復(fù)雜，面對生態(tài)領(lǐng)域多維查詢時，性能急劇下降；全局分布式索引實現(xiàn)起來相對簡單，但對于生態(tài)領(lǐng)域大數(shù)據(jù)量的場景下，無法滿足數(shù)據(jù)頻繁插入；位圖索引典型的是RBI[29],可以適合高并發(fā)的場景，但對于生態(tài)數(shù)據(jù)劃分規(guī)則復(fù)雜的場景時，會造成false positives的場景;而基于Hadoop框架實現(xiàn)的索引，大多是借助Hadoop生態(tài)組件來構(gòu)建索引，以此來提高性能，其中包括基于Coprocessor方案、ApachePhoenix方案[30]和華為HIndex方案[31]等，該方案需要為每一個索引列構(gòu)建一個索引表，以索引的值作為新的RowKey，實現(xiàn)索引列與原有RowKey的映射，但數(shù)據(jù)存儲和索引進(jìn)行耦合，具有一定的入侵性，會對RegionServer性能產(chǎn)生一定影響。文獻(xiàn)[32]提出了一種基于Solr的HBase海量數(shù)據(jù)的二級索引方案，將數(shù)據(jù)存儲和索引進(jìn)行分離，但Solr實時建立索引時，會產(chǎn)生I/O阻塞，查詢性能較差，并且隨著數(shù)據(jù)量增加，檢索效率會變得更低，同時面對生態(tài)數(shù)據(jù)時并沒有解決對多條件查詢優(yōu)化的問題；文獻(xiàn)[33]提出互補(bǔ)聚簇式索引，將數(shù)據(jù)詳細(xì)信息也放入索引表，這樣把隨機(jī)讀變成了順序讀，但當(dāng)索引列比較多時，空間開銷會更大，索引更新代價會比較高，影響了吞吐量；MD-HBase利用KD-tree對多維空間數(shù)據(jù)進(jìn)行劃分，根據(jù)最長公共前綴的方式計算得到每個子空間名稱，但該方法會造成數(shù)據(jù)一致性問題[34]。以上二級索引方案都不適合生態(tài)站的應(yīng)用場景，ElasticSearch對系統(tǒng)的耦合度低且簡單易行，在實時搜索方面性能很高，同時可以定制化專門生態(tài)數(shù)據(jù)的評分機(jī)制，所以采用ElasticSearch作為HBase的二級索引解決方案。

針對生態(tài)大數(shù)據(jù)存儲和快速索引方面的迫切需求，以及現(xiàn)有森林生態(tài)數(shù)據(jù)方案存在的弊端問題，本文在存儲方面科學(xué)地設(shè)計RowKey，其次設(shè)計預(yù)分區(qū)算法保證數(shù)據(jù)分布一致；針對海量小文件處理問題，提出基于數(shù)據(jù)站點及時間關(guān)聯(lián)性的關(guān)聯(lián)合并存儲方法(Redis based station time cooperate，RBSTC)；針對GIS數(shù)據(jù)存儲問題，提出HBase和GeoTools存儲方法[35]；在索引方面，根據(jù)生態(tài)站點的特點設(shè)計RowKey，并設(shè)計基于索引數(shù)據(jù)和服務(wù)器性能評估的ElasticSearch分片算法，優(yōu)化多條件檢索二級索引失效問題[36]。以期能夠滿足海量異構(gòu)生態(tài)數(shù)據(jù)的存儲和高效檢索，為生態(tài)監(jiān)測數(shù)據(jù)高效存儲、管理和分析提供技術(shù)支撐。

1 森林生態(tài)大數(shù)據(jù)平臺總體架構(gòu)

從森林生態(tài)數(shù)據(jù)特征出發(fā)，提出基于Hadoop的森林生態(tài)大數(shù)據(jù)平臺，可用于分布在全國各地的生態(tài)站數(shù)據(jù)管理。平臺深度集成大數(shù)據(jù)、物聯(lián)網(wǎng)、人工智能等技術(shù)，為用戶提供森林生態(tài)數(shù)據(jù)的快速檢索、處理和可視化分析。其總體架構(gòu)如圖1所示，主要包括應(yīng)用層、服務(wù)層、存儲層。

存儲層是森林生態(tài)大數(shù)據(jù)模型中最重要的部分，其主要作用是用來持久化存儲。該層包括基于分布式的HDFS和面向列的HBase數(shù)據(jù)庫。HDFS存儲森林生態(tài)數(shù)據(jù)中的視頻、圖像等非結(jié)構(gòu)化數(shù)據(jù)；HBase數(shù)據(jù)庫用來存儲森林生態(tài)中產(chǎn)生的結(jié)構(gòu)化數(shù)據(jù)。

服務(wù)層主要包括數(shù)據(jù)轉(zhuǎn)換、圖像合并、GeoTools、視頻分割、預(yù)分區(qū)設(shè)計和HBase二級索引。數(shù)據(jù)轉(zhuǎn)換主要是因為接入數(shù)據(jù)復(fù)雜且海量，同時各傳感器型號類型不同，數(shù)據(jù)傳輸格式不統(tǒng)一，利用數(shù)據(jù)轉(zhuǎn)換模塊將數(shù)據(jù)繼續(xù)進(jìn)行統(tǒng)一，有利于系統(tǒng)后期拓展性能增強(qiáng)；圖像合并模塊主要解決的是Hadoop處理海量小文件時性能不足的問題，通過基于數(shù)據(jù)站點及時間關(guān)聯(lián)性算法對小文件進(jìn)行合并，達(dá)到閾值后存儲HDFS上；GeoTools主要針對GIS數(shù)據(jù)解析后存入HBase數(shù)據(jù)庫；視頻分割是將大文件按照HDFS數(shù)據(jù)塊大小進(jìn)行分割后，直接儲存在HDFS上；HBase二級索引模塊主要解決HBase在查詢主鍵之外的數(shù)據(jù)索引失效的問題，可以實現(xiàn)數(shù)據(jù)的高效檢索。

應(yīng)用層主要是面向各類用戶對森林生態(tài)大數(shù)據(jù)平臺中的各種業(yè)務(wù)進(jìn)行統(tǒng)一數(shù)據(jù)處理。用戶可以對森林生態(tài)數(shù)據(jù)進(jìn)行查詢、分析、管理和數(shù)據(jù)下載等。

2 森林生態(tài)大數(shù)據(jù)平臺關(guān)鍵技術(shù)

2.1 業(yè)務(wù)流程設(shè)計

目前森林生態(tài)站點采集的數(shù)據(jù)主要分為圖像、視頻、GIS數(shù)據(jù)、文本數(shù)據(jù)的非結(jié)構(gòu)化數(shù)據(jù)及結(jié)構(gòu)化數(shù)據(jù)5大類，文本數(shù)據(jù)主要包括Excel文件和TXT文件等，業(yè)務(wù)處理模塊需要統(tǒng)一數(shù)據(jù)訪問接口對需要存儲的數(shù)據(jù)類型進(jìn)行判斷，并針對不同的數(shù)據(jù)類型，采取不用的存儲策略，數(shù)據(jù)寫入業(yè)務(wù)算法的處理偽代碼：

輸入：生態(tài)站實時傳入數(shù)據(jù)

輸出：HDFS和HBase數(shù)據(jù)庫

令 RealtimeData=實時數(shù)據(jù)流集合

BlockCapacity為每個文件塊的容量

while RealtimeData≠?

if RealtimeData為圖像類型數(shù)據(jù)

將圖像加入合并隊列基于Redis合并；

if BlockCapacity到達(dá)閾值

構(gòu)建索引信息并寫入HDFS；

if RealtimeData為視頻類型數(shù)據(jù)

if BlockCapacity > 128MB

視頻分塊；

構(gòu)建索引信息并寫入HDFS；

if RealtimeData為GIS類型數(shù)據(jù)

GeoTools工具解析；

構(gòu)建索引信息并寫入HDFS；

if RealtimeData為文本類型數(shù)據(jù)

if 為Excel類型

Excel解析器解析；

if 為TXT類型

TXT解析器解析；

?

構(gòu)建索引寫入HBase

if RealtimeData為結(jié)構(gòu)化數(shù)據(jù)

構(gòu)建索引寫入HBase

end while

當(dāng)存儲圖像時，因為生態(tài)監(jiān)測中的圖像都是以海量的小文件為主(每幅圖像通常在幾兆字節(jié)以內(nèi))，而HDFS的數(shù)據(jù)塊(Block)默認(rèn)容量為128 MB，當(dāng)把一幅圖像存儲到一個數(shù)據(jù)塊中時，雖然不會占滿整個數(shù)據(jù)塊，海量小文件不會對硬盤存儲產(chǎn)生壓力，但會增加HDFS中NameNode的內(nèi)存消耗，而且，讀取小尺寸圖像會浪費大量時間。

一般情況下NameNode的元數(shù)據(jù)容量為250 B，默認(rèn)3個副本的情況下，2個新副本的元數(shù)據(jù)容量為368 B。當(dāng)n個小圖像在HDFS上進(jìn)行3副本存儲時，NameNode的內(nèi)存消耗M隨著n的增大而增大。

(1)

式中a——HDFS沒有數(shù)據(jù)時NameNode所占內(nèi)存容量

b——每個數(shù)據(jù)塊在NameNode的內(nèi)存消耗

B——HDFS數(shù)據(jù)塊容量

F——HDFS中存儲的n個圖像所占的內(nèi)存容量

因此，當(dāng)數(shù)據(jù)為圖像時，采用對圖像進(jìn)行基于數(shù)據(jù)站點及時間關(guān)聯(lián)性合并存儲的策略，即：首先將圖像寫入一個圖像隊列，判斷圖像隊列的值是否大于一個Block容量，如果不夠一個Block的容量則繼續(xù)寫入；如果大于一個Block的容量，則直接存入HDFS中，并建立索引，將圖像元信息存入HBase中。

當(dāng)寫入數(shù)據(jù)為視頻時，首先判斷是否超過一個Block容量，如果沒有超過，直接按照一個Block的容量來處理，如果大于一個Block的容量，則直接按照HDFS分塊策略進(jìn)行分塊，建立索引，并將視頻元數(shù)據(jù)信息存入HBase中。

當(dāng)寫入數(shù)據(jù)為GIS數(shù)據(jù)時，通過GeoTools工具進(jìn)行解析，存入HBase數(shù)據(jù)庫。

當(dāng)寫入數(shù)據(jù)為文本數(shù)據(jù)時，通過對應(yīng)服務(wù)層解析，將文本數(shù)據(jù)轉(zhuǎn)成結(jié)構(gòu)化數(shù)據(jù)后，存入HBase數(shù)據(jù)庫。

當(dāng)寫入數(shù)據(jù)為結(jié)構(gòu)化數(shù)據(jù)時，直接將數(shù)據(jù)存入HBase數(shù)據(jù)庫。

2.2 預(yù)分區(qū)設(shè)計算法

HBase在默認(rèn)情況下創(chuàng)建數(shù)據(jù)表時，會創(chuàng)建一個沒有起始和終止的Region，數(shù)據(jù)會按照鍵值對的字典升序?qū)懭朐揜egion，如果HBase的Region到達(dá)閾值，就會頻繁觸發(fā)分裂(Split)操作，會造成熱點傾斜，取值范圍為0～60。假設(shè)擬劃分成k(k為整數(shù))個分區(qū)，將0～60范圍內(nèi)數(shù)據(jù)splitKey從1開始，按照HBase預(yù)分區(qū)算法初步進(jìn)行預(yù)分區(qū)，算法偽代碼為：

輸入：擬劃分分區(qū)k，數(shù)據(jù)量為num(n)，平均寫入請求數(shù)為avg;

輸出：splitKey

splitKey(n)=n60k;

(n=1,2,…,k-1；k為整數(shù))

ifM>1 ∥進(jìn)行微調(diào)

if num(n)

splitKey(n+1)=splitKey(n+1)+x;

return;

else

splitKey(n+1)=splitKey(n+1)-x;

return;

最后根據(jù)預(yù)分區(qū)算法獲取splitKey，并創(chuàng)建預(yù)分區(qū)表，以避免熱點傾斜。

2.3 RowKey設(shè)計方案

HBase數(shù)據(jù)庫主要由行鍵、列族、列族限定符和時間戳組成。在滿足長度原則、哈希原則和唯一性原則的前提下，行鍵可以提高內(nèi)存利用率。由于生態(tài)站點查詢使用較為頻繁，所以在設(shè)計時添加該字段，同時為了記錄數(shù)據(jù)產(chǎn)生的時間以及數(shù)據(jù)的版本控制，將時間也放在主鍵RowKey內(nèi)，所以本系統(tǒng)設(shè)計的RowKey格式為：站點+時間(YYYYMMDDHHMM)。森林生態(tài)結(jié)構(gòu)化數(shù)據(jù)根據(jù)特點將其分為4個列族，分為土壤列族、氣象列族、生物多樣性列族、水文列族，共包括742個要素，如溫度、相對濕度、風(fēng)速、降水量等。一個站點在特定時間的標(biāo)識ID存儲一個RowKey，每一個RowKey會有多個列族(Column qualifer)，表示不同時間的要素值。HBase結(jié)構(gòu)及數(shù)據(jù)樣例如表1所示。

表1 RowKey設(shè)計

2.4 HBase二級索引選取及ElasticSearch索引分片算法

HBase原生不支持二級索引，對非主鍵查詢時會出現(xiàn)索引失效問題。但由于生態(tài)數(shù)據(jù)檢索時常常需要對數(shù)據(jù)某一個維度進(jìn)行統(tǒng)計分析，如根據(jù)溫度、濕度等信息進(jìn)行統(tǒng)計查詢，如果沒有二級索引，則會進(jìn)行全表掃描，效率極其低下，與傳統(tǒng)的關(guān)系型數(shù)據(jù)系統(tǒng)索引類似。HBase二級索引存儲新坐標(biāo)和現(xiàn)有坐標(biāo)之間的映射關(guān)系，因此，從索引的角度出發(fā)，選擇合適的二級索引尤為重要。

在現(xiàn)在主流的HBase二級索引方案中，Phoenix方案并沒有將數(shù)據(jù)與索引分開存儲、耦合性很強(qiáng)；在實時建立索引時，Solr會產(chǎn)生I/O阻塞，查詢性能較差，隨著數(shù)據(jù)量的增加，Solr的搜索效率會降低，而ElasticSearch沒有明顯的變化，因此選擇ElasticSearch作為二級索引。

其利用ElasticSearch提供主要索引設(shè)計的索引結(jié)構(gòu)為

PUT create_index{

"settings":{

"number_of_shards"x, ∥根據(jù)算法修正

"number_of_replicas":3

},

"mappings":{

"data_type":{

"properties":{

"dataId":{"type":"long","index":"yes","store":true},

"datayear":{type:"Int","index":"yes","store":true},

"datamonth":{type:"Int","index":"yes","store":true},

"dataday":{type:"Int","index":"yes","store":true},

"datahour":{type:"Int","index":"yes","store":true},

"datamin":{type:"Int","index":"yes","store":true},

"dataTemp":{type:"Int","index":"yes","store":true}

"rowkey":{type:"String","index":"yes","store":true}

?

} }}

}

由于生態(tài)站觀測具有長期性，所以需要在架構(gòu)設(shè)計之初，就考慮未來存儲容量的問題，但原生ElasticSearch不易確定索引分片問題，索引主分片數(shù)量設(shè)置后不能修改，分片過多資源浪費；分片過少，會導(dǎo)致索引性能和集群性能降低，且不能保證生態(tài)站未來擴(kuò)容，故針對原生ElasticSearch分片問題，提出基于索引數(shù)據(jù)和服務(wù)器性能評估的索引分片放置策略，具體ElasticSearch索引分片算法偽代碼為

輸入：數(shù)據(jù)量D，磁盤使用率ratedisk，虛擬機(jī)堆內(nèi)存容量J

輸出：索引分片配置

令nodeList=可用節(jié)點集合，nodecurrent表示現(xiàn)有節(jié)點，nodecurrent(shardNum)表示現(xiàn)有節(jié)點的shardNum；

if ratedisk<85% && nodecurrent(shardNum)

∥ES官方建議節(jié)點磁盤使用率小于85%

∥1GB堆內(nèi)存對應(yīng)20shardNum

nodeList().add(nodecurrent)；

∥k1,k2,k3,k4為權(quán)重系數(shù)

if shardNum>|nodeList|2

shardNum=|nodeList|2;

return shardNum；

同時ElasticSearch的每一個單元稱之為Document(doc)，doc和HBase中的RowKey對應(yīng)。結(jié)合生態(tài)站的常用業(yè)務(wù)，將年(year)、月(month)、日(day)、時(hour)、分(min)、氣溫(Temp)、緯度(Latitude)、濕度(Hum)作為字段建立索引，通過ElasticSearch的多條件檢索快速過濾到符合條件的RowKey，通過指定的RowKey在HBase中檢索符合條件的結(jié)果，以實現(xiàn)海量生態(tài)數(shù)據(jù)的高效檢索，基于ElasticSearch實現(xiàn)非RowKey查詢?nèi)鐖D2所示。

當(dāng)要對氣象列族N1這列建立索引時，只需要建立氣象列族:N1各列值到其對應(yīng)行鍵的映射關(guān)系，如N11→RowKey1等，這樣就完成了對氣象列族N1列值的二級索引的構(gòu)建，當(dāng)要查詢符合氣象列族N1=N11對應(yīng)的氣象列族N2的列值時(即根據(jù)N1=N11來查詢N2的值,圖2綠色部分)其查詢步驟如下：①根據(jù)N1=N11到索引數(shù)據(jù)中查找其對應(yīng)的RowKey，查詢得到其對應(yīng)的RowKey=RowKey。②得到RowKey1后即能根據(jù)RowKey1來查詢N2的值。

2.5 圖像合并索引算法

由于生態(tài)站內(nèi)存儲的圖像大多都是小圖像，會出現(xiàn)NameNode瓶頸問題和檢索性能低等問題?，F(xiàn)有的算法一般都是為了解決內(nèi)存占用較高等問題，將小文件合并成大文件，再存儲成大文件的方式，但沒有考慮到圖像之間的問題，比如取某一生態(tài)特征數(shù)據(jù)圖像，可能分散在不同的大文件里面，存儲效率低下。

因此本文提出一種基于數(shù)據(jù)站點及時間關(guān)聯(lián)性的合并存儲方法RBSTC。首先，創(chuàng)建臨時隊列，存入初始圖像。然后，判斷待存儲的圖像是否來自相同站點并且同一天，若是，則將存儲的圖像合并到臨時隊列中，否則新建一個新的隊列，待存儲圖像作為新建隊列中的初始圖像，重復(fù)以上操作，直到所有待上傳圖像都傳至HDFS上。圖像合并索引算法具體操作偽代碼為

輸入：生態(tài)站實時傳入圖像數(shù)據(jù)

輸出：HDFS

令 RealtimeData=實時數(shù)據(jù)流集合

BlockCapacity為每個文件塊的容量

QueueCapacity為每個隊列塊的容量

while RealtimeData

判斷RealtimeData類型

if BlockCapacity到達(dá)閾值

構(gòu)建索引信息并寫入HDFS；

else

if ReatimeData類型存在

合并文件到臨時隊列塊

else 創(chuàng)建新的臨時隊列

if QueueCapacity到達(dá)閾值

構(gòu)建索引信息并寫入HDFS；

清除隊列塊信息

end while

2.6 GIS數(shù)據(jù)存儲設(shè)計

GeoTools是用Java語言開發(fā)的GIS工具包，基于標(biāo)準(zhǔn)的GIS接口，支持多種GIS數(shù)據(jù)源的訪問，GIS數(shù)據(jù)一般由坐標(biāo)數(shù)據(jù)、屬性數(shù)據(jù)、拓?fù)潢P(guān)系數(shù)據(jù)組成，根據(jù)矢量數(shù)據(jù)的特點，設(shè)計適合HBase的矢量數(shù)據(jù)存儲模型,GIS數(shù)據(jù)RowKey設(shè)計中RowKey為站點+時間戳，分為3個列族，空間信息列族、屬性信息列族、拓?fù)湫畔⒘凶濉＞唧w生態(tài)站GIS數(shù)據(jù)存儲算法偽代碼為

輸入：生態(tài)站實時傳入GIS數(shù)據(jù)

輸出：HBase數(shù)據(jù)庫

令 RealtimeData=實時數(shù)據(jù)流集合

while RealtimeData≠?

GeoTools開始解析GIS數(shù)據(jù)

創(chuàng)建HBase鏈接

if創(chuàng)建表成功

創(chuàng)建列族

for(1 to 列族.length){

添加列族屬性

}

else表創(chuàng)建失敗

end while

3 森林生態(tài)站系統(tǒng)性能測試

3.1 集群部署

為了評估本文技術(shù)方案的性能，基于不同數(shù)據(jù)量級的數(shù)據(jù)對存儲模型、預(yù)分區(qū)、RowKey設(shè)計、二級檢索方案、圖像合并策略等進(jìn)行性能測試，本文配置了服務(wù)器相關(guān)環(huán)境搭建了Hadoop集群、HBase集群、Zookeeper集群；為了進(jìn)行二級索引對比實驗，還搭建了ElasticSearch集群、Solr集群、Phoenix集群，服務(wù)器配置如表2所示。

表2 服務(wù)器配置

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

3.2.1ElasticSearch索引分片放置策略驗證

通過校驗集群節(jié)點性能因素以及索引數(shù)據(jù)量，來構(gòu)建索引分片數(shù)量計算模型得到合理的索引分片數(shù)量，其中索引預(yù)估生態(tài)數(shù)據(jù)量是分片結(jié)果的關(guān)鍵因素。為了驗證索引放置策略模型優(yōu)化的提升度，與文獻(xiàn)[37]改變原有ES評分機(jī)制提升ES性能的方法進(jìn)行對比。首先對比不同生態(tài)數(shù)據(jù)量下，分片優(yōu)化模型和ElasticSearch原生默認(rèn)的分片數(shù)據(jù)數(shù)量結(jié)果，如圖3所示。

從圖3可知，隨著數(shù)據(jù)量的增大，分片模型得到的分片數(shù)量也隨之線性增長，但不僅僅是單純的線性增長，還考慮了索引的拓展性，當(dāng)數(shù)據(jù)量小于60 GB，可以減小資源浪費，大于60 GB時，可以避免單片數(shù)據(jù)量過大，造成性能下降。

索引查詢是衡量索引性能的重要指標(biāo)，因此本文也做了原生默認(rèn)和分片策略模型結(jié)果生成索引的查詢，以此驗證分片模型對性能的影響，索引查詢性能對比如圖4所示。

從圖4中可看出，相同的索引數(shù)據(jù)量，優(yōu)化后模型生成的索引查詢普遍比原生默認(rèn)查詢低20 ms，并且隨著索引數(shù)據(jù)量的增大，兩種索引的查詢延遲應(yīng)該更大。但通過改變ES評分機(jī)制來提高性能的方法并沒有起到太好的效果，因為生態(tài)數(shù)據(jù)本身就比較繁雜，檢索評分不易判斷并且本身檢索計算基于內(nèi)存，所以提升效果并不明顯。因此，優(yōu)化后的分片數(shù)量模型，對生態(tài)站的索引查詢性能有提升。

3.2.2數(shù)據(jù)插入及檢索方案性能驗證

3.2.2.1插入性能對比

實驗通過4臺客戶端同時向HBase表插入數(shù)據(jù)，并在4臺客戶端上統(tǒng)計每107條數(shù)據(jù)的Put時間，重復(fù)了10次實驗后，取平均值，分別測試HBase原生、基于ElasticSearch的索引、Solr的索引和Phoenix的索引在相同條件下的Put時間，其結(jié)果如圖5所示。

由圖5可以看出，Put執(zhí)行效率最高的是HBase原生方式，這是因為在Put操作時，無需再分配資源進(jìn)行索引的構(gòu)建，而其它方式都需要額外構(gòu)建二級索引。可以看出在同樣增加107條數(shù)據(jù)時，插入時間越來越長，這是因為隨著數(shù)據(jù)量的增加，索引數(shù)據(jù)也越來越多，在進(jìn)行索引插入時困難。同時，因為Phoenix底層需要在協(xié)處理器構(gòu)建合適的存儲索引結(jié)構(gòu)，額外消耗計算資源。而基于ElasticSearch和Solr只需要在自己的集群中構(gòu)建索引，不需要程序額外的計算資源，因此Phoenix二級索引對插入性能損耗最大。

3.2.2.2不同二級索引的單條件查詢性能對比分析

檢索數(shù)據(jù)仍采用上述數(shù)據(jù)，其檢索性能對比如圖6所示。

由圖6可看出，原生HBase響應(yīng)速度降低較為明顯，當(dāng)數(shù)據(jù)量達(dá)到1×108時，響應(yīng)時間大于5 s，從理論層面分析，HBase是一個面向列的數(shù)據(jù)庫，它的底層是建立一個基于RowKey的B+樹索引，可以很高效地對數(shù)據(jù)進(jìn)行檢索，但對應(yīng)非行鍵的索引，系統(tǒng)將進(jìn)行全表掃描，整體數(shù)據(jù)檢索效率低下。針對二級索引的對比，Solr和ElasticSearch底層都是基于lucence，但ElasticSearch的框架設(shè)計進(jìn)行了進(jìn)一步優(yōu)化，數(shù)據(jù)檢索效率也具有更好的性能，所以當(dāng)數(shù)據(jù)量達(dá)到1×108條，ElasticSearch的效率是Solr的1.72倍。Phoenix的檢索效率跟ElasticSearch速度接近，但Phoenix的耦合性比較強(qiáng)，因此最終選擇ElasticSearch作為二級索引。

3.2.2.3多條件查詢、性能分析及其優(yōu)化

檢索數(shù)據(jù)仍采用上述數(shù)據(jù)，檢索條件數(shù)分別為2、5、10，取10次實驗后的平均值，其平均檢索性能對比如圖7所示。

把數(shù)據(jù)橫向?qū)Ρ?，發(fā)現(xiàn)檢索時間與檢索條件成負(fù)相關(guān)，檢索條件越多檢索時間越短，比如在數(shù)據(jù)為5×107條時，檢索條件數(shù)取2、5、10，HBase的檢索時間為4.721、4.328、4.295 s，HBase索引優(yōu)化的時間為0.925、0.884、0.888 s，這是由于在HBase中檢索條件增多，符合條件的數(shù)據(jù)檢索量減少，就相當(dāng)于減少用戶并發(fā)量，因此，檢索時間也一直降低。

3.2.3非結(jié)構(gòu)化數(shù)據(jù)存儲方案性能驗證

數(shù)據(jù)存儲驗證部分，針對圖像的合并策略性能驗證，即驗證HDFS默認(rèn)的SequenceFile合并和本實驗使用RBSTC算法對比測試。

采用生態(tài)站系統(tǒng)中圖像共1×107幅，占用存儲空間100～500 KB，將圖像采用HDFS默認(rèn)的SequenceFile合并和RBSTC合并索引分別測試，做10次讀寫實驗，取10次讀寫的平均值作為最終時間消耗，其平均讀寫驗證對比如圖8所示。

由圖8可看出，隨著圖像數(shù)據(jù)規(guī)模不斷增大，基于數(shù)據(jù)站點及時間關(guān)聯(lián)性的合并方式優(yōu)勢越來越明顯，當(dāng)圖像數(shù)量為1×107幅時，基于數(shù)據(jù)站點及時間關(guān)聯(lián)性的小文件合并是原生讀寫的1.79倍，是SequenceFile的1.15倍，因此基于數(shù)據(jù)站點及時間關(guān)聯(lián)性的合并策略更適合生態(tài)站海量圖像的存儲場景。

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

為了驗證系統(tǒng)穩(wěn)定性，采用Postman工具對大數(shù)據(jù)平臺進(jìn)行壓力測試，大數(shù)據(jù)平臺如圖9所示。選取每秒查詢率(QPS)、吞吐量(TPS)和響應(yīng)時間(RT)作為主要參數(shù)，并發(fā)量為1×104次，測試時間為3 min，取10次實驗的平均值，并發(fā)測試如表3所示。

表3 并發(fā)壓力測試結(jié)果

通過測試結(jié)果可以發(fā)現(xiàn)，在1×104次并發(fā)用戶的情況下，優(yōu)化后的每秒查詢數(shù)是原來的1.88倍，每秒吞吐量是優(yōu)化前的1.74倍，系統(tǒng)響應(yīng)時間比優(yōu)化前降低69.5%，說明該系統(tǒng)在高并發(fā)的條件下同樣可以穩(wěn)定運(yùn)行。

4 結(jié)論

(1)面對海量生態(tài)數(shù)據(jù)的存儲和快速檢索的需求，傳統(tǒng)模型架構(gòu)無法保證生態(tài)數(shù)據(jù)平臺的數(shù)據(jù)處理性能，采用分布式大數(shù)據(jù)技術(shù)，搭建了生態(tài)大數(shù)據(jù)平臺，通過對RowKey的科學(xué)設(shè)計，采用Hadoop和HBase作為數(shù)據(jù)存儲層，實現(xiàn)了海量數(shù)據(jù)的存儲；提出并設(shè)計預(yù)分區(qū)算法保證數(shù)據(jù)分布一致，避免了熱點數(shù)據(jù)傾斜問題。

(2)提出基于索引數(shù)據(jù)和服務(wù)器性能評估的索引分片放置策略，并通過ElasticSearch優(yōu)化了多條件檢索二級索引失效的問題，優(yōu)化后的分片策略比默認(rèn)分片策略和基于改變ElasticSearch評分的策略平均查詢時間減少20 ms；結(jié)構(gòu)化數(shù)據(jù)規(guī)模為1×108條時，系統(tǒng)的檢索時間為1.045 s，比原生HBase檢索速度提升3.99倍；在1×104次并發(fā)用戶的情況下，優(yōu)化后的每秒查詢數(shù)是原來的1.88倍，每秒吞吐量是優(yōu)化前的1.74倍，系統(tǒng)響應(yīng)時間比優(yōu)化前降低69.5%。

(3)針對海量圖像數(shù)據(jù)的存儲需求，提出一種基于數(shù)據(jù)站點及時間關(guān)聯(lián)性的關(guān)聯(lián)合并存儲方法，在非結(jié)構(gòu)化數(shù)據(jù)為1×107條時，采用數(shù)據(jù)站點及時間關(guān)聯(lián)性的打包小圖像策略是基于SequenceFile合并效率的1.15倍，是原生HBase的1.79倍。從實驗結(jié)果可以看到，本文所提出的方法可以有效地滿足生態(tài)數(shù)據(jù)存儲和檢索的實時需求，訪問效率取得良好效果，能夠根據(jù)需要高效地從各個維度對海量生態(tài)數(shù)據(jù)進(jìn)行查詢和統(tǒng)計分析，為應(yīng)用深度學(xué)習(xí)等人工智能技術(shù)對生態(tài)數(shù)據(jù)進(jìn)行多維度特征抽取提供足夠多的數(shù)據(jù)資源，進(jìn)而為后期開展生態(tài)數(shù)據(jù)智能決策分析提供了必要的數(shù)據(jù)支撐和處理能力。