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

2019/2/20 星期三

深度研究hbase的熱點問題，和hbase 表rk的設計 和手動分區(qū)region
在2019/1/25 星期五記錄
hbase的熱點問題：
hbase熱點問題解決（預分區(qū)） https://blog.csdn.net/qq_31289187/article/details/80869906
Hbase split的三種方式和split的過程 https://www.cnblogs.com/niurougan/p/3976519.html

082 HBase的幾種調(diào)優(yōu)（GC策略，flush，compact，split）http://www.cnblogs.com/juncaoit/p/6170642.html
這上面講解了這些，hbase 命令的使用
081 Region的預分區(qū) https://www.cnblogs.com/juncaoit/p/6170510.html 的4中方法
—————————————————————————————————————————————————
什么是hbase的熱點問題
出現(xiàn)熱點問題原因
1、hbase的中的數(shù)據(jù)是按照字典序排序的，當大量連續(xù)的rowkey集中寫在個別的region，各個region之間數(shù)據(jù)分布不均衡；
2、創(chuàng)建表時沒有提前預分區(qū)，創(chuàng)建的表默認只有一個region，大量的數(shù)據(jù)寫入當前region；
3、創(chuàng)建表已經(jīng)提前預分區(qū)，但是設計的rowkey沒有規(guī)律可循，設計的rowkey應該由regionNo+messageId組成。

如何解決熱點問題
解決這個問題，關鍵是要設計出可以讓數(shù)據(jù)分布均勻的rowkey，與關系型數(shù)據(jù)庫一樣,rowkey是用來檢索記錄的主鍵。訪問hbase table中的行，rowkey 可以是任意字符串(最大長度 是 64KB，實際應用中長度一般為 10-100bytes)，在hbase內(nèi)部，rowkey保存為字節(jié)數(shù)組，存儲時，數(shù)據(jù)按照rowkey的字典序排序存儲。

創(chuàng)建表命令：
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熱點問題、數(shù)據(jù)傾斜和rowkey的散列設計

預分區(qū)和rowkey的散列設計——解決數(shù)據(jù)傾斜和熱點問題
預分區(qū)，讓表的數(shù)據(jù)可以均衡的分散在集群中，而不是默認只有一個region分布在集群的一個節(jié)點上。（預分區(qū)個數(shù)=節(jié)點的倍數(shù)，看數(shù)據(jù)量估算，region不足了會被分列，預分區(qū)后每個region的rowkey還是有序的）

如何給hbase表預分區(qū)
HBase預分區(qū)方法 https://www.cnblogs.com/quchunhui/p/7543385.html *****
Hbase 表的設計原則 ————總結(jié) https://blog.csdn.net/m0_37138008/article/details/78985946

行鍵(RowKey)設計

HBase的行由行鍵按字典順序排序，這樣的設計優(yōu)化了掃描，允許存儲相關的行或者那些將被一起讀的鄰近的行。
然而，設計不好的行鍵是導致hots potting（熱點問題）的常見原因。當大量的客戶端流量（ traffic ）被定向在集群上的一個或幾個節(jié)點時，就會發(fā)生hots potting。這些流量可能代表著讀、寫或其他操作。流量超過了承載該region的單個機器所能負荷的量，這就會導致性能下降并有可能造成region的不可用。在同一RegionServer上的其他region也可能會受到其不良影響，因為主機無法提供服務所請求的負載。設計使集群能被充分均勻地使用的數(shù)據(jù)訪問模式是至關重要的。

預分區(qū)和rowkey的散列設計——解決數(shù)據(jù)傾斜和熱點問題
預分區(qū)
預分區(qū)，讓表的數(shù)據(jù)可以均衡的分散在集群中，而不是默認只有一個region分布在集群的一個節(jié)點上。（預分區(qū)個數(shù)=節(jié)點的倍數(shù)，看數(shù)據(jù)量估算，region不足了會被分列，預分區(qū)后每個region的rowkey還是有序的）
一個RegionServer能管理10-1000個Region，0.92.x版本后，默認的Region大小為10G，向下可以支持256MB，向上可以支持到20G，也就是說，每個RegionServer能管理的數(shù)據(jù)量為2.5GB-20TB。
如果有5個節(jié)點，3年內(nèi)數(shù)據(jù)量為5T，那么分區(qū)數(shù)可以預設為：
5000G/10G=500個region
這500個Region就會被均衡的分布在集群各個節(jié)點上（具體分布看機器的性能和存儲空間而定），機器硬盤不足可以添加硬盤，性能不足可以添加新節(jié)點（添加新機器）。
Rowkey長度原則（最好不超過16字節(jié)）
Rowkey是一個二進制碼流，Rowkey的長度被很多開發(fā)者建議說設計在10~100個字節(jié)，不過建議是越短越好，不要超過16個字節(jié)。
原因如下：
（1）數(shù)據(jù)的持久化文件HFile中是按照KeyValue存儲的，如果Rowkey過長比如100個字節(jié)，1000萬列數(shù)據(jù)光Rowkey就要占用100*1000萬=10億個字節(jié)，將近1G數(shù)據(jù)，這會極大影響HFile的存儲效率；
（2）MemStore將緩存部分數(shù)據(jù)到內(nèi)存，如果Rowkey字段過長內(nèi)存的有效利用率會降低，系統(tǒng)將無法緩存更多的數(shù)據(jù)，這會降低檢索效率。因此Rowkey的字節(jié)長度越短越好。
（3）目前操作系統(tǒng)是都是64位系統(tǒng)，內(nèi)存8字節(jié)對齊。控制在16個字節(jié)，8字節(jié)的整數(shù)倍利用操作系統(tǒng)的最佳特性。

