HBase分布式二級索引通用方案研究

周偉　劉希　陳浩

摘要：二級索引方案是分布式存儲研究的重要分支之一，基于通用目標設計二級索引方案可避免單一業務編程繁瑣問題，使實施人員更多地關注業務本身而非編程細節。以HBase數據庫為研究對象，引入分布式索引機制，通過重寫觀察者Observer協處理器方法，操作完數據后立即觸發創建或更新索引的請求，進一步在SolrCloud中完成對索引的管理。反向進行多條件組合查詢時，先在SolrCloud中查詢包含行鍵和索引列的文檔，再以行鍵為條件查詢并獲取HBase記錄。部署通用方案，實驗證明該方案很好地滿足了創建和維護HBase二級索引的要求，且保證了索引與記錄的一致性，對進一步研究分布式存儲二級索引方案有一定的指導意義。

關鍵詞：分布式存儲；分布式索引；二級索引；協處理器；通用方案

DOIDOI：10.11907/rjdk.171483

中圖分類號：TP391

文獻標識碼：A文章編號文章編號：16727800（2018）003018704

英文摘要Abstract：Secondary indexing scheme is an important branch of HBase database research. A scheme based on the general purpose will avoid programming against every single business detail， which helps the developers focus more on the business rather than the programming details. By overriding the methods of observer coprocessor， requests for creating indexes will be triggered after the records are stored in database， and then the indexes will be created and stored in SolrCloud which is a distributed indexer. Furthermore， documents of SolrCloud which contain both row keys and indexed columns can be filtered by a multiconditional query， and the target records will be fetched by the target row keys in the documents. Through deploying this scheme， it turns out that it completely meets the requirements of creating and maintaining secondary indexes of HBase and ensures the consistency between indexes and records. Whats more， the scheme referred in this paper has instructional significance for further study of HBase secondary indexing.

英文關鍵詞Key Words：HBase； SolrCloud； secondary indexing； coprocessor； general schema

0引言

索引是一種特殊文件，存儲著數據表中所有記錄的引用指針，從邏輯上對記錄進行排序。索引通常建立在數據表的某些列上，在數據量不大時，有無合適的索引對記錄查找速度影響不大，隨著數據量的增加，查找性能會急劇下降，此時索引能加速查找過程。索引對數據庫的查詢速度至關重要，重構索引是數據庫性能調優的起點。傳統關系型數據庫支持二級索引（也稱多級索引），擴展了一級索引只針對單列構建索引的特性，主要用于多條件組合查詢的場景。

在大數據應用中，作為一個分布式、可伸縮的列存儲數據庫，HBase表現出強大的生命力。HBase歸屬Hadoop生態系統，利用Hadoop分布式文件系統存儲切片數據，通過Hadoop MapReduce計算框架處理海量數據，適用于聯機分析處理和數據挖掘的場景。HBase主要定義了一個四維數據模型，分別為行鍵（rowkey）、列族（column family）、列修飾符（column qualifier）和版本（version）。HBase基于行鍵有序存儲，在查詢時使用行鍵十分高效，同時列修飾符可以被動態創建，適合應對屬性不固定的半結構化數據。然而HBase本身無法輕易建立二級多列索引（以下簡稱二級索引），隨著應用業務復雜度的增加，單一行鍵滿足不了類似關系型數據庫多條件組合查詢、分頁等功能的要求。

