一種分布式存儲索引中間件的設計與實現

黃靜，別要祥，謝宣

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

關鍵詞：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）

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

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

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

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

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

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

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

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

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

3? ?CFH設計（Design of CFH）

建立一個獨立于業務系統、支持多級索引構建的協調機制，對HBase查詢優化與系統維護具有十分重要的意義。為了達到這樣的目的，本節基于Lucene技術設計索引中間件CFH。

3.1? ?CFH介紹

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

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

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

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

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

3.2? ?CFH架構設計

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

（1）客戶端與服務器端建立連接;

（2）客戶端對數據序列化并傳輸;

（3）服務端接收數據，完成反序列化并驗證操作權限;

（4）服務端根據請求類型，選擇對應的解析器解析請求參數;

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

（6）本地查詢以及通過RPC（遠程過程調用）調用Lucene或HBase服務;

（7）封裝數據、序列化以及回寫客戶端;

（8）客戶端接收數據，反序列化。

中間件的服務端采用Zookeeper（分布式協調工具）進行集群部署，采用一主多從結構，CFH集群的主節點負責處理HBase寫操作，讀操作由從節點進行。CFH架構示意圖如圖3所示。

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

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

（Hypertext Transfer Protocol，超文本傳輸協議）+JSON

（JavaScript Object Notation，JS對象簡譜）的形式，網絡I/O模型為Netty。

（2）安全管理：負責數據信息的加密以及連接權限的管理。

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

（4）解析器：解析請求，針對不同的請求類型，調用相關解析器以及本地業務。

（5）本地業務：業務邏輯增強，對客戶端請求進行重構以及生成本地索引。

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

（7）遠程調用：調用HBase等服務、操作索引以及獲取客戶端需要的數據。

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

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

3.3? ?CFH故障處理

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

4? ?性能測試（Performance testing）

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

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

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

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

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

5? ?結論（Conclusion）

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

參考文獻（References）

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

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

[3] 田勝利.針對HBase的MapReduce數據訪問方式的優化[D].長沙：國防科學技術大學，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的全文索引及檢索技術的研究[D].武漢：華中科技大學，2015.

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

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

[8] 黨鵬.HBase層次化輔助索引系統的設計與實現[D].西安：西安電子科技大學，2019.

[9] 王惟一.基于存儲模型的HBase查詢優化技術研究[D].南京：南京大學，2018.

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

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

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

[13] 朱炯名.基于智慧水務的供水大數據采集架構分析研究[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-），女，博士，教授.研究領域：通信工程，大數據，深度學習.

別要祥（1996-），男，碩士生.研究領域：軟件工程，大數據.

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