黃靜，別要祥，謝宣

摘? 要：HBase（分布式存儲數(shù)據(jù)庫）是大數(shù)據(jù)存儲領(lǐng)域的熱點技術(shù)，為信息化快速發(fā)展帶來的存儲問題提供了有效的解決方案。針對HBase檢索低效以及企業(yè)對系統(tǒng)的低耦合、高擴展性需求，通過分析HBase檢索困難的原因，設(shè)計一個索引中間件。利用Lucene（全文檢索引擎工具）技術(shù)構(gòu)建二級索引，以統(tǒng)一接口的形式提供服務(wù)。經(jīng)過實驗驗證，索引中間件在保證寫入需求的情況下，有效地改善了查詢性能，在千萬級數(shù)據(jù)量下仍然達到毫秒級檢索，并且耦合性低，易于部署，可以快速整合到已有系統(tǒng)中，具有較強的泛用性。

關(guān)鍵詞：HBase;Lucene;中間件;索引

中圖分類號：TP311.1? ? ?文獻標識碼：A

Design and Implementation of a Distributed Storage Index Middleware

HUANG Jing， BIE Yaoxiang， XIE Xuan

（School of Information， Zhejiang Sci-Tech University， Hangzhou 310018， China）

syhj_sy@163.com; 1009214965@qq.com; 15951612952@163.com

Abstract： HBase （Distributed Storage Database）， a hot technology in the field of big data storage， provides an effective solution to the storage problems brought about by the rapid development of information technology. Aiming at the low efficiency of HBase retrieval and the enterprise's needs for system with low coupling and high scalability， this paper proposes to design an indexing middleware by analyzing reasons for the difficulty of HBase retrieval. Lucene （a full-text search engine tool） technology is used to build a secondary index to provide service in the form of a unified interface. The experimental verification shows that the proposed indexing middleware can effectively improve the query performance while ensuring the writing requirements. It can still reach the millisecond level of retrieval under data volume of tens of millions. Besides， it has low coupling， easy deployment， and can be quickly integrated into the existing system with strong versatility.

Keywords： HBase; Lucene; middleware; index

1? ?引言（Introduction）

在云時代的背景下，計算機需要管理的數(shù)據(jù)呈指數(shù)級增長[1]，龐大的數(shù)據(jù)規(guī)模給存儲和處理帶來了極大的挑戰(zhàn)。受單機存儲的性能瓶頸以及單點故障影響，分布式存儲應(yīng)運而生[2]。HBase是一個面向列的高性能分布式存儲系統(tǒng)[3]，其優(yōu)異的高并發(fā)讀寫性能受到眾多企業(yè)的青睞，甚至作為企業(yè)核心數(shù)據(jù)庫使用。但在大數(shù)據(jù)存儲情況下，HBase存在查詢慢的問題[4]，并且相關(guān)檢索優(yōu)化措施實現(xiàn)復(fù)雜，容錯性能低，與系統(tǒng)業(yè)務(wù)耦合緊密，不利于系統(tǒng)的擴展和升級。

本文從低耦合性與高擴展性出發(fā)，設(shè)計索引中間件CFH （Coordinator for HBase）。該中間件作為一個協(xié)調(diào)器，承接客戶端HBase操作請求的處理與轉(zhuǎn)發(fā)，通過Lucene技術(shù)構(gòu)建二級索引，在保證高效寫入與查詢的同時，達到業(yè)務(wù)低侵入性、易于快速擴展與部署的目的。

2 HBase檢索低效與優(yōu)化研究（Research on inefficiency and optimization of HBase retrieval）

HBase檢索低效的原因可以歸納為三種：

（1）HBase以鍵值對的方式存儲數(shù)據(jù)，僅提供B+樹構(gòu)造的一級索引（也稱為主鍵）。因此，基于主鍵的查詢具有很高的效率，對非主鍵的查詢效率很低。雖然，針對非主鍵字段查詢，HBase通過MapReduce（分布式計算）進行檢索，但這種方式的硬件資源消耗較高，時間損耗也不盡人意。

（2）海量的數(shù)據(jù)對檢索也會產(chǎn)生影響。大規(guī)模數(shù)據(jù)會建立更多的索引表，同時，非索引查詢會觸發(fā)全文掃描，對海量數(shù)據(jù)進行全文檢索，資源消耗非常巨大[5]。