為了突破單一行鍵在復雜查詢上的限制，避免全表掃描，業界已有一些研究成果。朱夏等[1]基于多維數據檢索機制MIndex，實現了從復雜查詢請求到一維查詢鍵值的轉換，并保證了復雜查詢的高效性。丁飛等[2]基于HBase協處理器，通過倒排索引實現了第二索引擴展功能。徐熙超等[3]提出HBase4M架構，利用協處理器建立和維護輔助索引，將字段查詢轉化為索引表的行鍵查詢。葛微等[4]提出的分層式非主鍵索引方案中，在組合查詢時也會轉換成索引表主鍵的查詢。上述研究需要巧妙地設計索引表的行鍵，通過將多個查詢條件鍵值對映射到行鍵的方式縮小索引表的行鍵區間，最后確定目標行鍵。該方式依賴于表結構已知且查詢條件固定的情況，具有一定的局限性。陳東輝等[5]依靠第三方搜索引擎Solr提供的API接口，參考具體業務中的查詢用例對相關字段建立輔助索引以適應檢索時效。該方式借助Solr提供的索引功能為HBase記錄創建、存儲索引，其中HBase負責存儲數據，Solr負責索引數據和檢索。許杰等[6]亦使用Solr建立二級索引的方法，提高了檢索效率。該方式充分利用各角色的優點，更適于企業級的架構設計。考慮到適應海量數據存儲和索引的要求，將原有架構擴展為分布式架構極為迫切[7]。付劍生[8]總結了SolrCloud作為Solr分布式實現的特色功能：數據檢索時自動負載均衡、自動化容錯處理、索引分片、倒排索引的虛擬化存儲等。本文結合SolrCloud研究分布式存儲HBase二級索引的通用實現，基于通用目標設計構建索引的具體過程，該過程不依賴于任何特定的業務。二級索引方案整體架構如圖1。

1相關技術

1.1分布式存儲模型

HBase基于Hadoop分布式文件系統（HDFS）構建，對數據進行索引后，將結果文件存放在HDFS上，以提高查找或更新大數據表中目標記錄的速度，同時確保數據的容錯性。HBase支持線性伸縮和模塊化擴展，突破了關系型數據庫有限擴展能力的限制，通過新增節點，集群的存儲能力和處理能力明顯增強。同時基于HDFS的架構，HBase在故障處理和容錯方面具有優良的性能。

1.2分布式索引模型

SolrCloud為服務器之間分發索引文件和請求轉發創建了一個高可用、高容錯的分布式環境。一份索引文件經切片后被保存在某臺機器上，同時索引文件的多份拷貝會被分別存儲在其它機器上，客戶端通過Solr API請求文件，若分布式系統感知該機器出現宕機、故障，就會直接返回其它機器上的文件拷貝。SolrCloud還支持集群集中管理、自動負載均衡和故障切換等特性。

1.3分布式應用協調服務

ZooKeeper作為分布式應用協調工具，能為分布式應用提供高性能和可靠的協調服務，簡化分布式協調服務的實現。HBase將元數據存儲在ZooKeeper中，使得客戶端不能直接訪問或修改HBase元數據，并保證集群只存在唯一HMaster。SolrCloud將配置文件存放在ZooKeeper中，以集中化管理配置信息，使得各節點共享信息，協調工作，并通過配置ZooKeeper訪問控制列表以控制外部API調用。HBase（HDFS）、SolrCloud和ZooKeeper關系如圖2所示。

2HBase二級索引

傳統關系型數據庫（以MySQL為例）架構主要分為SQL解析引擎和存儲引擎兩部分，前者包括解析器和查詢優化器，負責解析，后者負責執行（查詢或存儲），解析完SQL后，解析引擎會調用存儲引擎的相關接口供進一步處理。根據MySQL的架構設計，本文構思了HBase二級索引方案（見圖3）。HBase作為存儲引擎，負責存儲數據，待執行完存儲命令，索引器向索引引擎發起創建索引的請求，生成記錄的索引數據。

HBase自0.92版本后引入了協處理器Coprocessor機制以支持二級索引，Coprocessor存在兩種實現，分別是Observer Coprocessor和Endpoint Coprocessor，前者在特定事件出現前后被觸發，功能與關系型數據庫中的觸發器類似，后者則可類比關系型數據庫的存儲過程，具體邏輯在RegionServer服務器端執行，客戶端僅通過類庫方法調用服務端接口。Coprocessor執行過程如圖4，其中Observer與Endpoint相互之間可通過ZooKeeper共享數據。

