郭雪峰

摘要：針對HBase不提供二級索引、自帶Coprocessor（協(xié)作器）不穩(wěn)定及海量數(shù)據(jù)檢索速度較慢等問題，設計了一種新的基于Elasticsearch的HBase二級索引方案ELHBase（ElasticsearchIndexing HBase）。該方案借助Flume、Kafka、HBase及Elastic-search搭建了一套數(shù)據(jù)采集、高速解析和錄入大數(shù)據(jù)處理框架，使用Flume自定義Sink采集數(shù)據(jù)同時生成相應ID存入到Kafka，通過解析技術分別把數(shù)據(jù)存儲到HBase，相應ID作為索引存儲到ElasticSearch。該方案在不利用Coprocessor的基礎上增加了直接查詢ElasticSearch的接口，利用ElasticSearch提供的高效、靈活、多樣的檢索功能實現(xiàn)對HBase海量數(shù)據(jù)的快速檢索，協(xié)同解決了HBase數(shù)據(jù)索引性能不高、協(xié)作器不穩(wěn)定、ElasticSearch不適合大量數(shù)據(jù)存儲等問題。最后，分別與SI-HBase、hindex進行了二級索引性能對比實驗，證明了該方案在寫入性能上較SIHBase更快、更穩(wěn)定，查詢速度上要遠快于hindex。

關鍵詞：海量數(shù)據(jù);二級索引;ELHBase;自定義Sink;快速檢索

中圖分類號：TP31 文獻標識碼：A

文章編號：1009-3044（2020）01-0005-03

隨著社會的發(fā)展和科技的進步，網(wǎng)絡已成為人們分享和獲取信息的通用工具，伴隨著網(wǎng)絡流量數(shù)據(jù)的不斷交互，各類應用系統(tǒng)產(chǎn)生的日志數(shù)據(jù)越來越多，大數(shù)據(jù)時代到來。大數(shù)據(jù)被百度百科定義為：大數(shù)據(jù)是指無法用傳統(tǒng)軟件工具進行捕捉、處理及管理的海量數(shù)據(jù)集合，其含義是需要新處理模式才能具有更強的決策力、洞察發(fā)現(xiàn)力和流程優(yōu)化能力的海量、高增長率和多樣化的信息資產(chǎn)。而如何安全保證海量日志數(shù)據(jù)能被快速存儲、查詢及可擴展性是當前研究的熱點和難點。

隨互聯(lián)通信技術不斷改良和升級，大數(shù)據(jù)技術可以大致概括為四部分內(nèi)容：數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)存儲和數(shù)據(jù)查詢，每部分內(nèi)容包括不同的組件去實現(xiàn)各自的功能。傳統(tǒng)的關系數(shù)據(jù)庫是采用二維表格數(shù)據(jù)模型不能夠有效地處理多維數(shù)據(jù)，不能有效處理互聯(lián)網(wǎng)應用中半結構化和非結構化的海量數(shù)據(jù)，且支撐容量非常有限，在其達到一定規(guī)模時，很容易發(fā)生死鎖等并發(fā)問題，導致其讀寫性能下降嚴重。因此，HBase數(shù)據(jù)庫在大數(shù)據(jù)領域的應用應運而生。

Hbase是一個面向列存儲的分布式存儲系統(tǒng)，不同于傳統(tǒng)數(shù)據(jù)庫，它的優(yōu)點在于可以實現(xiàn)高性能的并發(fā)讀寫操作，同時Hbase還會自動對數(shù)據(jù)進行透明的切分，這樣就使得存儲本身具有了水平伸縮性。同樣HBase也存在缺點嗍，它不能支持條件查詢，只支持按照rowkey來查詢，暫時不能支持Master server的故障切換，當Master宕機后，整個存儲系統(tǒng)就會掛掉。