（3）HBase在檢索時，需要將數(shù)據(jù)加載到內(nèi)存中，與CPU的處理速度相比，磁盤的讀寫操作非常慢。索引表過大、過多，可能會造成頻繁的磁盤I/O操作，這會極大增加查詢的時間[6]。

針對HBase查詢慢的問題，華為技術(shù)公司基于Coprocessor（協(xié)處理器）開發(fā)的hindex框架支持二級索引，但hindex基于HBase 0.94版本開發(fā)，如今版本老舊，也不再維護。徐江峰等[7]提出New-Grid框架，此方案擴展性較差，也未作負載均衡，容易產(chǎn)生性能瓶頸。黨鵬[8]提出LBIndexer機制，利用最小均方差（Least Mean Square， LMS）模型管理索引數(shù)據(jù)，增強了索引的可用性，但基于LMS設(shè)計的索引，其性能易受長久不使用的大索引文件影響，會降低索引文件的讀寫與查詢速度。王惟一[9]也基于LMS提出CFIDM數(shù)據(jù)模型，根據(jù)列族存儲特點縮小待查詢的存儲文件數(shù)量，從而提高查詢效率。黃璨等[10]通過分片計數(shù)布隆過濾器，利用哈希映射的方式建立二級索引，但在分片數(shù)據(jù)量大的情況下優(yōu)化效果并不明顯。葉奇明等[11]將Hive（數(shù)據(jù)倉庫工具）作為HBase的查詢?nèi)肟冢欢讷@得查詢效率提升的同時增加了系統(tǒng)的不穩(wěn)定性。朱松杰等[12]通過協(xié)處理器實現(xiàn)二級索引的快速構(gòu)建，并根據(jù)HBase表的變化自動更新索引，由于該方案對所有列建立索引且索引文件與HBase處于同一服務(wù)器，這會增大內(nèi)存資源的消耗，嚴重時甚至可能使服務(wù)器癱瘓。

HBase查詢優(yōu)化的方案有很多，其探索腳步也從未停止，但實現(xiàn)方式大多較為復(fù)雜，局限性大，并且代碼耦合性強，無法進行廣泛應(yīng)用，造成資源的重復(fù)建設(shè)。

3? ?CFH設(shè)計（Design of CFH）

建立一個獨立于業(yè)務(wù)系統(tǒng)、支持多級索引構(gòu)建的協(xié)調(diào)機制，對HBase查詢優(yōu)化與系統(tǒng)維護具有十分重要的意義。為了達到這樣的目的，本節(jié)基于Lucene技術(shù)設(shè)計索引中間件CFH。

3.1? ?CFH介紹

CFH服務(wù)端基于Netty（網(wǎng)絡(luò)應(yīng)用程序框架）開發(fā)，Netty的NIO（Non-blocking，同步非阻塞I/O）機制以及零拷貝技術(shù)具有優(yōu)異的性能[13]。服務(wù)端打包后通過jar文件啟動，僅在配置文件中進行HBase鏈接地址等少量設(shè)置，即可快速啟動，易于部署。通過CFH，可以按需建立索引，區(qū)分出冷熱數(shù)據(jù)，加速查詢。下面從不同的數(shù)據(jù)操作類型闡述CFH的業(yè)務(wù)邏輯，主要是針對二級索引、中間件進行的輔助操作。

（1）查詢操作。CFH會判斷查詢操作是否基于索引，如果不是，則先通過Lucene查詢出符合條件的主鍵值，然后創(chuàng)建新的查詢語句，通過主鍵值在HBase中查詢數(shù)據(jù)。調(diào)用Lucene技術(shù)時，如果發(fā)生索引覆蓋，則直接返回查詢結(jié)果。查詢流程如圖1所示。

（2）修改操作。重點在于判斷索引字段是否發(fā)生修改，如果未修改索引字段，則無須操作二級索引文檔，僅調(diào)用HBase服務(wù)處理原數(shù)據(jù)。

（3）新增操作。此操作需要客戶端告知中間件建立索引的字段。除了把新數(shù)據(jù)添加到HBase中，HBase還會將需建立索引的字段與數(shù)據(jù)的主鍵添加到二級索引文檔中，便于后續(xù)檢索。寫入流程如圖2所示。