根據HBase數據入庫的基本流程[5]，本文在構建二級索引過程時基于Observer實現，待記錄被寫入（Put）到HRegion后，會立即觸發將記錄同步到SolrCloud的操作，進而生成索引。客戶端讀取（Get）記錄時，首先根據索引字段請求SolrCloud查詢索引，得到目標行鍵，繼而根據目標行鍵獲取HBase記錄。二級索引方案中，各組件通過ZooKeeper協同工作，并通過暴露API接口供外部調用，整體流程如圖5。

2.1索引方案設計

Observer允許實施人員在記錄被寫入到HBase前后作一些處理，本文提供的索引工具類通過繼承BaseRegionObserver抽象類，重寫postPut方法，請求SolrCloud生成索引。默認情況下，HBase每提交一條數據都會觸發一次postPut操作，考慮到系統的性能，工具類引入了一個本地可持久化的隊列機制，用來代理創建或刪除索引的操作，在postPut或postDelete重載方法中將包含索引字段的記錄放入隊列，隊列以定時器輪詢的方式向SolrCloud提交數據，同時監控異常以供故障恢復。索引工具類創建索引的活動見圖6。

通用性是軟件設計的重要準則之一，通用性使得工具更易于擴展，避免重復編碼，提高開發效率。檢索業務升級、需求變更伴隨著對索引字段靈活性的要求，這也意味著在設計時需考慮索引工具類對不同業務二級索引的通用性要求。

為提高索引方案的通用性，本文規范了Solr配置和HBase創建數據表過程，首先在Solr的配置文件中定義統一的動態字段，格式以下劃線加字母的方式進行聲明，對照關系如表1。利用工具構建HBase索引，Solr中每一條Document對應著HBase的一條記錄，除了需要索引的字段外，還包括4個缺省字段：ID（表名+行鍵）、表名、行鍵、更新時間。接著在HBase中建立需索引的字段，其列修飾符按字段名加預定義的標識符進行定義。比如統計用戶對各網站的訪問量排名，在設計數據表時，訪問量列標識符需按照“訪問量_i”的格式設計，其中“i”表示訪問量是整型數。該方式統一了創建和維護索引的流程，在設計列修飾符時相應字段按約定命名。實現過程參見代碼如下：

//獲取rowKey

for （Cell cell：cells）{

//獲取cFamily，cQualifier，cValue

if （cQualifier.endsWith（"_s"））

jsonSet.putObject（cFamily+F_SEPARATOR+cQualifier，（new JsonObject（））.putString（"set"，cValue））；

else if （cQualifier.endsWith（"_t"））

jsonSet.putObject（cFamily+F_SEPARATOR+cQualifier，（new JsonObject（））.putString（"set"，cValue））；

//處理其它類型的cQualifier

}

jsonSet.putString（F_ID，tableName+F_SEPARATOR+rowKey）；

jsonSet.putObject（F_TABLENAME，（new JsonObject（））.putString（"set"，tableName））；

jsonSet.putObject（F_ROWKEY，（new JsonObject（））.putString（"set"，rowKey））；

jsonSet.putObject（F_UPDATETIME，（new JsonObject（））.putString（"set"，SolrTools.solrDateFormat.format（new java.util.Date（））））；

_bqUpdate.enqueue（jsonSet.encode（）.getBytes（SolrTools.UTF_8））；

2.2部署索引方案

本文采用1臺服務器，基于3臺虛擬機搭建大數據分布式應用實驗環境。各機器的具體配置如表2。安裝、配置分布式集群時，需配置各機器SSH免密碼登錄、關閉防火墻、調整SELinux參數、同步機器時間，另外使用官方推薦的整合方式確保各軟件版本之間的兼容性。依次分別啟動ZooKeeper、Hadoop、HBase和Solr Cloud，啟動無異常后，可通過WebUI訪問HBase和SolrCloud。

