hbase 集群規劃（集群業務規劃，集群容量規劃，Region規劃）

//hbase集群業務規劃，集群容量規劃，Region規劃，
引出問題：
1、一個集群上面到底應該運行哪些業務可以最大程度上利用系統的軟硬件資源？
2、另外，對于一個給定業務來說，應該如何規劃集群的硬件容量才能使得資源不浪費？
3、最后，一個給定的RegionServer上到底部署多少Region比較合適？想必這些問題都曾經困惑過很多HBaser，

集群業務規劃
1、一個HBase集群上很少只跑一個業務，大多數情況都是多個業務共享集群，實際上就是共享系統軟硬件資源。
2、其一是業務之間資源隔離問題，就是將各個業務在邏輯上隔離開來，互相不受影響，這個問題產生于業務共享場景下一旦某一業務一段時間內流量猛增必然會因為過度消耗系統資源而影響其他業務；
3、其二就是共享情況下如何使得系統資源利用率最高，理想情況下當然希望集群中所有軟硬件資源都得到最大程度利用。

使得集群系統資源最大化利用，那首先要看業務對系統資源的需求情況。
1、硬盤容量敏感型業務
//這類業務對讀寫延遲以及吞吐量都沒有很大的要求，唯一的需要就是硬盤容量。
//上層應用一般每隔一段時間批量寫入大量數據，然后讀取也是定期批量讀取大量數據。
//特點：離線寫、離線讀，需求硬盤容量
2、帶寬敏感型業務
//這類業務大多數寫入吞吐量很大，但對讀取吞吐量沒有什么要求。比如日志實時存儲業務，
//上層應用通過kafka將海量日志實時傳輸過來，要求能夠實時寫入，而讀取場景一般是離線分析或者在上次業務遇到異常的時候對日志進行檢索。
//特點：在線寫、離線讀，需求帶寬 （elk+kafka）
3、io敏感性業務
//IO敏感型業務一般都是較為核心的業務。
//這類業務對讀寫延遲要求較高，尤其對于讀取延遲通常在100ms以內，部分業務可能要求更高。
//比如在線消息存儲系統、歷史訂單系統、實時推薦系統等。
//特點：在（離）線寫、在線讀，需求內存、高IOPS介質

提示：
而對于CPU資源，HBase本身就是CPU敏感型系統，主要用于數據塊的壓縮/解壓縮，所有業務都對CPU有共同的需求

小結：
1、一個集群想要資源利用率最大化，一個思路就是各個業務之間‘揚長避短’，合理搭配，各取所需。
2、實際上就是上述幾種類型的業務能夠混合分布，建議不要將同一種類型的業務太多分布在同一個集群。
3、因此一個集群理論上資源利用率比較高效的配置為：硬盤敏感型業務 ＋ 帶寬敏感型業務 ＋ IO敏感型業務。
4、建議將核心業務和非核心業務分布在同一個集群，強烈建議不要將太多核心業務同時分布在同一個集群。（考慮到運維方面）
//核心業務共享資源一定會產生競爭（無論哪個落敗，都不是我們希望看見的），在一定的時候，為了保證核心業務的平穩處理，在資源共享的情況下只能犧牲其他非核心業務，甚至是關閉非核心業務。
弊端：這樣的業務設計會產生很多小集群，很多人會采用資源隔離 rsgroup 進行業務資源隔離的集群（來減少小集群的數量），大集群通過隔離會將業務獨立分布到很多獨立的RS上，這樣實際上就產生了很多邏輯上的小集群，那么，這些小集群同樣適用上面提出的規劃思路。

集群容量的規劃 //重點

假如現在一臺RegionServer的硬盤規格是3.6T * 12，總內存大小為128G，從理論上來說這樣的配置是否會有資源浪費？如果有的話是硬盤浪費還是內存浪費？那合理的硬盤/內存搭配應該是什么樣？和哪些影響因素有關？

