深度研究hbase的熱點問題，和hbase 表rk的設計 和手動分區region

2019/2/20 星期三

深度研究hbase的熱點問題，和hbase 表rk的設計 和手動分區region

在2019/1/25 星期五記錄

hbase的熱點問題：

hbase熱點問題解決（預分區） https://blog.csdn.net/qq_31289187/article/details/80869906

Hbase split的三種方式和split的過程 https://www.cnblogs.com/niurougan/p/3976519.html

082 HBase的幾種調優（GC政策，flush，compact，split）http://www.cnblogs.com/juncaoit/p/6170642.html

這上面講解了這些，hbase 指令的使用

081 Region的預分區 https://www.cnblogs.com/juncaoit/p/6170510.html 的4中方法

—————————————————————————————————————————————————

什麼是hbase的熱點問題

出現熱點問題原因

1、hbase的中的資料是按照字典序排序的，當大量連續的rowkey集中寫在個别的region，各個region之間資料分布不均衡；

2、建立表時沒有提前預分區，建立的表預設隻有一個region，大量的資料寫入目前region；

3、建立表已經提前預分區，但是設計的rowkey沒有規律可循，設計的rowkey應該由regionNo+messageId組成。

如何解決熱點問題

解決這個問題，關鍵是要設計出可以讓資料分布均勻的rowkey，與關系型資料庫一樣,rowkey是用來檢索記錄的主鍵。通路hbase table中的行，rowkey 可以是任意字元串(最大長度 是 64KB，實際應用中長度一般為 10-100bytes)，在hbase内部，rowkey儲存為位元組數組，存儲時，資料按照rowkey的字典序排序存儲。

建立表指令：

create 'testTable',{NAME => 'cf', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_SCOPE=> '0', VERSIONS => '1', COMPRESSION => 'snappy', MIN_VERSIONS =>'0', TTL => '15552000', KEEP_DELETED_CELLS => 'false', BLOCKSIZE =>'65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA =>{'ENCODE_ON_DISK' => 'true'}},{SPLITS_FILE=>'/app/soft/test/region.txt'}

https://blog.csdn.net/weixin_41279060/article/details/78855679 hbase系列-Hbase熱點問題、資料傾斜和rowkey的散列設計

預分區和rowkey的散列設計——解決資料傾斜和熱點問題

預分區，讓表的資料可以均衡的分散在叢集中，而不是預設隻有一個region分布在叢集的一個節點上。（預分區個數=節點的倍數，看資料量估算，region不足了會被分列，預分區後每個region的rowkey還是有序的）

如何給hbase表預分區

HBase預分區方法 https://www.cnblogs.com/quchunhui/p/7543385.html *****

Hbase 表的設計原則 ————總結 https://blog.csdn.net/m0_37138008/article/details/78985946

行鍵(RowKey)設計

HBase的行由行鍵按字典順序排序，這樣的設計優化了掃描，允許存儲相關的行或者那些将被一起讀的鄰近的行。

然而，設計不好的行鍵是導緻hots potting（熱點問題）的常見原因。當大量的用戶端流量（ traffic ）被定向在叢集上的一個或幾個節點時，就會發生hots potting。這些流量可能代表着讀、寫或其他操作。流量超過了承載該region的單個機器所能負荷的量，這就會導緻性能下降并有可能造成region的不可用。在同一RegionServer上的其他region也可能會受到其不良影響，因為主機無法提供服務所請求的負載。設計使叢集能被充分均勻地使用的資料通路模式是至關重要的。

預分區

一個RegionServer能管理10-1000個Region，0.92.x版本後，預設的Region大小為10G，向下可以支援256MB，向上可以支援到20G，也就是說，每個RegionServer能管理的資料量為2.5GB-20TB。

如果有5個節點，3年内資料量為5T，那麼分區數可以預設為：

5000G/10G=500個region

這500個Region就會被均衡的分布在叢集各個節點上（具體分布看機器的性能和存儲空間而定），機器硬碟不足可以添加硬碟，性能不足可以添加新節點（添加新機器）。

Rowkey長度原則（最好不超過16位元組）

Rowkey是一個二進制碼流，Rowkey的長度被很多開發者建議說設計在10~100個位元組，不過建議是越短越好，不要超過16個位元組。

原因如下：

（1）資料的持久化檔案HFile中是按照KeyValue存儲的，如果Rowkey過長比如100個位元組，1000萬列資料光Rowkey就要占用100*1000萬=10億個位元組，将近1G資料，這會極大影響HFile的存儲效率；

（2）MemStore将緩存部分資料到記憶體，如果Rowkey字段過長記憶體的有效使用率會降低，系統将無法緩存更多的資料，這會降低檢索效率。是以Rowkey的位元組長度越短越好。

（3）目前作業系統是都是64位系統，記憶體8位元組對齊。控制在16個位元組，8位元組的整數倍利用作業系統的最佳特性。

rowkey散列原則

把主鍵哈希後當成rowkey的頭部

rowkey唯一原則

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

時間戳反轉

如果資料需要保留多個版本，可以使用反轉的時間戳作為rowkey的一部分，用 Long.Max_Value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最後錄入的資料。

整個rowkey（timestamp并不是必要的，視業務而定）

rowkey=哈希（主鍵<遞增的id\手機号碼等>）+Long.Max_Value - timestamp

作者：boat824109722

來源：CSDN

原文：https://blog.csdn.net/weixin_41279060/article/details/78855679

版權聲明：本文為部落客原創文章，轉載請附上博文連結！

rk設計小結1：

1、首先先規劃hbase表的大小，計算規劃出合理的region數

2、rk長度設計（最好不超過16位元組）

3、rk散列原則（把主鍵哈希後當成rk的頭部，這裡的散列了解為字首指派的随機數添加到rk前面）

4、rk唯一原則（将經常讀取的資料放在一起，将最近可能被通路的資料放在一個塊）

5、版本數為3合理，如果過期資料不是很重要的話。

行鍵rk的設計小結2：

設計行鍵時應該使得資料盡量同時往多個region上寫，而避免隻向一個region寫（避免hbase的熱點問題），可用用字首指派的随機數添加到rk的前面，這樣就可以分散到不同的region中（salting），使用了順序的key會将本沒有順序的資料變得有順序，把負載壓在一台機器上。是以要盡量避免時間戳或者序列(e.g. 1, 2, 3)這樣的行鍵。（減少單調遞增行鍵/時序資料）。