Hbase的二級索引和RowKey的設計

Hbase查詢簡介

Hbase查詢的時候，有如下幾種方式：
• 經過 rowkey方式，指定 獲取惟一記錄
• 經過 scan方式，設置satrtRow 和stopRow 參數進行範圍匹配(模糊查詢)
• 全表掃描，即直接掃描整張表中全部行記錄

HBase裏面只有rowkey做爲一級索引

Hbase的scan，不走主鍵索引，而是全表掃描，性能奇差。

爲了HBase的數據查詢更高效、適應更多的場景， 諸如使用非rowkey字段檢索也能作到秒級響應，或者支持各個字段進行模糊查詢和多字段組合查詢等， 所以須要在HBase上面構建二級索引， 以知足現實中更復雜多樣的業務需求。

 

二級索引方案

基於Coprocessor方案

原理：基於Coprocessor（0.92版本開始引入，達到支持相似傳統RDBMS的觸發器的行爲）開發自定義數據處理邏輯，採用數據「雙寫」（dual-write）策略，在有數據寫入同時同步到二級索引表

開源方案：

一、華爲的hindex：當年剛出來的時候比較火，可是版本較舊，看GitHub項目地址最近這幾年就沒更新過

二、Apache的phoenix：在目前開源的方案中，是一個比較優的選擇。主打SQL on HBase ， 基於SQL能完成HBase的CRUD操做，支持JDBC協議

優勢： 基於Coprocessor的方案，從開發設計的角度看， 把不少對二級索引管理的細節都封裝在的Coprocessor具體實現類裏面， 這些細節對外面讀寫的人是無感知的，簡化了數據訪問者的使用。

缺點： 可是Coprocessor的方案***性比較強， 增長了在Regionserver內部須要運行和維護二級索引關係表的代碼邏輯等，對Regionserver的性能會有必定影響 

非Coprocessor方案

常見的是採用底層基於Apache Lucene的Elasticsearch(下面簡稱ES)或Apache Solr ，來構建強大的索引能力、搜索能力， 例如支持模糊查詢、全文檢索、組合查詢、排序等。

一、Lily HBase Indexer：
Lily HBase Indexer(也簡稱 HBase Indexer)是國外的NGDATA公司開源的基於solr的索引構建工具， 特點是其基於HBase的備份機制，開發了一個叫SEP工具， 經過監控HBase 的WAL日誌（Put/Delete操做），來觸發對solr集羣索引的異步更新， 基本對HBase無侵入性（但必須開啓WAL ）

二、CDHSearch

CDHSearch是Hadoop發行商Cloudera公司開發的基於solr的HBase檢索方案，部分集成了Lily HBase Indexer的功能。

三、 DataStory

有本身的大數據團隊的公司通常都會針對本身的業務場景進行優化，自行構建ES/Solr的搜索集羣。 例如數說故事企業內部的百億級數據全量庫，就是基於ES構建海量索引和檢索能力的案例。 主要優化點包括：

對企業的索引集羣面向的業務場景和模式定製，對通用數據模型進行抽象和平臺化複用須要針對多業務、多項目場景進行ES集羣資源的合理劃分和運維管理查詢須要針對多索引集羣、跨集羣查詢進行優化共用集羣場景須要作好防禦、監控、限流

增量索引： 平常持續接入的數據源，進行增量的索引更新

全量索引： 配套基於Spark/MR的批量索引建立/更新程序， 用於初次或重建已有HBase庫表的索引

數據查詢流程：

Datastory在作全量庫的過程當中，仍是有更多遇到的問題要解決，諸如數據一致性、大量小索引、多版本ES集羣共存等 

 

RowKey的設計

若是咱們RowKey設計爲uid+phone+name，那麼這種設計能夠很好的支持一下的場景:

uid=873969725 AND phone=18900000000 AND name=zhangsan
uid= 873969725 AND phone=18900000000
uid= 873969725 AND phone=189?
uid= 873969725

難以支持的場景：

phone=18900000000 AND name = zhangsan
phone=18900000000 
name=zhangsan

RowKey設計案例剖析

1. 查詢某用戶在某應用中的操做記錄

reverse(userid) + appid + timestamp

2. 查詢某用戶在某應用中的操做記錄（優先展示最近的數據）

reverse(userid) + appid + (Long.Max_Value - timestamp)

3. 查詢某用戶在某段時間內全部應用的操做記錄

reverse(userid) + timestamp + appid

4. 查詢某用戶的基本信息

reverse(userid)

5. 查詢某eventid記錄信息

salt + eventid + timestamp

若是 userid是按數字遞增的，而且長度不一，能夠先預估 userid 最大長度，而後將userid進行翻轉，再在翻轉以後的字符串後面補0（至最大長度）；若是長度固定，直接進行翻轉便可（如手機號碼）。

在第5個例子中，加鹽的目的是爲了增長查詢的併發性，加入Slat的範圍是0~n，能夠將數據分爲n個split同時作scan操做，有利於提升查詢效率。

RowKey設計原則總結

在HBase的使用過程，設計RowKey是一個很重要的一個環節。咱們在進行RowKey設計的時候可參照以下步驟： 

1. 結合業務場景特色，選擇合適的字段來作爲RowKey，而且按照查詢頻次來放置字段順序
2. 經過設計的RowKey能儘量的將數據打散到整個集羣中，均衡負載，避免熱點問題
3. 設計的RowKey應儘可能簡短