為解決快速檢索的功能，張榆等為了解決在海量空間文本中快速檢索的問題，在HBase的基礎上設計了一種空間文本索引方案SK-HBase，該方案自建索引以達到快速檢索HBase中的空間文本數(shù)據(jù)。Cheng Pengsen等針對存儲空間不足問題，在HBase的基礎上構建倒排索引表，并在此基礎上進一步建立壓縮和解壓算法。卓海藝針對HBase查詢速度慢問題，利用HBase自帶的協(xié)作器開發(fā)出索引自動生成組件及更新組件，同時參考1THBase方案構造和維護二級索引表。華為公司設計了二級索引方案hin-dexN，該方案實現(xiàn)了針對不同的數(shù)據(jù)表使用HBase自帶協(xié)作器建立索引，它提供了一種自動生成索引的方法，當進行數(shù)據(jù)操作時會自動實現(xiàn)索引的維護，具有便捷化的索引管理功能。王文賢等針對華為hindex方案難以滿足海量數(shù)據(jù)高速檢索問題，設計了基于Solr的HBase二級索引方案SIHBase（SolrIndexing HBase）。該方法使用HBase的協(xié)作器實現(xiàn)在Solr中自動為HBase建立和維護二級索引，提高了數(shù)據(jù)檢索速度，但co-processor不穩(wěn)定問題仍在。HBase官方和開源社區(qū)對其二級索引問題，仍在不斷地探索中。

針對HBase不提供二級索引、自帶Coprocessor（協(xié)作器）不穩(wěn)定及海量數(shù)據(jù)檢索速度較慢等問題，文章設計了基于Elastic-search的HBase二級索引方案ELHBase（Elasticsearch IndexingHBasel。該方案利用Flume、Kafka、HBase及Elasticsearch搭建了一套數(shù)據(jù)采集、高速解析和錄入大數(shù)據(jù)處理框架，該方案在不利用Coprocessor的基礎上增加了直接查詢ElasticSearch的接口，利用ElasticSearch提供的高效、靈活、多樣的檢索功能實現(xiàn)對HBase海量數(shù)據(jù)的快速檢索，協(xié)同解決了HBase數(shù)據(jù)索引性能不高、Coprocessor不穩(wěn)定、ElasticSearch不適合大量數(shù)據(jù)存儲等問題。

1二級索引方案設計

首先，對HBase二級索引方案的基本原理進行簡單介紹，然后，分析了華為針對該問題提出的hindex二級索引方案與針對檢索速度問題提出的基于Solr的HBase二級索引方案SIH-Base，前者雖然解決了HBase在檢索非主鍵字段時遇到的問題，但難以滿足對檢索的快速響應，后者雖然提升了檢索速度，但協(xié)作器存在不穩(wěn)定問題。最后，本文為解決以上問題提出了基于Elasticsearch的HBase二級索引方案ELHBase（Elastic-search Indexing HBase）。

1.1設計原理

由于HBase里面只有rowkey作為一級索引，因此如果要對數(shù)據(jù)庫里的非mwkey字段進行數(shù)據(jù)檢索和查詢，往往要通過MapReduce/Spark等分布式計算框架進行，硬件資源消耗和時間延遲都會比較高。

為了HBase的數(shù)據(jù)查詢更高效、適應更多的場景，諸如使用非rowkey字段檢索也能做到秒級響應，或者支持各個字段進行模糊查詢和多字段組合查詢等，因此需要在HBase上面構建二級索引，以滿足現(xiàn)實中更復雜多變的業(yè)務需求。二級索引是對于目標記錄的某個或某些列而設立的“鍵一值”數(shù)據(jù)結構，以列的值為鍵，以記錄的rowkey為值，假如按照這些列進行查詢時，就可以檢索出對應的“鍵一值”進而達到快速檢索記錄的目的。

1.2 hindex方案介紹

hindex架構在ClientExt中設定索引細節(jié)，在Balancer中收集信息，在Coprocessor中管理二級索引數(shù)據(jù)。hindex二級索引方案的框架如圖1所示。

在創(chuàng)建表的時候，在同一個region server上創(chuàng)建索引表，且一一對應。在主表中插入某條數(shù)據(jù)后，用Coprocessor將索引列寫到索引表中去，當一個查詢到來的時候，通過Coprocessor鉤子，先從索引表中查詢范圍rowkey，然后再從主表相關rowkey中掃描獲取最終數(shù)據(jù)。

1.3SIHBase方案介紹

