Hbase高階應用：建表高階屬性、行鍵設計、設計原則、熱點問題

阿新 • • 發佈：2019-02-04

Hbase建表高階屬性

1、BLOOMFILTER

預設是NONE 是否使用布隆過慮及使用何種方式
布隆過濾可以每列族單獨啟用。
使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 對列族單獨啟用布隆。

Default = ROW 對行進行布隆過濾。
對 ROW，行鍵的雜湊在每次插入行時將被新增到布隆。
對 ROWCOL，行鍵 + 列族 + 列族修飾的雜湊將在每次插入行時新增到布隆
使用方法: create ‘table’,{BLOOMFILTER =>’ROW’}
啟用布隆過濾可以節省讀磁碟過程，可以有助於降低讀取延遲

2、VERSIONS

預設是1 這個引數的意思是資料保留1個版本，如果認為我們的老版本資料對我們毫無價值不需要保留這麼多，且更新頻繁，那將此引數設為1 能節約2/3的空間。
使用方法: create 'table',{VERSIONS=>'2'}

附：MIN_VERSIONS => ‘0’是說在compact操作執行之後，至少要保留的版本

3、COMPRESSION

預設值是NONE 即不使用壓縮
這個引數意思是該列族是否採用壓縮，採用什麼壓縮演算法
使用方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'}

建議採用SNAPPY壓縮演算法
HBase中，在Snappy釋出之前（Google 2011年對外發布Snappy），採用的LZO演算法，目標是達到儘可能快的壓縮和解壓速度，同時減少對CPU的消耗；
在Snappy釋出之後，建議採用Snappy演算法（參考《HBase: The Definitive Guide》），具體可以根據實際情況對LZO和Snappy做過更詳細的對比測試後再做選擇。

Algorithm	remaining	Encoding	Decoding
GZIP	13.4%	21 MB/s	118 MB/s
LZO	20.5%	135 MB/s	410 MB/s
Zippy/Snappy	22.2%	172 MB/s	409 MB/s

如果建表之初沒有壓縮，後來想要加入壓縮演算法，可以通過alter修改schema

4、alter

使用方法：
如修改壓縮演算法

      disable 'table'
      alter 'table',{NAME=>'info',COMPRESSION=>'snappy'} 
      enable 'table'

但是需要執行major_compact 'table' 命令之後才會做實際的操作。

5、TTL

預設是 2147483647 即:Integer.MAX_VALUE 值大概是68年
這個引數是說明該列族資料的存活時間，單位是s
這個引數可以根據具體的需求對資料設定存活時間，超過存過時間的資料將在表中不在顯示，待下次major compact的時候再徹底刪除資料.
注意的是TTL設定之後 MIN_VERSIONS=>’0’ 這樣設定之後，TTL時間戳過期後，將全部徹底刪除該family下所有的資料，如果MIN_VERSIONS 不等於0那將保留最新的MIN_VERSIONS個版本的資料，其它的全部刪除，比如MIN_VERSIONS=>’1’ 屆時將保留一個最新版本的資料，其它版本的資料將不再儲存。

6、describe ‘table’

這個命令查看了create table 的各項引數或者是預設值。

7、disable_all ‘toplist.*’

disable_all 支援正則表示式，並列出當前匹配的表的如下：
toplist_a_total_1001
toplist_a_total_1002
toplist_a_total_1008
toplist_a_total_1009
toplist_a_total_1019
toplist_a_total_1035
…
Disable the above 25 tables (y/n)? 並給出確認提示.

8、drop_all

這個命令和disable_all的使用方式是一樣的

9、hbase 表預分割槽—-手動分割槽

預設情況下，在建立HBase表的時候會自動建立一個region分割槽，當匯入資料的時候，所有的HBase客戶端都向這一個region寫資料，直到這個region足夠大了才進行切分。一種可以加快批量寫入速度的方法是通過預先建立一些空的regions，這樣當資料寫入HBase時，會按照region分割槽情況，在叢集內做資料的負載均衡。
命令方式:

create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

也可以使用api的方式:

bin/hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 15 -f info

引數：

test_table是表名
HexStringSplit 是split 方式
-c 是分15個region
-f 是family

可在Web上檢視結果，如圖：
這裡寫圖片描述