rowkey散列原則
把主鍵哈希后當成rowkey的頭部

rowkey唯一原則
必須在設計上保證其唯一性，rowkey是按照字典順序排序存儲的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經(jīng)常讀取的數(shù)據(jù)存儲到一塊，將最近可能會被訪問的數(shù)據(jù)放到一塊。
時間戳反轉(zhuǎn)
如果數(shù)據(jù)需要保留多個版本，可以使用反轉(zhuǎn)的時間戳作為rowkey的一部分，用 Long.Max_Value - timestamp 追加到key的末尾，例如 [key][reverse_timestamp] , [key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的數(shù)據(jù)。

整個rowkey（timestamp并不是必要的，視業(yè)務而定）
rowkey=哈希（主鍵<遞增的id\手機號碼等>）+Long.Max_Value - timestamp

作者：boat824109722
來源：CSDN
原文：https://blog.csdn.net/weixin_41279060/article/details/78855679
版權聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！

rk設計小結(jié)1：
1、首先先規(guī)劃hbase表的大小，計算規(guī)劃出合理的region數(shù)
2、rk長度設計（最好不超過16字節(jié)）
3、rk散列原則（把主鍵哈希后當成rk的頭部，這里的散列理解為前綴指派的隨機數(shù)添加到rk前面）
4、rk唯一原則（將經(jīng)常讀取的數(shù)據(jù)放在一起，將最近可能被訪問的數(shù)據(jù)放在一個塊）
5、版本數(shù)為3合理，如果過期數(shù)據(jù)不是很重要的話。

行鍵rk的設計小結(jié)2：
設計行鍵時應該使得數(shù)據(jù)盡量同時往多個region上寫，而避免只向一個region寫（避免hbase的熱點問題），可用用前綴指派的隨機數(shù)添加到rk的前面，這樣就可以分散到不同的region中（salting），使用了順序的key會將本沒有順序的數(shù)據(jù)變得有順序，把負載壓在一臺機器上。所以要盡量避免時間戳或者序列(e.g. 1, 2, 3)這樣的行鍵。（減少單調(diào)遞增行鍵/時序數(shù)據(jù)）。

表模式經(jīng)驗法則
1、region規(guī)模大小在10到50GB之間；
2、單元的大小不要超過10MB，如果使用 Object Store（在下面介紹） ，可放寬到50MB；不然，可以考慮將單元數(shù)據(jù)存在HDFS中，或者在HBase中存一個指向這些數(shù)據(jù)的指針；
3、一個典型的模式每個表中含有1～3個列族
4、對于只有1～2個列族的表，50到100個region是一個比較合適的數(shù)量。需要提醒的是，每個region都是列族的一個連續(xù)段；
5、列族的名字越短越好，因為對每個值（忽略前綴編碼， prefix encoding ），列族名都會存一次。它們不應當像典型RDNMS一樣自記錄（ self-documenting ） 和描述。
6、如果在基于時間的機器上存儲數(shù)據(jù)或日志信息，行鍵（Row Key）是由設備ID或服務器ID加上時間得到的，那最后能得到這樣的模式：除了某個特定的時間段，舊的數(shù)據(jù)region沒有額外的寫。在這種情況下，得到的是少量的活躍region和大量的沒有新寫入的舊region。這時由于資源消耗僅來自于活躍的region，大量的region能被容納接受；

大部分時候，細微的低效不會影響很大。但不幸的是，在這里卻不能忽略。無論是列族、屬性和行鍵都會在數(shù)據(jù)中重復上億次。
1、列族：盡量使列族名小，最好一個字符。(如 "d" 表示 data/default).
2、屬性：詳細屬性名 (如, "myVeryImportantAttribute") 易讀，最好還是用短屬性名 (e.g., "via") 保存到HBase.
3、行鍵長度：讓行鍵短到可讀即可，這樣對獲取數(shù)據(jù)有幫助(e.g., Get vs. Scan)。短鍵對訪問數(shù)據(jù)無用，并不比長鍵對get/scan更好。設計行鍵需要權衡。
4、字節(jié)模式：long類型有8字節(jié)。8字節(jié)內(nèi)可以保存無符號數(shù)字到18,446,744,073,709,551,615。 如果用字符串保存——假設一個字節(jié)一個字符——需要將近3倍的字節(jié)數(shù)。

行鍵永遠不變：行鍵不能改變。唯一可以“改變”的方式是刪除然后再插入。這是一個常問問題，所以要注意開始就要讓行鍵正確(且/或在插入很多數(shù)據(jù)之前)。