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
—————————————————————————————————————————————————
什麼是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也可能會受到其不良影響，因爲主機無法提供服務所請求的負載。設計使集羣能被充分均勻地使用的數據訪問模式是至關重要的。
預分區和rowkey的散列設計——解決數據傾斜和熱點問題
預分區
預分區，讓表的數據可以均衡的分散在集羣中，而不是默認只有一個region分佈在集羣的一個節點上。（預分區個數=節點的倍數，看數據量估算，region不足了會被分列，預分區後每個region的rowkey還是有序的）
一個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)這樣的行鍵。（減少單調遞增行鍵/時序數據）。
表模式經驗法則
1、region規模大小在10到50GB之間；
2、單元的大小不要超過10MB，如果使用 Object Store（在下面介紹） ，可放寬到50MB；不然，可以考慮將單元數據存在HDFS中，或者在HBase中存一個指向這些數據的指針；
3、一個典型的模式每個表中含有1～3個列族
4、對於只有1～2個列族的表，50到100個region是一個比較合適的數量。需要提醒的是，每個region都是列族的一個連續段；
5、列族的名字越短越好，因爲對每個值（忽略前綴編碼， prefix encoding ），列族名都會存一次。它們不應當像典型RDNMS一樣自記錄（ self-documenting ） 和描述。
6、如果在基於時間的機器上存儲數據或日誌信息，行鍵（Row Key）是由設備ID或服務器ID加上時間得到的，那最後能得到這樣的模式：除了某個特定的時間段，舊的數據region沒有額外的寫。在這種情況下，得到的是少量的活躍region和大量的沒有新寫入的舊region。這時由於資源消耗僅來自於活躍的region，大量的region能被容納接受；
大部分時候，細微的低效不會影響很大。但不幸的是，在這裏卻不能忽略。無論是列族、屬性和行鍵都會在數據中重複上億次。
1、列族：儘量使列族名小，最好一個字符。(如 "d" 表示 data/default).
2、屬性：詳細屬性名 (如, "myVeryImportantAttribute") 易讀，最好還是用短屬性名 (e.g., "via") 保存到HBase.
3、行鍵長度：讓行鍵短到可讀即可，這樣對獲取數據有幫助(e.g., Get vs. Scan)。短鍵對訪問數據無用，並不比長鍵對get/scan更好。設計行鍵需要權衡。
4、字節模式：long類型有8字節。8字節內可以保存無符號數字到18,446,744,073,709,551,615。 如果用字符串保存——假設一個字節一個字符——需要將近3倍的字節數。
行鍵永遠不變：行鍵不能改變。唯一可以“改變”的方式是刪除然後再插入。這是一個常問問題，所以要注意開始就要讓行鍵正確(且/或在插入很多數據之前)。