摘要：HBase一直是大數(shù)據(jù)領(lǐng)域常用的非關(guān)系型數(shù)據(jù)庫(kù)。隨著HBase數(shù)據(jù)庫(kù)中存入的數(shù)據(jù)量不斷增長(zhǎng)，對(duì)數(shù)據(jù)庫(kù)里的數(shù)據(jù)進(jìn)行查詢變得越來(lái)越困難，需要有一個(gè)合理的二級(jí)索引的方案提高查詢的效率。Elasticsearch是一個(gè)高性能的搜索服務(wù)器，利用Elasticsearch的技術(shù)，存儲(chǔ)并搜索二級(jí)索引可以極大地提高HBase查詢效率。

關(guān)鍵詞：大數(shù)據(jù);HBase;二級(jí)索引;協(xié)處理器;Elasticsearch

中圖分類號(hào)：TP392

文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2020）04-0001-02

收稿日期：2019-11-18

作者簡(jiǎn)介：李傳冰（1993—），男，湖北武漢人，碩士研究生，主要研究方向?yàn)榇髷?shù)據(jù)。

A Secondary Index Scheme of Big Data in HBase Based on Elasticsearch

LI Chuan-bing

（The Third Research Institute of The Ministry of Public Security，Shanghai 200031，China）

Abstract：HBase has always been used as a NoSQL database in the field of big data.With the increasing amount of data stored in the HBase database，it becomes more and more difficult to query the data in the database.Therefore，a reasonable secondary index scheme is needed to improve the efficiency of the query.Elasticsearch is a high-performance search server，and the efficiency of the query in the HBase database can be improved greatly by storing and searching secondary indexes with Elasticsearch.

Key words：big data;HBase;secondary index;coprocessor;Elasticsearch

1?概述

隨著大數(shù)據(jù)時(shí)代的來(lái)臨，人們所存儲(chǔ)的數(shù)據(jù)量呈爆炸性增長(zhǎng)。數(shù)據(jù)能被用起來(lái)做各種數(shù)據(jù)分析才能發(fā)揮數(shù)據(jù)的價(jià)值。而對(duì)數(shù)據(jù)的利用第一步就是查詢，查詢效率的高低直接影響大數(shù)據(jù)分析的快慢。因此，很多公司投入相當(dāng)多的精力去尋找可以提升搜索速度的方案。HBase作為一個(gè)可以存儲(chǔ)海量數(shù)據(jù)的數(shù)據(jù)庫(kù)，存儲(chǔ)性能十分優(yōu)異，但是查詢范圍十分有限，在缺少主鍵的情況下，條件查詢效率也比較低下[1]，僅僅依靠數(shù)據(jù)庫(kù)的搜索功能無(wú)法滿足商業(yè)化的業(yè)務(wù)需求。于是，有很多新穎的搜索方案被提出，其中比較實(shí)用的方案是釆取存儲(chǔ)并查詢二級(jí)索引的方案，加上基于Lucene的分布式搜索引擎Elasticsearch的配合使用[2]，整套方案更加可靠、高效。

2?基于Elasticsearch—級(jí)索引方案

為了方便測(cè)試，構(gòu)建了一個(gè)完整的二級(jí)索引存儲(chǔ)系統(tǒng)。首先由Kafka的生產(chǎn)者生產(chǎn)批量實(shí)驗(yàn)性數(shù)據(jù)，數(shù)據(jù)總量1000萬(wàn)條;然后由Kafka的消費(fèi)者將數(shù)據(jù)寫入HBase，在數(shù)據(jù)錄入的同時(shí)，啟動(dòng)HBase的協(xié)處理器Coprocessor，通過(guò)觸發(fā)Coprocessor的鉤子函數(shù)，同步二級(jí)索引至Elasticsearch。

整個(gè)系統(tǒng)搭建在三臺(tái)服務(wù)器上，三臺(tái)服務(wù)器均是Think-Server RD650，操作系統(tǒng)centos6.7，處理器Intel（R）Xeon（R）E5-2630v3，內(nèi)存32GB。為了便于區(qū)分，給三臺(tái)服務(wù)器分別命名為nodel10、nodel11、nodel12。因?yàn)镠Base是部署在HDFS之上的，所以先在nodel10、node111、node112上部署了hadoop，node110為NameNode，node110、node111、node112為DataNodeo通過(guò)不斷的選擇嘗試，最后選擇了安裝hadoop-2.7.7，hadoop-2.7.7版本比較穩(wěn)定、成熟。在安裝HBase的時(shí)候，在與hadoop-2.7.7匹配的版本中，選擇了比較新的HBase-2.0.5。