這里需要提出一個’Disk / Java Heap Ratio’的概念，意思是說一臺RegionServer上1bytes的Java內存大小需要搭配多大的硬盤大小最合理。在給出合理的解釋在前，先把結果給出來：

Disk Size / Java Heap = RegionSize / MemstoreSize ReplicationFactor HeapFractionForMemstore * 2

按照默認配置，RegionSize = 10G，對應參數為hbase.hregion.max.filesize；MemstoreSize = 128M，對應參數為hbase.hregion.memstore.flush.size；ReplicationFactor = 3，對應參數為dfs.replication；HeapFractionForMemstore = 0.4，對應參數為hbase.regionserver.global.memstore.lowerLimit；

10G=10 1024M 1024B 1024b
———————————————————————— 30.42=192b
128M=1281024B1024b

計算為：10G / 128M 3 0.4 2 = 192，意思是說RegionServer上1bytes的Java內存大小需要搭配192bytes的硬盤大小最合理，再回到之前給出的問題，128G的內存總大小，拿出96G作為Java內存用于RegionServer（這里有個公式就是RS內存為系統內存的2/3 1282/3約等于85.4，rs內存為系統內存的3/4 128*3/4 = 96G 還有一種情況是，留給固定系統內存為32G, 剩余的都給rs內存我本人比較傾向于 當內存大的情況下給系統內存為32G，內存小的時候，可以分配介于2/3~3/4之間），那對應需要搭配96G ＊ 192 = 18T硬盤容量，而實際采購機器配置的是36T，說明在默認配置條件下會有幾乎一半硬盤被浪費。

提示：
cdh中
hbase.regionserver.global.memstore.lowerLimit = 0.95 默認值 0.95
//flush算法會首先按照Region大小進行排序，再按照該順序依次進行flush，直至總Memstore大小低至lowerlimit。
10G=101024M1024B1024b
———————————————————————— 30.952=456b
128M=1281024B1024b
按照cdh默認配置是算法的話 96G * 465 = 43T
注意：當我們在cdh中設置
Memstore 刷新的低水位線
hbase.regionserver.global.memstore.size.lower.limit,
hbase.regionserver.global.memstore.lowerLimit = 0.4 的話，cdh出現警告：
Setting Memstore 刷新的低水位線 to 0.9 or lower can cause performance issues due to under-utilization of available memory.//將Memstore刷新的低水位線設置為0.9或更低可能會因可用內存利用不足而導致性能問題。 當我們內存大的話，遵循：
hbase.regionserver.global.memstore.lowerLimit，一般lowerLimit比upperLimit小5%。
有些參數需要在大內存下進行測試
當我在設置成
hbase.regionserver.global.memstore.upperLimit設置為0.45，
hbase.regionserver.global.memstore.lowerLimit設置為0.40

出現報錯為：
Exception in thread "main" java.lang.RuntimeException: Current heap configuration for MemStore and BlockCache exceeds the threshold required for successful cluster operation. The combined value cannot exceed 0.8. Please check the settings for hbase.regionserver.global.memstore.size and hfile.block.cache.size in your configuration. hbase.regionserver.global.memstore.size is 0.45 hfile.block.cache.size is 0.4
    at org.apache.hadoop.hbase.io.util.HeapMemorySizeUtil.checkForClusterFreeMemoryLimit(HeapMemorySizeUtil.java:85)
    at org.apache.hadoop.hbase.HBaseConfiguration.addHbaseResources(HBaseConfiguration.java:82)
    at org.apache.hadoop.hbase.HBaseConfiguration.create(HBaseConfiguration.java:96)
    at org.apache.hadoop.hbase.regionserver.HRegionServer.main(HRegionServer.java:2716)

