Hbase的二級索引和RowKey的設計

擊水三千里發表於2020-10-05
索引

Hbase查詢簡介

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

HBase裡面只有rowkey作為一級索引

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

為了HBase的資料查詢更高效、適應更多的場景， 諸如使用非rowkey欄位檢索也能做到秒級響應，或者支援各個欄位進行模糊查詢和多欄位組合查詢等， 因此需要在HBase上面構建二級索引， 以滿足現實中更復雜多樣的業務需求。

 

二級索引方案

基於Coprocessor方案

原理：基於Coprocessor（0.92版本開始引入，達到支援類似傳統RDBMS的觸發器的行為）開發自定義資料處理邏輯，採用資料“雙寫”（dual-write）策略，在有資料寫入同時同步到二級索引表

開源方案：

1、華為的hindex：當年剛出來的時候比較火，但是版本較舊，看GitHub專案地址最近這幾年就沒更新過

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

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

缺點： 但是Coprocessor的方案入侵性比較強， 增加了在Regionserver內部需要執行和維護二級索引關係表的程式碼邏輯等，對Regionserver的效能會有一定影響 

非Coprocessor方案

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

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

2、CDHSearch

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

3、 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應儘量簡短

 

參考文章

https://blog.csdn.net/weixin_43892898/article/details/89249322

https://blog.csdn.net/WYpersist/article/details/79830811

https://zhuanlan.zhihu.com/p/69462736 

 

相關文章