深度研究hbase的熱點(diǎn)問題，和hbase表rk的設(shè)計(jì)和手動(dòng)分區(qū)region

2019/2/20 星期三

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

十多年的華寧網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。全網(wǎng)整合營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整華寧建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“華寧網(wǎng)站設(shè)計(jì)”,“華寧網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

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

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

創(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熱點(diǎn)問題、數(shù)據(jù)傾斜和rowkey的散列設(shè)計(jì)

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

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

行鍵(RowKey)設(shè)計(jì)

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

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

rowkey散列原則
把主鍵哈希后當(dāng)成rowkey的頭部

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

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

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

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

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

表模式經(jīng)驗(yàn)法則
1、region規(guī)模大小在10到50GB之間；
2、單元的大小不要超過10MB，如果使用 Object Store（在下面介紹） ，可放寬到50MB；不然，可以考慮將單元數(shù)據(jù)存在HDFS中，或者在HBase中存一個(gè)指向這些數(shù)據(jù)的指針；
3、一個(gè)典型的模式每個(gè)表中含有1～3個(gè)列族
4、對于只有1～2個(gè)列族的表，50到100個(gè)region是一個(gè)比較合適的數(shù)量。需要提醒的是，每個(gè)region都是列族的一個(gè)連續(xù)段；
5、列族的名字越短越好，因?yàn)閷γ總€(gè)值（忽略前綴編碼， prefix encoding ），列族名都會(huì)存一次。它們不應(yīng)當(dāng)像典型RDNMS一樣自記錄（ self-documenting ） 和描述。
6、如果在基于時(shí)間的機(jī)器上存儲(chǔ)數(shù)據(jù)或日志信息，行鍵（Row Key）是由設(shè)備ID或2、屬性：詳細(xì)屬性名 (如, "myVeryImportantAttribute") 易讀，最好還是用短屬性名 (e.g., "via") 保存到HBase.
3、行鍵長度：讓行鍵短到可讀即可，這樣對獲取數(shù)據(jù)有幫助(e.g., Get vs. Scan)。短鍵對訪問數(shù)據(jù)無用，并不比長鍵對get/scan更好。設(shè)計(jì)行鍵需要權(quán)衡。
4、字節(jié)模式：long類型有8字節(jié)。8字節(jié)內(nèi)可以保存無符號(hào)數(shù)字到18,446,744,073,709,551,615。 如果用字符串保存——假設(shè)一個(gè)字節(jié)一個(gè)字符——需要將近3倍的字節(jié)數(shù)。

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