Hbase Rowkey如何設計

這篇文章給大家分享的是有關Hbase Rowkey如何設計的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

      1、表的屬性

      (1)最大版本數：通常是3，如果對于更新比較頻繁的應用完全可以設置為1，能夠快速的淘汰無用數據，對于節省存儲空間和提高查詢速度有效果。不過這類需求在海量數據領域比較小眾。

      (2)壓縮算法：可以嘗試一下最新出爐的snappy算法，相對lzo來說，壓縮率接近，壓縮效率稍高，解壓效率高很多。

      (3)inmemory：表在內存中存放，一直會被忽略的屬性。如果完全將數據存放在內存中，那么hbase和現在流行的內存數據庫memorycached和redis性能差距有多少，尚待實測。

      (4)bloomfilter：根據應用來定，看需要精確到rowkey還是column。不過這里需要理解一下原理，bloomfilter的作用是對一個region下查找記錄所在的hfile有用。即如果一個region下的hfile數量很多，bloomfilter的作用越明顯。適合那種compaction趕不上flush速度的應用。

      2、rowkey

2.1 排序問題

數字rowkey的從大到小排序：原生hbase只支持從小到大的排序，這樣就對于排行榜一類的查詢需求很尷尬。那么采用rowkey = Integer.MAX_VALUE-rowkey的方式將rowkey進行轉換，最大的變最小，最小的變最大。在應用層再轉回來即可完成排序需求。

2.2 熱點問題
    HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行存取在臨近位置，便于scan。然而糟糕的rowkey設計是熱點的源頭。 熱點發生在大量的client直接訪問集群的一個或極少數個節點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起性能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由于主機無法服務其他region的請求。 設計良好的數據訪問模式以使集群被充分，均衡的利用。

    為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多數據情況下，數據應該被寫入集群的多個region，而不是一個。

下面是一些常見的避免熱點的方法以及它們的優缺點：

加鹽
    這里所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同。分配的前綴種類數量應該和你想使用數據分散到不同的region的數量一致。加鹽之后的rowkey就會根據隨機生成的前綴分散到各個region上，以避免熱點。

哈希
    哈希會使同一行永遠用一個前綴加鹽。哈希也可以使負載分散到整個集群，但是讀卻是可以預測的。使用確定的哈希可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行數據

反轉
    第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。

    反轉rowkey的例子以手機號為rowkey，可以將手機號反轉后的字符串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題

時間戳反轉
    一個常見的數據處理問題是快速獲取數據的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用 Long.Max_Value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的數據。比如需要保存一個用戶的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計[userId反轉][Long.Max_Value - timestamp]，在查詢用戶的所有操作記錄數據的時候，直接指定反轉后的userId，startRow是[userId反轉][000000000000],stopRow是[userId反轉][Long.Max_Value - timestamp]如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value - 起始時間]，stopRow是[userId反轉][Long.Max_Value - 結束時間] rowkey是hbase的key-value存儲中的key，通常使用用戶要查詢的字段作為rowkey，查詢結果作為value。可以通過設計滿足幾種不同的查詢需求。

      3、columnfamily

      columnfamily盡量少，原因是過多的columnfamily之間會互相影響。

      4、column

      對于column需要擴展的應用，column可以按普通的方式設計，但是對于列相對固定的應用，最好采用將一行記錄封裝到一個column中的方式，這樣能夠節省存儲空間。封裝的方式推薦protocolbuffer。

     以下會分場景介紹一些特殊的表結構設計方法，只是一些摸索，歡迎討論：

      value數目過多場景下的表結構設計：

       目前我碰到了一種key-value的數據結構，某一個key下面包含的column很多，以致于客戶端查詢的時候oom，bulkload寫入的時候oom，regionsplit的時候失敗這三種后果。通常來講，hbase的column數目不要超過百萬這個數量級。在官方的說明和我實際的測試中都驗證了這一點。

       有兩種思路可以參考，第一種是單獨處理這些特殊的rowkey，第二種如下：

      可以考慮將column設計到rowkey的方法解決。例如原來的rowkey是uid1,，column是uid2，uid3...。重新設計之后rowkey為<uid1>~<uid2>，<uid1>~<uid3>...當然大家會有疑問，這種方式如何查詢，如果要查詢uid1下面的所有uid怎么辦。這里說明一下hbase并不是只有get一種隨機讀取的方法。而是含有scan(startkey,endkey)的掃描方法，而這種方法和get的效率相當。需要取得uid1下的記錄只需要new Scan("uid1~","uid1~~")即可。

感謝各位的閱讀！關于“Hbase Rowkey如何設計”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！