（4）刪除操作。若刪除的數(shù)量比較大，CFH會檢查索引記錄數(shù)，如果剩余索引數(shù)據(jù)比較少，CFH會將剩余數(shù)據(jù)建立新的索引，并啟動定時任務(wù)，在不影響業(yè)務(wù)運轉(zhuǎn)的情況下，定期刪除數(shù)據(jù)。若刪除的數(shù)據(jù)較少，則直接刪除Lucene索引文檔中的數(shù)據(jù)。

3.2? ?CFH架構(gòu)設(shè)計

CFH涉及服務(wù)端與客戶端，建立一套有效的通信機制非常重要。CFH的工作流程可以劃分為八個步驟，包括：

（1）客戶端與服務(wù)器端建立連接;

（2）客戶端對數(shù)據(jù)序列化并傳輸;

（3）服務(wù)端接收數(shù)據(jù)，完成反序列化并驗證操作權(quán)限;

（4）服務(wù)端根據(jù)請求類型，選擇對應(yīng)的解析器解析請求參數(shù);

（5）對請求進行拆分，完成請求重寫;

（6）本地查詢以及通過RPC（遠程過程調(diào)用）調(diào)用Lucene或HBase服務(wù);

（7）封裝數(shù)據(jù)、序列化以及回寫客戶端;

（8）客戶端接收數(shù)據(jù)，反序列化。

中間件的服務(wù)端采用Zookeeper（分布式協(xié)調(diào)工具）進行集群部署，采用一主多從結(jié)構(gòu)，CFH集群的主節(jié)點負責(zé)處理HBase寫操作，讀操作由從節(jié)點進行。CFH架構(gòu)示意圖如圖3所示。

由圖3可知，CFH服務(wù)端包含七個部分，各部分功能如下：

（1）連接器：管理與客戶端的連接，通信方式采用Http

（Hypertext Transfer Protocol，超文本傳輸協(xié)議）+JSON

（JavaScript Object Notation，JS對象簡譜）的形式，網(wǎng)絡(luò)I/O模型為Netty。

（2）安全管理：負責(zé)數(shù)據(jù)信息的加密以及連接權(quán)限的管理。

（3）序列化與反序列化：數(shù)據(jù)傳輸前后，控制對象與字節(jié)序列之間的轉(zhuǎn)化，CFH采用FastJson工具包進行JSON數(shù)據(jù)的解析與生成。

（4）解析器：解析請求，針對不同的請求類型，調(diào)用相關(guān)解析器以及本地業(yè)務(wù)。

（5）本地業(yè)務(wù)：業(yè)務(wù)邏輯增強，對客戶端請求進行重構(gòu)以及生成本地索引。

（6）同步器：采用原生Lucene服務(wù)包建立索引時，集群節(jié)點進行索引文檔同步。

（7）遠程調(diào)用：調(diào)用HBase等服務(wù)、操作索引以及獲取客戶端需要的數(shù)據(jù)。

為了增強可用性，服務(wù)端設(shè)置了兩種創(chuàng)建索引的方式。第一種通過CFH原生集成的Lucene服務(wù)包實現(xiàn)，此方法生成的索引文件在中間件所在的服務(wù)器上。由于CFH可以進行分布式部署，集群節(jié)點需要對索引進行同步，從而保證數(shù)據(jù)的一致性，這在一定程度上會增加系統(tǒng)資源消耗。索引同步通過操作日志進行，CFH集群中非查詢操作由主節(jié)點處理，將操作記錄保存到同步日志中，主節(jié)點會定時往其他節(jié)點發(fā)送同步日志，從節(jié)點接收到日志文件后更新索引文檔。第二種是利用ES（Elasticsearch）。ES是一種基于Lucene技術(shù)的分布式搜索引擎，有著較為成熟的索引構(gòu)建以及檢索方法，但這種方式需要更多的服務(wù)器資源。如果通過ES構(gòu)建二級索引，需要在服務(wù)端啟動之前，在配置文件中做出相應(yīng)的設(shè)置。采用ES的情況下，可以經(jīng)Kibana（可視化平臺）工具對索引進行可視化管理。在代碼實現(xiàn)中，根據(jù)配置參數(shù)，利用JNDI（Java Naming and Directory Interface，Java命名和目錄接口）機制，CFH會加載不同的索引創(chuàng)建工具包，即采用本地生成或者ES生成索引的方式。