停止HBase服務，將索引工具類打包后上傳給所有的Region Servers，并放在HBase根目錄下的lib子目錄中，接著配置HBasesite.xml文件，主要設置Solr Cloud地址，設置coprocessor實現類為索引工具類。再次啟動HBase服務，通過客戶端請求HBase，并插入預定義格式的記錄，刷新SolrCloud集群狀態后，發現SolrCloud產生新的索引記錄，ID參數形如“表名#行鍵”，其它屬性均與HBase記錄一致。如先執行建表和插入實驗數據的命令：

put 'test_table'，'row_1'，'report：name_s'，'張三'

put 'test_table'，'row_1'，'report：age_i'，'24'

put 'test_table'，'row_1'，'report：gender_b'，'true'

put 'test_table'，'row_1'，'report：grade_f'，'89.5'

put 'test_table'，'row_2'，'report：name_s'，'李四'

put 'test_table'，'row_2'，'report：age_i'，'23'

put 'test_table'，'row_2'，'report：gender_b'，'true'

put 'test_table'，'row_2'，'report：grade_f'，'90.0'

隨后在客戶端按指定URL（形如[domain]：[port]/solr/admin/collections？action=RELOAD&name;=[coreName]）重新加載集群狀態，查詢索引即得到如下記錄：

"docs"：[{

"report#name_s"："張三"，

"id"："test_table#row_1"，

"t_s"："test_table"，

"r_s"："row_1"，

"u_dt"："2016-07-10T22：47：13Z"，

"report#age_i"：24，

"report#gender_b"：true，

"report#grade_f"：89.5，

"_version_"：1539479473261379600

}，{

"report#name_s"："李四"，

"id"："test_table#row_2"，

"t_s"："test_table"，

"r_s"："row_2"，

"u_dt"："2016-07-10T22：47：26Z"，

"report#age_i"：23，

"report#gender_b"：true，

"report#grade_f"：90，

"_version_"：1539479487465390000

}]

以同樣的方式測試更新表中某行記錄、刪除某行記錄的某一列以及刪除某行記錄的情況，發現SolrCloud存儲的索引都會產生相應變化。多條件查詢HBase記錄時，先在客戶端通過API查詢Solr索引，待返回目標行鍵，便可根據目標行鍵查詢HBase目標記錄。

3結語

本文針對HBase在二級索引問題上的缺陷，結合SolrCloud分布式索引特性，利用HBase提供的Observer Coprocessor API，設計了創建和維護HBase二級索引的通用實現，簡化了開發流程，避免了針對單一業務編程的繁瑣問題。通過部署索引方案，發現該方案能很好地滿足創建和維護HBase二級索引的要求，并保證索引與記錄的一致性。對于通用實現的高并發性能測試將是下一步研究的工作。

參考文獻參考文獻：

[1]朱夏，羅軍舟，宋愛波，等.云計算環境下支持復雜查詢的多維數據索引機制[J].計算機研究與發展，2013，50（8）：15921603.

[2]丁飛，陳長松，張濤，等.基于協處理器的區域級第二索引研究與實現[J].計算機應用，2014，34（S1）：181185.

[3]徐熙超，楊錚，馬廷淮.基于HBase的氣象結構化數據查詢優化[J/OL].計算機工程與應用，http：//www.cnki.net/kcms/detail/11.2127.TP.20160510.1117.038.html.

[4]葛微，羅圣美，周文輝，等.一種基于分層式索引的高效查詢技術與系統[J].計算機學報，2016，39（1）：140153.

[5]陳東輝，曾樂，梁中軍，等.基于的氣象地面分鐘數據分布式存儲系統[J].計算機應用，2014，34（9）：26172621.

[6]許杰，冷冰，李明桂，等.大數據處理技術在安全審計系統中的應用[J].通信技術，2016，49（3）：346351.

[7]吳廣君，王樹鵬，陳明，等.海量結構化數據存儲檢索系統[J].計算機研究與發展，2012，49（Sl）：15.

[8]付劍生，徐林龍，林文斌.分布式全網職位搜索引擎的研究與實現[J].計算機技術與發展，2015，25（5）：69.

責任編輯（責任編輯：何麗）