HBase最佳實踐 - 集羣規劃

本文由  網易雲 發佈。

 

做者：範欣欣

本篇文章僅限本站分享，如需轉載，請聯繫網易獲取受權。

 

 

HBase自身具備極好的擴展性，也所以，構建擴展集羣是它的天生強項之一。在實際線上應用中不少業務都運行在一個集羣上，業務之間共享集羣硬件、軟件資源。那問題來了，一個集羣上面到底應該運行哪些業務能夠最大程度上利用系統的軟硬件資源？另外，對於一個給定業務來講，應該如何規劃集羣的硬件容量才能使得資源不浪費？最後，一個給定的RegionServer上到底部署多少

Region比較合適？想必這些問題都曾經困惑過不少HBaser，那本文將結合前人的分享以及筆者的經驗簡單的對這三個問題分別進行解析，拋磚引玉，但願你們可以針對這幾個話題進行深刻的交流！

 

集羣業務規劃

 

通常而言，一個HBase集羣上不多隻跑一個業務，大多數狀況都是多個業務共享集羣，實際上就是共享系統軟硬件資源。這裏一般涉及兩大問題，其一是業務之間資源隔離問題，就是將各個業務在邏輯上隔離開來，互相不受影響，這個問題產生於業務共享場景下一旦某一業務一段時間內流量猛增必然會由於過分消耗系統資源而影響其餘業務；其二就是共享狀況下如何使得系統資源利用率最高，理想狀況下固然但願集羣中全部軟硬件資源都獲得最大程度利用。前者本次並不討論，後期會開’專場’討論，本節主要就後者進行探討。

使得集羣系統資源最大化利用，那首先要看業務對系統資源的需求狀況。通過對線上業務的梳理，一般可將這些業務分爲以下幾類：

 

1. 硬盤容量敏感型業務：這類業務對讀寫延遲以及吞吐量都沒有很大的要求，惟一的須要就是硬盤容量。好比大多數離線讀寫分析業務，上層應用通常每隔一段時間批量寫入大量數據，而後讀取也是按期批量讀取大量數據。特色：離線寫、離線讀，需求硬盤容量

2. 帶寬敏感型業務：這類業務大多數寫入吞吐量很大，但對讀取吞吐量沒有什麼要求。好比日誌實時存儲業務，上層應用經過kafka將海量日誌實時傳輸過來，要求可以實時寫入，而讀取場景通常是離線分析或者在上次業務遇到異常的時候對日誌進行檢索。特色：在線寫、離線讀，需求帶寬

3. IO敏感型業務：相比前面兩類業務來講，IO敏感型業務通常都是較爲核心的業務。這類業務對讀寫延遲要求較高，尤爲對於讀取延遲一般在100ms之內，部分業務可能要求更高。好比在線消息存儲系統、歷史訂單系統、實時推薦系統等。特色：在（離）線寫、在線讀，需求內存、高IOPS介質

（而對於CPU資源，HBase自己就是CPU敏感型系統，主要用於數據塊的壓縮/解壓縮，全部業務都對CPU有共同的需求）

 

一個集羣想要資源利用率最大化，一個思路就是各個業務之間‘揚長避短’，合理搭配，各取所需。實際上就是上述幾種類型的業務可以混合分佈，建議不要將同一種類型的業務太多分佈在同一個集羣。所以一個集羣理論上資源利用率比較高效的配置爲：硬盤敏感型業務 ＋ 帶寬敏感型業務 ＋ IO敏感型業務。

另外，集羣業務規劃的時候除了考慮資源使用率最大化這個問題以外，還須要考慮實際運維的需求。建議將核心業務和非核心業務分佈在同一個集羣，強烈建議不要將太多核心業務同時分佈在同一個集羣。這主要有兩方面的考慮：

1. 一方面是由於‘一山不容二虎’，核心業務共享資源必然會產生競爭，一旦出現競爭不管哪一個業務’落敗’都不是咱們願意看到的；

2. 另外一方面在特殊場景下方便運維童鞋進行降級處理，好比相似於淘寶雙十一這類大促活動，某個核心業務預期會有很大的流量涌入，爲了保證核心業務的平穩，在資源共享的狀況下只能犧牲其餘非核心業務，在和非核心業務方充分交流溝通的基礎上限制這些業務的資源使用，在流量極限的時候甚至能夠直接停掉這些非核心業務。試想，若是是不少核心業務共享集羣的話，哪一個核心業務願意輕易讓路？

那有些同窗就說了：若是按照你這樣設計，那豈不是會產生不少小集羣。的確，這種設計會產生不少小集羣，相信若是沒有資源隔離的話，小集羣是無法避免的。有些使用’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 / 128M * 3 * 0.4 * 2 = 192，意思是說RegionServer上1bytes的Java內存大小須要搭配192bytes的硬盤大小最合理，再回到以前給出的問題，128G的內存總大小，拿出96G做爲Java內存用於RegionServer，那對應須要搭配96G ＊ 192 = 18T 硬盤容量，而實際採購機器配置的是36T，說明在默認配置條件下會有幾乎一半硬盤被浪費。

 

計算公式是如何’冒’出來的？

 

再回過頭來看看那個計算公式是怎麼’冒’出來的，其實很簡單，只須要從硬盤容量緯度和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，基本就可使得硬盤和內存達到匹配。