這樣就可以將表預先分為15個區，減少資料達到storefile 大小的時候自動分割槽的時間消耗，並且還有以一個優勢，就是合理設計rowkey 能讓各個region 的併發請求平均分配(趨於均勻) 使IO 效率達到最高，但是預分割槽需要將filesize 設定一個較大的值，hbase.hregion.max.filesize 這個值預設是10G 也就是說單個region 預設大小是10G,
這個引數的預設值在0.90 到0.92到0.94.3各版本的變化：256M–1G–10G
但是如果MapReduce Input型別為TableInputFormat 使用hbase作為輸入的時候，就要注意了，每個region一個map，如果資料小於10G 那隻會啟用一個map 造成很大的資源浪費，這時候可以考慮適當調小該引數的值，或者採用預分配region的方式，並將檢測如果達到這個值，再手動分配region。

行鍵設計

表結構設計

1、列族數量的設定

以使用者資訊為例，可以將必須的基本資訊存放在一個列族，而一些附加的額外資訊可以放在另一列族；

2、行鍵的設計

語音詳單：
13877889988-20150625
13877889988-20150625
13877889988-20150626
13877889988-20150626
—-將需要批量查詢的資料儘可能連續存放
CMS系統—多條件查詢
儘可能將查詢條件關鍵詞拼裝到rowkey中，查詢頻率最高的條件儘量往前靠
20150230-zhangsan-category…
20150230-lisi-category…
Category+20150230 20150230-zhangsan-category
(每一個條件的值長度不同，可以通過做定長對映來提高效率)

Hbase的設計原則

HBase是三維有序儲存的，通過rowkey（行鍵），column key（column family和qualifier）和TimeStamp（時間戳）這個三個維度可以對HBase中的資料進行快速定位。

HBase中rowkey可以唯一標識一行記錄，有以下3種查詢方式：

通過get方式，指定rowkey獲取唯一一條記錄
通過scan方式，設定startRow和stopRow引數進行範圍匹配
全表掃描，即直接掃描整張表中所有行記錄

1、rowkey長度原則

rowkey是一個二進位制碼流，可以是任意字串，最大長度64kb，實際應用中一般為10-100bytes，以byte[]形式儲存，一般設計成定長。
建議越短越好，不要超過16個位元組，原因如下：

資料的持久化檔案HFile中是按照KeyValue儲存的，如果rowkey過長，比如超過100位元組，1000w行資料，光rowkey就要佔用100*1000w=10億個位元組，將近1G資料，這樣會極大影響HFile的儲存效率；
MemStore將快取部分資料到記憶體，如果rowkey欄位過長，記憶體的有效利用率就會降低，系統不能快取更多的資料，這樣會降低檢索效率。

2、rowkey雜湊原則

如果rowkey按照時間戳的方式遞增，不要將時間放在二進位制碼的前面，建議將rowkey的高位作為雜湊欄位，由程式隨機生成，低位放時間欄位，這樣將提高資料均衡分佈在每個RegionServer，以實現負載均衡的機率。如果沒有雜湊欄位，首欄位直接是時間資訊，所有的資料都會集中在一個RegionServer上，這樣在資料檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率。

3、rowkey唯一原則

必須在設計上保證其唯一性，rowkey是按照字典順序排序儲存的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料儲存到一塊，將最近可能會被訪問的資料放到一塊。

熱點問題

HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行存取在臨近位置，便於scan。然而糟糕的rowkey設計是熱點的源頭。

熱點發生在大量的client直接訪問叢集的一個或極少數個節點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起效能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由於主機無法服務其他region的請求。

設計良好的資料訪問模式以使叢集被充分，均衡的利用。為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多資料情況下，資料應該被寫入叢集的多個region，而不是一個。

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

1、加鹽

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

2、雜湊

雜湊會使同一行永遠用一個字首加鹽。雜湊也可以使負載分散到整個叢集，但是讀卻是可以預測的。使用確定的雜湊可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行資料。

3、反轉

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

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

4、時間戳反轉

一個常見的資料處理問題是快速獲取資料的最近版本，使用反轉的時間戳作為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 - 結束時間]

注意：
儘量減少行和列的大小在HBase中，value永遠和它的key一起傳輸的。當具體的值在系統間傳輸時，它的rowkey，列名，時間戳也會一起傳輸。如果你的rowkey和列名很大，甚至可以和具體的值相比較，那麼你將會遇到一些有趣的問題。HBase storefiles中的索引（有助於隨機訪問）最終佔據了HBase分配的大量記憶體，因為具體的值和它的key很大。可以增加block大小使得storefiles索引再更大的時間間隔增加，或者修改表的模式以減小rowkey和列名的大小。壓縮也有助於更大的索引。
列族儘可能越短越好，最好是一個字元。
冗長的屬性名雖然可讀性好，但是更短的屬性名儲存在HBase中會更好。