意思是說：
MemStore和BlockCache的當前堆配置超出了成功集群操作所需的閾值。 合并值不能超過0.8。 請檢查配置中hbase.regionserver.global.memstore.size和hfile.block.cache.size的設置。 hbase.regionserver.global.memstore.size為0.45 hfile.block.cache.size為0.4
也就是 說
HFile 塊緩存大小
hfile.block.cache.size = 0.4 默認
hbase.regionserver.global.memstore.upperLimit = 0.4 默認
但是HBase的硬規定卻是按照這個參數計算的，這個參數的值加上hbase.regionserver.global.memstore.upperLimit的值不能大于0.8，上文提到hbase.regionserver.global.memstore.upperLimit值設置為0.4，因此，hfile.block.cache.size必須設置為一個小于0.14的任意值。
//實際操作為：
hbase.regionserver.global.memstore.upperLimit = 0.45
hbase.regionserver.global.memstore.lowerLimit = 0.4
hfile.block.cache.size + hbase.regionserver.global.memstore.upperLimi 不能大于0.8
hfile.block.cache.size = 0.35
成功
以上這個問題，hbase內存規劃（讀多寫少型和寫多讀少型） 中的案例二：讀多寫少型 + BucketCache
https://blog.51cto.com/12445535/2373788

上面的計算公式怎么來的？
其實很簡單，只需要從硬盤容量緯度和Java Heap緯度兩方面計算Region個數，再令兩者相等就可以推導出來，如下：
硬盤容量緯度下Region個數：Disk Size / (RegionSize ＊ReplicationFactor)
Java Heap緯度下Region個數：Java Heap HeapFractionForMemstore / (MemstoreSize / 2 )
Disk Size / (RegionSize ＊ReplicationFactor) ＝ Java Heap HeapFractionForMemstore / (MemstoreSize / 2 )
＝> Disk Size / Java Heap = RegionSize / MemstoreSize ReplicationFactor HeapFractionForMemstore * 2

這樣的公式有什么具體意義？

1. 最直觀的意義就是判斷在當前給定配置下是否會有資源浪費，內存資源和硬盤資源是否匹配。
2. 那反過來，如果已經給定了硬件資源，比如硬件采購部已經采購了當前機器內存128G，分配給Java Heap為96G，而硬盤是40T，很顯然兩者是不匹配的，那能不能通過修改HBase配置來使得兩者匹配？當然可以，可以通過增大RegionSize或者減少MemstoreSize來實現，比如將默認的RegionSize由10G增大到20G，此時Disk Size / Java Heap ＝ 384，96G * 384 = 36T，基本就可以使得硬盤和內存達到匹配。//如果不匹配的話，就要去調整【增大RegionSize或者減少MemstoreSize來實現】
3. 另外，如果給定配置下內存硬盤不匹配，那實際場景下內存’浪費’好呢還是硬盤’浪費’好？答案是內存’浪費’好，比如采購的機器Java Heap可以分配到126G，而總硬盤容量只有18T，默認配置下必然是Java Heap有浪費，但是可以通過修改HBase配置將多余的內存資源分配給HBase讀緩存BlockCache，這樣就可以保證Java Heap并沒有實際浪費。

另外，還有這些資源需要注意…
帶寬資源：
1、因為HBase在大量scan以及高吞吐量寫入的時候特別耗費網絡帶寬資源，
2、強烈建議HBase集群部署在萬兆交換機機房，單臺機器最好也是萬兆網卡＋bond。
3、如果特殊情況交換機是千兆網卡，一定要保證所有的RegionServer機器部署在同一個交換機下，跨交換機會導致寫入延遲很大，嚴重影響業務寫入性能。

CPU資源：
1、HBase是一個CPU敏感型業務，無論數據寫入讀取，都會因為大量的壓縮解壓操作，特別耗費計算資源。因此對于HBase來說，CPU越多越好。
參考：
http://hadoop-hbase.blogspot.com/2013/01/hbase-region-server-memory-sizing.html

Region規劃

1、Region規劃主要涉及到兩個方面：Region個數規劃以及單Region大小規劃，這兩個方面并不獨立，而是相互關聯的，
2、大Region對應的Region個數少，小Region對應的Region個數多。
3、Region規劃相信是很多HBase運維同學比較關心的問題，一個給定規格的RegionServer上運行多少Region比較合適，在剛開始接觸HBase的時候，這個問題也一直困擾著筆者。在實際應用中，Region太多或者太少都有一定的利弊：
大量小Region：
優點：

