森林生態站大數據快速存儲與索引方法

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

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

0 引言

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

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

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

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

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

1 森林生態大數據平臺總體架構

從森林生態數據特征出發，提出基于Hadoop的森林生態大數據平臺，可用于分布在全國各地的生態站數據管理。平臺深度集成大數據、物聯網、人工智能等技術，為用戶提供森林生態數據的快速檢索、處理和可視化分析。其總體架構如圖1所示，主要包括應用層、服務層、存儲層。

存儲層是森林生態大數據模型中最重要的部分，其主要作用是用來持久化存儲。該層包括基于分布式的HDFS和面向列的HBase數據庫。HDFS存儲森林生態數據中的視頻、圖像等非結構化數據；HBase數據庫用來存儲森林生態中產生的結構化數據。

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

應用層主要是面向各類用戶對森林生態大數據平臺中的各種業務進行統一數據處理。用戶可以對森林生態數據進行查詢、分析、管理和數據下載等。

2 森林生態大數據平臺關鍵技術

2.1 業務流程設計

目前森林生態站點采集的數據主要分為圖像、視頻、GIS數據、文本數據的非結構化數據及結構化數據5大類，文本數據主要包括Excel文件和TXT文件等，業務處理模塊需要統一數據訪問接口對需要存儲的數據類型進行判斷，并針對不同的數據類型，采取不用的存儲策略，數據寫入業務算法的處理偽代碼：

輸入：生態站實時傳入數據

輸出：HDFS和HBase數據庫

令 RealtimeData=實時數據流集合

BlockCapacity為每個文件塊的容量

while RealtimeData≠?

if RealtimeData為圖像類型數據

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

if BlockCapacity到達閾值

構建索引信息并寫入HDFS；

if RealtimeData為視頻類型數據

if BlockCapacity > 128MB

視頻分塊；

構建索引信息并寫入HDFS；

if RealtimeData為GIS類型數據

GeoTools工具解析；

構建索引信息并寫入HDFS；

if RealtimeData為文本類型數據

if 為Excel類型

Excel解析器解析；

if 為TXT類型

TXT解析器解析；

?

構建索引寫入HBase

if RealtimeData為結構化數據

構建索引寫入HBase

end while

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

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

(1)

式中a——HDFS沒有數據時NameNode所占內存容量

b——每個數據塊在NameNode的內存消耗

B——HDFS數據塊容量

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

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

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

當寫入數據為GIS數據時，通過GeoTools工具進行解析，存入HBase數據庫。

當寫入數據為文本數據時，通過對應服務層解析，將文本數據轉成結構化數據后，存入HBase數據庫。

當寫入數據為結構化數據時，直接將數據存入HBase數據庫。

2.2 預分區設計算法

HBase在默認情況下創建數據表時，會創建一個沒有起始和終止的Region，數據會按照鍵值對的字典升序寫入該Region，如果HBase的Region到達閾值，就會頻繁觸發分裂(Split)操作，會造成熱點傾斜，取值范圍為0～60。假設擬劃分成k(k為整數)個分區，將0～60范圍內數據splitKey從1開始，按照HBase預分區算法初步進行預分區，算法偽代碼為：

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

輸出：splitKey

splitKey(n)=n60k;

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

ifM>1 ∥進行微調

if num(n)

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

return;

else

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

return;

最后根據預分區算法獲取splitKey，并創建預分區表，以避免熱點傾斜。

2.3 RowKey設計方案

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

表1 RowKey設計

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

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

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

其利用ElasticSearch提供主要索引設計的索引結構為

PUT create_index{

"settings":{

"number_of_shards"x, ∥根據算法修正

"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}

?

} }}

}

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

輸入：數據量D，磁盤使用率ratedisk，虛擬機堆內存容量J

輸出：索引分片配置

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

if ratedisk<85% && nodecurrent(shardNum)

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

∥1GB堆內存對應20shardNum

nodeList().add(nodecurrent)；

∥k1,k2,k3,k4為權重系數

if shardNum>|nodeList|2

shardNum=|nodeList|2;

return shardNum；

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

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

2.5 圖像合并索引算法

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

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

輸入：生態站實時傳入圖像數據

輸出：HDFS

令 RealtimeData=實時數據流集合

BlockCapacity為每個文件塊的容量

QueueCapacity為每個隊列塊的容量

while RealtimeData

判斷RealtimeData類型

if BlockCapacity到達閾值

構建索引信息并寫入HDFS；

else

if ReatimeData類型存在

合并文件到臨時隊列塊

else 創建新的臨時隊列

if QueueCapacity到達閾值

構建索引信息并寫入HDFS；

清除隊列塊信息

end while

2.6 GIS數據存儲設計

GeoTools是用Java語言開發的GIS工具包，基于標準的GIS接口，支持多種GIS數據源的訪問，GIS數據一般由坐標數據、屬性數據、拓撲關系數據組成，根據矢量數據的特點，設計適合HBase的矢量數據存儲模型,GIS數據RowKey設計中RowKey為站點+時間戳，分為3個列族，空間信息列族、屬性信息列族、拓撲信息列族。具體生態站GIS數據存儲算法偽代碼為

輸入：生態站實時傳入GIS數據

輸出：HBase數據庫

令 RealtimeData=實時數據流集合

while RealtimeData≠?

GeoTools開始解析GIS數據

創建HBase鏈接

if創建表成功

創建列族

for(1 to 列族.length){

添加列族屬性

}

else表創建失敗

end while

3 森林生態站系統性能測試

3.1 集群部署

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

表2 服務器配置

3.2 實驗結果與分析

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

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

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

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

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

3.2.2數據插入及檢索方案性能驗證

3.2.2.1插入性能對比

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

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

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

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

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

3.2.2.3多條件查詢、性能分析及其優化

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

把數據橫向對比，發現檢索時間與檢索條件成負相關，檢索條件越多檢索時間越短，比如在數據為5×107條時，檢索條件數取2、5、10，HBase的檢索時間為4.721、4.328、4.295 s，HBase索引優化的時間為0.925、0.884、0.888 s，這是由于在HBase中檢索條件增多，符合條件的數據檢索量減少，就相當于減少用戶并發量，因此，檢索時間也一直降低。

3.2.3非結構化數據存儲方案性能驗證

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

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

由圖8可看出，隨著圖像數據規模不斷增大，基于數據站點及時間關聯性的合并方式優勢越來越明顯，當圖像數量為1×107幅時，基于數據站點及時間關聯性的小文件合并是原生讀寫的1.79倍，是SequenceFile的1.15倍，因此基于數據站點及時間關聯性的合并策略更適合生態站海量圖像的存儲場景。

3.2.4系統壓力測試

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

表3 并發壓力測試結果

通過測試結果可以發現，在1×104次并發用戶的情況下，優化后的每秒查詢數是原來的1.88倍，每秒吞吐量是優化前的1.74倍，系統響應時間比優化前降低69.5%，說明該系統在高并發的條件下同樣可以穩定運行。

4 結論

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

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

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