HBase的協(xié)處理器機(jī)制有兩種：一種是Observer，另一種是Endpoint[3]。Observer類似于一個(gè)觸發(fā)器，在實(shí)際使用中，Observer機(jī)制比Endpoint更加靈活，Observer機(jī)制可以給特定的表綁定，不需要該機(jī)制的表則可以不綁定。考慮到實(shí)際的應(yīng)用場(chǎng)景，采取的是Observer機(jī)制。在Kafka的消費(fèi)者向HBase傳入數(shù)據(jù)的過(guò)程中，釆取了以隊(duì)列的方式批量導(dǎo)入，每一萬(wàn)條數(shù)據(jù)為一個(gè)批次，這樣比一條一*條數(shù)據(jù)put進(jìn)HBase，速度要快上很多。在實(shí)際的數(shù)據(jù)導(dǎo)入過(guò)程中，數(shù)據(jù)量不可能恰好是一萬(wàn)的倍數(shù)，多出來(lái)的余數(shù)如果不足一萬(wàn)，會(huì)導(dǎo)致數(shù)據(jù)遺漏，為了彌補(bǔ)這一缺漏，還給HBase導(dǎo)入數(shù)據(jù)增加了一個(gè)時(shí)間機(jī)制，每隔5秒鐘，會(huì)將一個(gè)批次里剩下的數(shù)據(jù)均導(dǎo)入HBase數(shù)據(jù)庫(kù)。

Elasticsearch的連接client以前是Transportclient，根據(jù)Elasticsearch官方的建議，以后會(huì)一直使用RestHighLevelClient、RestLowLevelClient[4]，并停止對(duì)Transportclient的更新。RestHighLevelClient封裝的更好，相比于RestLowLevelClient更易于配置參數(shù)，因此采用RestHighLevelClient。Elasticsearch也選取了比較新的版本7.2.0。

在給Elasticsearch傳輸數(shù)據(jù)的過(guò)程中，配置了bulkProces-sor，設(shè)置了批量傳輸?shù)臋C(jī)制，這樣可以提高傳輸效率。bulkPro-cessor也是兩種傳輸機(jī)制并行，一個(gè)是以隊(duì)列的方式批量導(dǎo)入，另一個(gè)是時(shí)間機(jī)制。這兩種機(jī)制在bulkProcssor中都可以很方便的配置參數(shù)，經(jīng)過(guò)各種調(diào)試，最后選擇隊(duì)列容量同樣為一萬(wàn)條數(shù)據(jù)，時(shí)間機(jī)制為每隔5秒鐘回滾一次，將隊(duì)列中剩余的數(shù)據(jù)一起導(dǎo)入。

3?Elasticsearch二級(jí)索引性能測(cè)試

3.1?數(shù)據(jù)的寫入性能

Kafka的生產(chǎn)者生產(chǎn)了批量實(shí)驗(yàn)性數(shù)據(jù)，每一批數(shù)據(jù)都有一千萬(wàn)條。每一條數(shù)據(jù)包括了一個(gè)假想用戶的各項(xiàng)信息，一共有11個(gè)字段，字段名分別為用戶名、地址、創(chuàng)建時(shí)間、電子郵件、序號(hào)、主機(jī)IP、登錄時(shí)間、手機(jī)號(hào)碼、密碼、真實(shí)姓名、記錄。每一個(gè)字段下的參數(shù)都是12位隨機(jī)英文字符。數(shù)據(jù)寫入測(cè)試進(jìn)行了5次，每次測(cè)試時(shí)每條數(shù)據(jù)包含的字段數(shù)不同，依此是1、4、6、8、11個(gè)，用于比較在不同字段數(shù)的情況下整個(gè)系統(tǒng)的數(shù)據(jù)寫入性能。對(duì)整個(gè)系統(tǒng)的數(shù)據(jù)寫入性能測(cè)試，是從數(shù)據(jù)寫入HBase開(kāi)始，到二級(jí)索引全部存入Elasticsearch結(jié)束。