1. 更加有利于集群之間負載分布
2. 有利于高效平穩的Compaction，這是因為小Region中HFile相對較小，Compaction代價小，詳情可見：Stripe Compaction http://hbasefly.com/2016/07/25/hbase-compaction-2/
   缺點：
3. 最直接的影響：在某臺RegionServer異常宕機或者重啟的情況下大量小Region重分配以及遷移是一個很耗時的操作，一般一個Region遷移需要1.5s～2.5s左右，Region個數越多，遷移時間越長。直接導致failover時間很長。
4. 大量小Region有可能會產生更加頻繁的flush，產生很多小文件，進而引起不必要的Compaction。特殊場景下，一旦Region數超過一個閾值，將會導致整個RegionServer級別的flush，嚴重阻塞用戶讀寫。
5. RegionServer管理維護開銷很大

少量大Region：
優點：

1. 有利于RegionServer的快速重啟以及宕機恢復
2. 可以減少總的RCP數量
3. 有利于產生更少的、更大的flush
   缺點：
4. Compaction效果很差，會引起較大的數據寫入抖動，穩定性較差
5. 不利于集群之間負載均衡

小結：
//可以看出來，在HBase當前工作模式下，Region太多或者太少都不是一件太好的事情，在實際線上環境需要選擇一個折中點。官方文檔給出的一個推薦范圍在20～200之間，而單個Region大小控制在10G~30G，比較符合實際情況。 （我們建議region個數在100個，region大小在20G）
//HBase并不能直接配置一臺RegionServer上的Region數，Region數最直接取決于RegionSize的大小配置hbase.hregion.max.filesize，HBase認為，一旦某個Region的大小大于配置值，就會進行分裂。
//可見，對于當下的HBase，如果想讓HBase工作的更加平穩（Region個數控制在20～200之間，單Region大小控制在10G~30G之間），最多可以存儲的數據量差不多為200 * 30G ＊ 3＝ 18T。如果存儲的數據量超過18T，必然會引起或多或少的性能問題。所以說，從Region規模這個角度講，當前單臺RegionServer能夠合理利用起來的硬盤容量上限基本為18T。

提示：
公式：
Disk Size / Java Heap = RegionSize / MemstoreSize ReplicationFactor HeapFractionForMemstore * 2

hbase.hregion.max.filesize默認為10G，如果一臺RegionServer預期運行100個Region，那單臺RegionServer上數據量預估值就為：10G 100 3 = 3T。反過來想，如果一臺RegionServer上想存儲12T數據量，那按照單Region為10G計算，就會分裂出400個Region，很顯然不合理。此時就需要調整參數hbase.hregion.max.filesize，將此值適度調大，調整為20G或者30G。而實際上當下單臺物理機所能配置的硬盤越來越大，比如36T已經很普遍，如果想把所有容量都用來存儲數據，依然假設一臺RegionServer上分布100個Region，那么每個Region的大小將會達到可怕的120G，一旦執行Compaction將會是一個災難。

未來新概念： Sub-Region
問題：然而隨著硬件成本的不斷下降，單臺RegionServer可以輕松配置40T＋的硬盤容量，如果按照上述說法，越來越多的硬盤其實只是’鏡中月，水中花’。
1、社區也意識到了這樣的問題，在當前Region的概念下提出了Sub-Region的概念
2、可以簡單理解為將當前的Region切分為很多邏輯上小的Sub-Region。
3、Region還是以前的Region，只是所有之前以Region為單位進行的Compaction將會以更小的Sub-Region粒度執行
4、這樣，單Region就可以配置的很大，比如50G、100G，此時單臺RegionServer上也就可以存儲更多的數據。
5、個人認為Sub-Region功能將會是HBase開發的一個重點。