CFH客戶端包括連接器、序列化與反序列化以及轉(zhuǎn)發(fā)器三部分。連接器會從Zookeeper中獲取CFH的集群信息，轉(zhuǎn)發(fā)器則根據(jù)讀寫請求選擇CFH集群節(jié)點?？蛻舳瞬僮鞣绞讲蛔鲞^多新的設(shè)計，在已有開發(fā)包的基礎(chǔ)上進行封裝。CFH客戶端操作基于org.apache.HBaseHBase-client包中提供的API，對其中的部分API進行了擴展，通過新的API告知CFH是否需要操作二級索引，默認服務(wù)端會對所有字段建立索引?？蛻舳死肧pring Boot（服務(wù)開發(fā)框架）的自動裝配機制降低配置復(fù)雜度，通過系統(tǒng)的配置文件導(dǎo)入CFH外部配置。

3.3? ?CFH故障處理

引入中間件會增加系統(tǒng)的不穩(wěn)定性。如果中間件服務(wù)發(fā)生故障，會導(dǎo)致該鏈路服務(wù)不可用[14]。為了避免中間件故障造成的服務(wù)不可用，CFH服務(wù)端以Zookeeper作為注冊中心進行集群部署。通過集群部署可以降低服務(wù)不可用的概率，同時增強系統(tǒng)的吞吐量。此外，在CFH客戶端設(shè)置了故障、超時重試機制。如果重試達到一定次數(shù)仍未獲得響應(yīng)，客戶端將越過中間件直接訪問HBase，在HBase正常的情況下保證提供服務(wù)，但客戶端對HBase服務(wù)器信息的獲取仍通過中間件?？蛻舳藭O(shè)置定時任務(wù)，持久化最新的服務(wù)信息到本地，客戶端本身不需要對HBase進行配置。

4? ?性能測試（Performance testing）

為了方便查看二級索引信息，實驗所采用的索引構(gòu)建方式為ES，通過Kibana可視化界面操作索引，構(gòu)建索引時采用的分詞器為IKAnalyzer（中文分詞工具包）。測試用的主機為CentOS系統(tǒng)，CPU為Intel（R） Core（TM） i9-7900X CPU @ 3.30 GHz，64 GB內(nèi)存，通過VMWare15軟件搭建三臺CentOS7虛擬機，每臺分配8 GB內(nèi)存。測試軟件采用集群方式部署，版本信息如表1所示。HBase與ES內(nèi)存分配為4 GB。測試軟件未做其他優(yōu)化措施，均為默認設(shè)置。客戶端在另一臺物理機上，Windows 10操作系統(tǒng)，配置為Intel（R） Core（TM） i5-9600K CPU @ 3.70 GHz，16 GB內(nèi)存。實驗準備過程中，利用Python腳本批量生產(chǎn)了1，000萬條實驗數(shù)據(jù)，每條數(shù)據(jù)約76 字節(jié)，包含用戶個人信息共7 個字段，分別為姓名、年齡、性別、學(xué)歷、電話、郵箱和國籍，每個字段由字母、數(shù)字或特殊字符組成。

表2表示數(shù)據(jù)量與所需建立二級索引字段數(shù)不同組合情況下的寫入耗時（字段值為0表示無任何字段需要建立二級索引，但數(shù)據(jù)仍經(jīng)CFH中轉(zhuǎn)），單位為秒。

從表2可以看出，建立索引以及需建立索引的字段數(shù)增加都會增加存儲耗時，因為中間件重構(gòu)請求并維護索引數(shù)據(jù)結(jié)構(gòu)需要消耗額外的時間。此外，隨著數(shù)據(jù)量的增加，寫入時間也以近似線性的趨勢增加。表2中的實驗均為10，000 條數(shù)據(jù)的批寫入，由于未作其他優(yōu)化，高頻提交小數(shù)據(jù)會導(dǎo)致HBase頻繁創(chuàng)建線程并進行資源回收，浪費服務(wù)器資源，嚴重時會出現(xiàn)宕機，因而采用批寫入的方式。當(dāng)CFH不可用時，客戶端直連HBase，此時寫入效率為1.3 秒/萬條，未建立任何二級索引。

查詢時，提取數(shù)據(jù)所有字段信息，即先通過ES獲取主鍵，繼而經(jīng)主鍵查詢數(shù)據(jù)信息，不考慮索引覆蓋的優(yōu)化效果。表3為不同條件下經(jīng)CFH的查詢耗時（模糊匹配字段數(shù)與HBase數(shù)據(jù)量的組合），單位為秒。

