黃靜，別要祥，謝宣

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

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

中圖分類號(hào)：TP311.1? ? ?文獻(xiàn)標(biāo)識(shí)碼：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ì)算機(jī)需要管理的數(shù)據(jù)呈指數(shù)級(jí)增長(zhǎng)[1]，龐大的數(shù)據(jù)規(guī)模給存儲(chǔ)和處理帶來了極大的挑戰(zhàn)。受單機(jī)存儲(chǔ)的性能瓶頸以及單點(diǎn)故障影響，分布式存儲(chǔ)應(yīng)運(yùn)而生[2]。HBase是一個(gè)面向列的高性能分布式存儲(chǔ)系統(tǒng)[3]，其優(yōu)異的高并發(fā)讀寫性能受到眾多企業(yè)的青睞，甚至作為企業(yè)核心數(shù)據(jù)庫(kù)使用。但在大數(shù)據(jù)存儲(chǔ)情況下，HBase存在查詢慢的問題[4]，并且相關(guān)檢索優(yōu)化措施實(shí)現(xiàn)復(fù)雜，容錯(cuò)性能低，與系統(tǒng)業(yè)務(wù)耦合緊密，不利于系統(tǒng)的擴(kuò)展和升級(jí)。

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

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

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

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

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

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

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

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

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

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

3.1? ?CFH介紹

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

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

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

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

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

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

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

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

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

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

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

（5）對(duì)請(qǐng)求進(jìn)行拆分，完成請(qǐng)求重寫;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3? ?CFH故障處理

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

4? ?性能測(cè)試（Performance testing）

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

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

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

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

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

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

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

參考文獻(xiàn)（References）

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

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

[3] 田勝利.針對(duì)HBase的MapReduce數(shù)據(jù)訪問方式的優(yōu)化[D].長(zhǎng)沙：國(guó)防科學(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] 吳國(guó)泉.基于HBase的全文索引及檢索技術(shù)的研究[D].武漢：華中科技大學(xué)，2015.

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

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

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

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

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

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

[12] 朱松杰，婁淵勝，葉楓，等.基于協(xié)處理器的HBase內(nèi)存索引機(jī)制的研究[J].計(jì)算機(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.

作者簡(jiǎn)介：

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

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

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