本方案從HBase的客戶端考慮，加入了具有高速檢索能力的Solr，按照數(shù)據(jù)與索引分開存儲的思想，實現(xiàn)海量數(shù)據(jù)的高速檢索功能。其整體架構如下圖2所示。

Client Ext客戶端主要針對Solr中的索引查詢功能進行了擴展。當表中數(shù)據(jù)出現(xiàn)增、刪、改的情況下，通過Solr IndexingCopmcessor可以實時更新Solr中的索引，并且當出現(xiàn)宕機和修復數(shù)據(jù)時能使得Solr索引數(shù)據(jù)和HBase表中數(shù)據(jù)保持一致。Solr主要存放和管理索引數(shù)據(jù)，利用Solr可以達到高效檢索的目的。

但當實時建立索引時，Solr會產(chǎn)生io阻塞，查詢性能較差，伴隨著數(shù)據(jù)量的不斷增加，Solr的搜索效率會變得更低，而Elasticsearch卻無明顯變化，完全支持Apache Lucene的接近實時的搜索。

1.4基于Elastiesearch的HBase二級索引方案ELHBase

本文不同于以往的思路，利用Flume、Kafka、HBase及Elas-ticsearch搭建了一套數(shù)據(jù)采集、高速解析和錄入大數(shù)據(jù)處理框架，其整體架構如圖3所示。

本方案利用Flume采集數(shù)據(jù)，通過自定義sink的方式，在獲取消息的同時生成相應ID一塊存入到Kafka的Topic中，其中ID部分是由英文字母和數(shù)字隨機生成，共有31個字符。然后通過自定義sink解析Topic中的數(shù)據(jù)分別把消息存儲到HBase，相應ID作為索引（rowkey）存儲到ElasticSearch，保證數(shù)據(jù)與索引的一致性。ElasticSearch索引速度快，擴展方便，性能優(yōu)異，但在功能上不適合作為數(shù)據(jù)庫使用，因此本方案ElasticSearch中只存放ID。用戶可以通過ElasticSearch進行多條件的復雜查詢，獲取到滿足條件的rowkey集合后，進而在HBase中以row-key快速查詢獲取數(shù)據(jù)。

該方案在不利用Coprocessor的基礎上增加了直接查詢ElasticSearch的接口，利用ElasticSearch提供的高效、靈活、多樣的檢索功能實現(xiàn)對HBase海量數(shù)據(jù)的快速檢索，協(xié)同解決了HBase數(shù)據(jù)索引性能不高、協(xié)作器不穩(wěn)定、ElasticSearch不適合大量數(shù)據(jù)存儲等問題。

2EIHBase二級索引性能分析

本章針對EIHBase方案的性能進行了對比分析，共使用三臺物理服務器進行測試，三臺服務器的操作系統(tǒng)為CentOS 6，7，CPU為Intel（R）Xeon（R）E5-2630 v3@2.4GHz（32核），內(nèi)存為32GB。

集群中節(jié)點信息為：一臺作為master節(jié)點，兩臺作為slave節(jié)點。軟件版本信息見下表1。

測試中使用的測試數(shù)據(jù)是利用shell腳本生成的由英文字母與阿拉伯數(shù)字組成的66位字符串，共計10億條記錄。本方案分別與二級索引方案hindex以及SIHBase方案進行數(shù)據(jù)寫入性能和數(shù)據(jù)檢索性能對比實驗。測試結果如下表2所示：

如上表2所示是三個二級索引方案的檢索性能對比實驗結果，由此可知，在海量數(shù)據(jù)查詢中，本文提出的EIHBase方案較華為提出的hindex方案在查詢速度方面具有明顯優(yōu)勢，在寫入性能上較SIHBase更快、更穩(wěn)定。因此，本方案能夠基本滿足對HBase快速檢索的需求。

3結束語

本文詳細分析了華為針對該問題提出的hindex二級索引方案與針對檢索速度問題提出的基于Solr的HBase二級索引方案SIHBase，但這些技術本身各有優(yōu)缺點，且目前對于HBase的二級索引和全文檢索問題的研究仍未明確統(tǒng)一，只能夠滿足部分場景需求。因此，針對上述問題提出一種新的基于Elastic-search的HBase二級索引方案ELHBase，并進行了性能分析，證明了該方案的可行性。