HBase二級索引方案總結

在HBase中，表格的Rowkey按照字典排序，Region按照RowKey設定split point進行shard，透過這種方式實現的全域性、分散式索引，成為了其成功的最大的砝碼。圖1顯示了HBase表格的Rowkey切分與Region的部署關係圖。

圖1： HBase Rowkey-Region 關係圖

然而，隨著在HBase系統上應用的驅動，人們發現Global-Rowkey-Indexing不再滿足應用的需求。單一的透過Rowkey檢索資料的方式，不再滿足更多應用的需求，人們希望像SQL一樣檢索資料，select * from table where col=val。可是，HBase之前的定位是大表的儲存，要進行這樣的查詢，往往是要透過類似Hive、Pig等系統進行全表的MapReduce計算，這種方式既浪費了機器的計算資源，又因高延遲使得應用黯然失色。於是，在業界和社群，針對HBase Secondary Indexing的方案，成為HBase新版本(0.96)呼聲最高的一項Feature。

粗略分析了當前的技術，大概的方案可以總結為這樣兩類：

1、使用HBase的coprocessor。CoProcessor相當於HBase的Observer+hook，目前支援MasterObserver、RegionObserver和WALObserver，基本上對於HBase Table的管理、資料的Put、Delete、Get等操作都可以找到對應的pre***和post***。這樣如果需要對於某一項Column建立Secondary Indexing，就可以在Put、Delete的時候，將其資訊更新到另外一張索引表中。如圖二所示，對於Indexing裡面的value值是否儲存的問題，可以根據需要進行控制，如果value的空間開銷不大，逆向的檢索又比較頻繁，可以直接儲存在Indexing Table中，反之則避免這種情況。

圖2 使用HBase Coprocessor實現Secondary Indexing

2、由客戶端發起對於主表和索引表的Put、Delete操作的雙重操作。源自：http://hadoop-hbase.blogspot.com/2012/10/musings-on-secondary-indexes.html 【牆外】

它具體的做法總結起來有：

• 設定主表的TTL(Time To Live)比索引表小一點，讓其略早一點消亡。
• 不要在IndexingTable儲存Value值，即刪除如圖2所示的val列。
• Put操作時，對於操作的主表的所有列，使用同一的Local TimeStamp的值，更新到Indexing Table，然後使用該TimeStamp插入主表資料。
• Delete操作時，首先操作主表的資料，然後再去更新Indexing Table的資料。

雖然在這種方案裡無法保證原子性和一致性，但是透過TimeStamp的設定，No Locks和 No Server-side codes，使其在二級索引上有著較大的優勢。至於中間出錯的環節，我們看看是否可以容忍：

1）Put索引表成功，Put主表失敗。由於Indexing Table不儲存val值，仍需要跳轉到Main Table,所以這樣的錯誤相當於拿一個Stale index去訪問對應Rowkey吧了，對結果正確性沒有影響。

2）Delete主表成功，Delete索引表失敗。都是索引表的內容>=主表的內容而已，而實際返回值需要透過主表進行。

生產環境下，什麼樣的方法實用性更強？

就這個問題，根據個人當前對於生產環境下HBase叢集的經驗，綜合上面兩種方式的優劣，可以透過這樣的方式設計。

1、主表服務線上業務，它的效能需要保證。使用coprocessor和客戶端的封裝也好，都會影響其效能，所以在正常情況下，直接操作都不太合適。如果想使用方案二，我倒是感覺，可以調整Indexing Table的操作方式，去除保證其安全性的內容，比如可以關閉寫HLOG，這樣會進一步減低其操作的延遲。

2、離線更新索引表。在真正需要二級索引的場景內，其時效性要求往往不高。可以將索引實時更新到Redis等KV系統中，定時從KV更新索引到Hbase的Indexing Table中。PS:Redis裡面有DB設定的概念，可以按照時間段進行隔離，這樣某段時間內的資料會更新到Redis上，保證Redis匯入MapReduce之後仍然可以進行update操作。

 
原文地址：http://blog.sina.com.cn/s/blog_4a1f59bf01018apd.html