測(cè)試結(jié)果如表1所示：

如表1中展示的結(jié)果可以看出，隨著字段數(shù)的增加，每秒寫入條數(shù)開(kāi)始降低，雖然每一次測(cè)試數(shù)據(jù)的條數(shù)都是一千萬(wàn)，但是字段數(shù)的增加等于HBase存入的列數(shù)增加，相對(duì)于一個(gè)字段來(lái)說(shuō)寫入的數(shù)據(jù)量更大，按每秒寫入多少條數(shù)據(jù)并不能完全顯示寫入性能，按每秒寫入的字節(jié)數(shù)可以更可靠的顯示寫入性能。這點(diǎn)可以從表1中最后一列得到驗(yàn)證，寫入速率基本維持在2～3MB/秒之間。

基于Elasticsearch的二級(jí)索引存儲(chǔ)系統(tǒng)，寫入數(shù)據(jù)速率比較穩(wěn)定，在存入數(shù)據(jù)的字段數(shù)為1個(gè)的情況下，按照測(cè)試的結(jié)果，一天的數(shù)據(jù)寫入量可以達(dá)到20億條左右。

3.2?數(shù)據(jù)的檢索性能

數(shù)據(jù)的檢索，先依靠Elasticsearch搜索關(guān)鍵詞查詢到id，Elasticsearch中存入的每條數(shù)據(jù)的id即是HBase中所對(duì)應(yīng)數(shù)據(jù)的rowKey，然后根據(jù)這個(gè)rowKey在HBase中查詢?cè)紨?shù)據(jù)。HBase搜索關(guān)鍵詞的能力比較差，但是在已知rowKey的情況下，查詢效率能夠得到顯著提高。

測(cè)試時(shí)，進(jìn)行了兩種檢索性能測(cè)試，一種是精確查詢，另一種是模糊查詢。均進(jìn)行了100次重復(fù)實(shí)驗(yàn)，Elasticsearch查詢時(shí)間是Elasticsearch根據(jù)關(guān)鍵詞檢索id的時(shí)間，HBase檢索時(shí)間是HBase根據(jù)id（rowKey）查詢?cè)紨?shù)據(jù)的時(shí)間，每次查詢的總時(shí)間是這兩個(gè)查詢時(shí)間之和，平均查詢時(shí)間如下表2所示。

Elasticsearch模糊查詢時(shí)間比精確查詢時(shí)間多花了一點(diǎn)，但基本上檢索時(shí)間都在毫秒量級(jí)，Elasticsearch查詢出rowKey后，HBase再根據(jù)rowKey查詢?cè)紨?shù)據(jù)所消耗的時(shí)間也很短，同樣是毫秒量級(jí)，二者相加，總的查詢時(shí)間不到1秒，可見(jiàn)整個(gè)系統(tǒng)的數(shù)據(jù)查詢性能足夠滿足快速查詢的需求。

4?結(jié)論

基于Elasticsearch的二級(jí)索引系統(tǒng)，極大地提咼了HBase的檢索效率。數(shù)據(jù)寫入性能可以達(dá)到2～3MB/s，總的檢索性能可以達(dá)到毫秒量級(jí)。整套系統(tǒng)既可以滿足海量數(shù)據(jù)的寫入需求，也可以滿足快速檢索的需求。

參考文獻(xiàn)：

[1] 夏超俊.基于協(xié)處理器機(jī)制的HBase檢索速度改進(jìn)研究[D].湖南大學(xué)，2015.

[2] 梁文楷.基于Elasticsearch全文檢索系統(tǒng)的實(shí)現(xiàn)[J].電腦編程技巧與維護(hù)，2019（6）：116-119.

[3] 朱松杰，婁淵勝，葉楓，李凌，陳勇.基于協(xié)處理器的HBase內(nèi)存索引機(jī)制的研究[J/OL].計(jì)算機(jī)工程與應(yīng)用，1-11[2019-11-15].

[4] 李宣廷，姜楠，狄查美玲，王淖瑩，孟德文.基于ElasticSearch的網(wǎng)絡(luò)輿情搜索平臺(tái)設(shè)計(jì)[J].大連民族大學(xué)學(xué)報(bào)，2019，21（5）：449-452.

[通聯(lián)編輯：王力]