小伙伴問的問題1：
非常好的博文； 對于 集群中服務器性能差距比較大的問題您那邊有什么解決方案嗎？ 集群中有物理機（64個核心），有虛擬機（2核心），能不能達到讓物理機承擔的region個數是虛擬承擔region個數的32倍，默認情況下各個regionserver承擔的region個數會趨向于一致, x謝謝
答：
目前沒有什么特別好的辦法 只能禁用自動balance 手動遷移region～

小伙伴的問題2：
作者你好，這個公式Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 ) ，為什么MemstoreSize / 2？
答：
一般認為Memstore只有一半空間充滿~
問
感謝回復，還想請教下，“一半”這個值是怎么得到的，對應hbase的某個配置參數還是根據平時使用經驗估計的。
另外，我們現在設備大概9T硬盤，Hbase Java Heap = 64G，寫多讀少場景
hbase.regionserver.global.memstore.size = 0.5
hbase.regionserver.global.memstore.size.lower.limit = 0.45
hfile.block.cache.size = 0.25
hbase.hregion.memstore.flush.size = 256M
hbase.hregion.memstore.block.multiplier = 8
hbase.hregion.max.filesize = 15G //replicate=3，最多200region
這些參數這么配置合適嗎？
答：
硬盤相對來說有點小 在這樣的硬盤大小下RegionSize為15G，3副本，200個Region就9T數據 建議預留一定的硬盤 所以hbase.hregion.max.filesize = 10G可能會比較合適

多謝，我們設備硬盤有10T，已經預留了~

小伙伴的問題3
感謝您的分享，關于集群中磁盤陣列使用什么模式比較合適呢？JBOD 還是RAID 0 或者是其他的，怎么評估？
答：
HBase磁盤陣列模式選擇理論上取決于Hadoop磁盤陣列模式 通常Hadoop可能會傾向于選擇JBOD 可以參考：http://zh.hortonworks.com/blog/why-not-raid-0-its-about-time-and-snowflakes/

為什么hdfs集群需要選擇 JBOD磁盤陣列模式。
有兩點原因：

1. 壞盤影響：如果是RAID 0，一旦某個盤壞掉，需要卸載這個盤，而且必須要重新掛載一個新盤上去才能恢復讀寫，不然整個DN就需要從集群踢掉；而如果是JBOD，一旦某個盤壞掉，只需要卸載這個盤，集群就能自動檢測到并恢復正常
2. 長尾效應：RAID 0場景下讀寫性能基本取決于最差的一塊盤的讀寫性能，這個可能會有一些影響
   當然實際操作中具體選擇JBOD還是RAID 0需要結合公司提供的方案來定 個人覺得RAID 0短期來看更有性能優勢 長遠來看JBOD可能會更好
   再問：
   我們每臺RegionServer 掛載的硬盤是10T ，目前采用的是RAI 0磁盤陣列，數據冷熱程度隨著時間越來越冷并且為寫多讀少的場景。由于種種原因公司使用的是千兆網卡，現在極其擔心某個RegionServer 掛掉，造成整個集群資源帶寬不夠。這個場景是不是更適合JBOD 而不是RAID 0 ？JBOD 會不會成為寫入的性能瓶頸呢。
   答：
3. 一個RegionServer掛掉可能會導致集群資源不夠 而且在千兆網卡條件下寫性能以及scan性能都有可能帶寬瓶頸 不過這個場景和JBOD以及RAID 0沒關系 。
4. 所有磁盤組成RAID 0會有一個問題，就是如果一塊盤性能不好或者性能下降可能會導致scan性能下降，還有就是壞盤影響。
5. 寫入通常會將單臺RS上的所有硬盤帶寬都充分利用，通俗講就是所有盤都在寫，所以RAID 0條帶化對性能提升帶來的優化并不明顯，所以JBOD不會成為寫入性能瓶頸
   再問：
   JBOD能否發揮多盤并發寫入性能呢？每塊盤單獨做RAID 0不知道是不是更好，”壞盤影響”是不是也會存在？
   答：
   每塊盤單獨做RAID 0也可以的