檢索時，測試100 條記錄取均值。由表3可知，數(shù)據(jù)量與模糊匹配的字段數(shù)增加，都會增加查詢的時間，但經(jīng)CFH與ES的配合，CFH檢索仍達毫秒級查詢。由此可見，此方案實現(xiàn)了快速查詢。

5? ?結(jié)論（Conclusion）

本文設(shè)計了分布式存儲索引中間件CFH，通過Lucene技術(shù)構(gòu)建二級索引，實現(xiàn)快速檢索。經(jīng)過實驗驗證，CFH在保證大規(guī)模數(shù)據(jù)并發(fā)寫入需求的同時，有效地改善了HBase的檢索效率，對千萬級數(shù)據(jù)查詢可達毫秒級檢索。CFH獨立于業(yè)務(wù)系統(tǒng)，基于已有的HBase客戶端工具包進行開發(fā)，易于整合到已有系統(tǒng)中，支持集群部署。然而，中間件對復(fù)雜查詢的支持還不夠完善，采用原生Lucene工具包構(gòu)建索引，集群節(jié)點同步也可能會發(fā)生數(shù)據(jù)丟失的問題。

參考文獻（References）

[1] 周淳，李賢慧.一種實時數(shù)據(jù)庫的分布式存儲方法[J].計算機系統(tǒng)應(yīng)用，2019，28（04）：125-130.

[2] 周逸文.分布式存儲技術(shù)和應(yīng)用淺析[J].數(shù)碼世界，2017（12）：49.

[3] 田勝利.針對HBase的MapReduce數(shù)據(jù)訪問方式的優(yōu)化[D].長沙：國防科學(xué)技術(shù)大學(xué)，2012.

[4] YE F， ZHU S J， LOU Y S， et al. Research on index mechanism of HBase based on coprocessor for sensor data[C]// REISMANS. 2019 IEEE 43rd Annual Computer Software and Applications Conference（COMPSAC）. Los Alamitos， CA： IEEE Computer Society， 2019： 598-603.

[5] 吳國泉.基于HBase的全文索引及檢索技術(shù)的研究[D].武漢：華中科技大學(xué)，2015.

[6] 石磊，黃高攀，喬雄.基于內(nèi)存數(shù)據(jù)庫的索引算法研究[J].信息技術(shù)，2016，40（11）：139-142.

[7] 徐江峰，譚玉龍.基于HBase的多維索引查詢機制的優(yōu)化[J].計算機應(yīng)用，2020，40（02）：571-577.

[8] 黨鵬.HBase層次化輔助索引系統(tǒng)的設(shè)計與實現(xiàn)[D].西安：西安電子科技大學(xué)，2019.

[9] 王惟一.基于存儲模型的HBase查詢優(yōu)化技術(shù)研究[D].南京：南京大學(xué)，2018.

[10] 黃璨，方旭昇，張朝泉.分片計數(shù)布隆過濾器及其在HBase二級索引的應(yīng)用[J].計算機系統(tǒng)應(yīng)用，2016，25（03）：119-123.

[11] 葉奇明，陳俊宇.Hive over HBase框架查詢性能研究[J].廣東石油化工學(xué)院學(xué)報，2018，28（06）：36-38，42.

[12] 朱松杰，婁淵勝，葉楓，等.基于協(xié)處理器的HBase內(nèi)存索引機制的研究[J].計算機工程與應(yīng)用，2020，56（01）：98-105.

[13] 朱炯名.基于智慧水務(wù)的供水大數(shù)據(jù)采集架構(gòu)分析研究[J].軟件工程，2018，21（09）：5-7.

[14] CIAVOTTA M， ALGE M， MENATO S， et al. A microservice-based middleware for the digital factory[J]. Procedia Manufacturing， 2017， 11（05）：931-938.

作者簡介：

黃? 靜（1965-），女，博士，教授.研究領(lǐng)域：通信工程，大數(shù)據(jù)，深度學(xué)習(xí).

別要祥（1996-），男，碩士生.研究領(lǐng)域：軟件工程，大數(shù)據(jù).

謝? ?宣（1995-），男，碩士生.研究領(lǐng)域：軟件工程，圖像處理.