3. 另外，若是給定配置下內存硬盤不匹配，那實際場景下內存’浪費’好呢仍是硬盤’浪費’好？答案是內存’浪費’好，好比採購的機器Java Heap能夠分配到126G，而總硬盤容量只有18T，默認配置下必然是Java Heap有浪費，可是能夠經過修改HBase配置將多餘的內存資源分配給HBase讀緩存BlockCache，這樣就能夠保證Java Heap並無實際浪費。

 

另外，還有這些資源須要注意…

 

帶寬資源：由於HBase在大量scan以及高吞吐量寫入的時候特別耗費網絡帶寬資源，強烈建議HBase集羣部署在萬兆交換機機房， 單臺機器最好也是萬兆網卡＋bond。若是特殊狀況交換機是千兆網卡，必定要保證全部的RegionServer機器部署在同一個交換機下，跨交換機會致使寫入延遲很大，嚴重影響業務寫入性能。

CPU資源：HBase是一個CPU敏感型業務，不管數據寫入讀取，都會由於大量的壓縮解壓操做，特別耗費計算資源。所以對於HBase來講，CPU越多越好。

參考：

Region規劃主要涉及到兩個方面：Region個數規劃以及單Region大小規劃，這兩個方面並不獨立，而是相互關聯的，大Region對應的Region個數少，小Region對應的Region個數多。Region規劃相信是不少HBase運維同窗比較關心的問題，一個給定規格的

RegionServer上運行多少Region比較合適，在剛開始接觸HBase的時候，這個問題也一直困擾着筆者。在實際應用中，Region太多或者太少都有必定的利弊：

 

	優勢	缺點
大量小Region	1. 更加有利於集羣之間負載分佈2. 有利於高效平穩的Compaction，這是由於小Region中HFile相對較小，Compaction代價小，詳情可見：Stripe Compaction	1. 最直接的影響：在某臺RegionServer異常宕機或者重啓的狀況下大量小Region 重分配以及遷移是一個很耗時的操做， 通常一個 Region遷移須要1.5s～2.5s左右，Region個數越多，遷移時間越長。直接致使failover時間很長。   2. 大量小Region有可能會產生更加頻繁的flush，產生不少小文件， 進而引發沒必要要的Compaction。特殊場景下，一旦Region數超過一個閾值，將會致使整個RegionServer級別的flush，嚴重阻塞用戶讀寫。   3. RegionServer管理維護開銷很大
少許大Region	1. 有利於RegionServer的快速重啓以及宕機恢復 2. 能夠減小總的RCP數量 3. 有利於產生更少的、更大的flush	1. Compaction效果不好，會引發較大的數據寫入抖動，穩定性較差   2. 不利於集羣之間負載均衡

 

能夠看出來，在HBase當前工做模式下，Region太多或者太少都不是一件太好的事情，在實際線上環境須要選擇一個折中點。官方文檔給出的一個推薦範圍在20～200之間，而單個Region大小控制在10G~30G，比較符合實際狀況。

 

然 而 ， HBase 並 不 能 直 接 配 置 一 臺 RegionServer 上 的 Region 數 ， Region 數 最 直 接 取 決 於 RegionSize 的 大 小 配 置hbase.hregion.max.filesize，HBase認爲，一旦某個Region的大小大於配置值，就會進行分裂。

 

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將會是一個災難。

 

可見，對於當下的HBase，若是想讓HBase工做的更加平穩（Region個數控制在20～200之間，單Region大小控制在10G~30G之間），最多能夠存儲的數據量差很少爲200 * 30G ＊ 3＝ 18T。若是存儲的數據量超過18T，必然會引發或多或少的性能問題。因此說，從Region規模這個角度講，當前單臺RegionServer可以合理利用起來的硬盤容量上限基本爲18T。

 

然而隨着硬件成本的不斷降低，單臺RegionServer能夠輕鬆配置40T＋的硬盤容量，若是按照上述說法，愈來愈多的硬盤其實只是’鏡中月，水中花’。社區也意識到了這樣的問題，在當前Region的概念下提出了Sub-Region的概念，能夠簡單理解爲將當前的Region切分爲不少邏輯上小的Sub-Region。Region仍是之前的Region，只是全部以前以Region爲單位進行的Compaction將會以更小的Sub-Region粒度執行。這樣，單Region就能夠配置的很大，好比50G、100G，此時單臺RegionServer上也就能夠存儲更多的數據。我的認爲Sub-Region功能將會是HBase開發的一個重點。

 

總結

本文結合HBase相關理論知識以及筆者的實際經驗，對HBase集羣規劃中最多見的三個問題 － 業務規劃、容量規劃以及Region規劃作了簡單的解析，但願給你們一些啓發和思考。線上集羣規劃是一個經驗積累的過程，相信每一個HBase運維同窗或多或少都會碰到一些坑，也確定會有本身的思考和看法，但願你們可以更多的在評論區或者郵件交流，謝謝！

 

 

網易有數：企業級大數據可視化分析平臺。面向業務人員的自助式敏捷分析平臺，採用PPT模式的報告製做，更加易學易用，具有強大的探索分析功能，真正幫助用戶洞察數據發現價值。可點擊這裏免費試用。

 

瞭解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/