小伙伴的問題4：
樓主，你好，如果hbase.hregion.max.filesize設置太小，那么region的分裂幾率就增大了，而分裂是比較消耗資源的，進而會影響到hbase實時寫入的性能；所以在我的集群上我把hbase.hregion.max.filesize設置的非常大，有100-300g大小，這樣大小是我評估了我總存儲量，然后在表格里設置預分區，這樣regionsize* regionnum=allsize(總存儲量)；而且我設置了hbase.hregion.majorcompaction=0，這樣雖然避免了頻繁的split與major,但是你的博客中“那么每個Region的大小將會達到可怕的120G，一旦執行Compaction將會是一個災難”，這句話是指major的合并么?我現在還沒有手動major,準備挑在周末去major table 試一下，不知道會不會出現啥問題？再詢問一下，像這種要存儲的數據量比較大，而且要實時入庫的，除了設置hbase.hregion.max.filesize避免分裂與合并，還有什么好方法么？
答：
這么大的region執行compaction會消耗大量的io資源和帶寬資源，對系統讀寫有很大的影響。分裂對寫入為什么會有影響？
//合并對讀寫都有影響，分裂split對寫入沒有影響的
再問：
我現在要做的是實時入庫,我采用了flume+kafka+sparkstreaming入庫hbase,每10秒一個bach,如果hbase表格正在做split或者major compaction,在region出現兩種情況的同時，我的bach就會變慢，一般我的bach是5-6秒，但是在上面兩種情況下，我的bach要跑1到2分鐘才能跑完，而且沒兩分鐘就出現一次，這樣我streaming就永遠也追不上來了，數據入庫延遲越來越大。。我解決上面慢的問題就是這篇csdn的博客上解決的，https://blog.csdn.net/imgxr/article/details/80130456，好像也是您的博客？如果我開啟自動split,與major compaction也能實時入庫么？
答：
//自動split可以開的，不過需要做好預分區和rowkey散列；major compaction建議手動執行；

小伙伴的問題5：
Java Heap緯度下Region個數：Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 )
對這個2感覺比較疑惑，請問下這個2代表的含義？
答 ：
除以2表示memstore平均只使用到一半，沒有用滿

小伙伴的問題6：
一個hbase集群，對于表的個數不限定吧，反正只要所有表總的region的個數推薦范圍在20～200之間，而單個Region大小控制在10G~30G，就可以是吧？
答：
對表沒有限定

小伙伴的問題6：
我發現HBase有一個Replication機制 ，這個機制我查了下，是用于HBase集群備份用的，說有這么幾個用途：
1、數據備份和容災恢復
2、數據歸集
3、數據地理分布
4、在線數據服務和線下數據分析
我有幾個疑問：
1、數據備份有必要嘛？hdfs本身不就有副本功能，HBase數據肯定不會丟呀，除非hdfs服務器全部都被炸了，才可能丟數據，所以我覺得Replication機制用來數據備份應該是沒啥意義吧
2、容災恢復，我猜是不是比如我有2個機房，每個機房都是一個HBase集群，一個提供服務一個作為備份，然后第一個機房全癱了，比如網線被挖斷了，馬上把第二個機房啟用作為主服務，這樣恢復得快
3、什么是數據地理分布？這個也沒查到，可否簡單說下

答：

1. 如果使用HDFS三副本做數據備份，而且做的足夠好（跨機架、跨機房），再使用replication做數據備份意義確實不大。
2. replication可能更大的作用是服務高可用
3. 數據地理分布我理解應該是異地跨機房部署吧

小伙伴的問題7：
“特殊場景下，一旦Region數超過一個閾值，將會導致整個RegionServer級別的flush，嚴重阻塞用戶讀寫。”這里的region數超過一個閾值，是指region數多，那么memstore就會多，總量加起來超過rs總量設定的百分比，就會導致rs級別flush？亦或是rs的hlog文件數超過限制？
答：
恩 第一種理解 總實際占用的memstore大小超過rs設定的百分比 導致rs級別flush

參考鏈接：http://hbasefly.com/2016/08/22/hbase-practise-cluster-planning/