? HBase是一種支持自動負載均衡的分布式KV數(shù)據(jù)庫，在開啟balance的開關(guān)(balance_switch)后，HBase的HMaster進程會自動根據(jù)指定策略挑選出一些Region，并將這些Region分配給負載比較低的RegionServer上。官方目前支持兩種挑選Region的策略，一種叫做DefaultLoadBalancer，另一種叫做StochasticLoadBalancer，這兩種策略后面會具體講到。由于HBase的所有數(shù)據(jù)(包括HLog/Meta/HStoreFile等)都是寫入到HDFS文件系統(tǒng)中的， 因此HBase的Region移動其實非常輕量級。在做Region移動的時候，保持這個Region對應(yīng)的HDFS文件位置不變，只需要將Region的Meta數(shù)據(jù)分配到相關(guān)的RegionServer即可，整個Region移動的過程取決于RegionClose以及RegionOpen的耗時，這個時間一般都很短。

本文來講講hbase的balance實現(xiàn)。

balance的流程

• 首先通過LoadBalancer找出所有需要移動的region plan，一個region plan包括region/原始RegionServer/目的RegionServer三個屬性
• unassign region , 將region從原來的RegionServer上解除綁定；
• assign region ，將region綁定到目標(biāo)RegionServer上;

? ? ?其中， unassign region的具體流程為：

• create zk closing node . 該節(jié)點在/unassigned路徑下， 包含(znode狀態(tài)，region名字，原始RS名，payload)這些數(shù)據(jù)。
• hmaster 調(diào)用rpc服務(wù)關(guān)閉region server。region-close的流程大致為先獲取region的writeLock ， 然后flush memstore, 再并發(fā)關(guān)閉該region下的所有的store file文件(注意一個region有多個store，每個store又有多個store file , 所以可以實現(xiàn)并發(fā)close store file) 。最后釋放region的writeLock.
• 設(shè)置zk closing node的znode狀態(tài)為closed.

assgin region的具體流程為:

• 獲取到對應(yīng)的Region Plan.
• HMaster調(diào)用rpc服務(wù)去Region Plan對應(yīng)的RegionServer上open region. 這里會先更新/unassigned節(jié)點為opening. 然后并發(fā)Load HStore，再更行zk/ROOT/META表信息，這里是為了client下次能獲取到正確的路由信息， 最后更新region狀態(tài)為OPEN.

DefaultLoadBalancer策略

這種策略能夠保證每個RS的regions個數(shù)基本上都相等，確切來說，假設(shè)一共有n個RS，第i個RS有Ai個region，記average=sigma(Ai)/n , 那么這種策略能夠保證所有的RS的region個數(shù)都在[floor(average), ceil(average)]之間。這種策略的實現(xiàn)簡單，應(yīng)用廣泛。

但是，這種策略考慮的因素比較單一， 沒有考慮到每臺region server的讀寫qps/負載壓力等等，這樣就可能導(dǎo)致出現(xiàn)一種情況：雖然每個region server的regions都非常接近，但是90%的請求還是落在了一臺RS上，因為這臺RS上的region全部都是熱點數(shù)據(jù)，這樣還是沒有達到負載均衡的目的。 但我覺得balance的首要目的是保證數(shù)據(jù)均衡，如果在數(shù)據(jù)均衡的情況下，負載還是集中，這時候就要考慮下rowKey的選擇是否有問題了。因此, 我個人還是比較推薦采用DefaultLoadBalancer的。

StochasticLoadBalancer策略

StochasticLoadBalancer 這種策略真的是非常復(fù)雜，簡單來講，是一種綜合權(quán)衡一下6個因素的均衡策略：

• 每臺服務(wù)器讀請求數(shù)(ReadRequestCostFunction)
• 每臺服務(wù)器寫請求數(shù)(WriteRequestCostFunction)
• Region個數(shù)(RegionCountSkewCostFunction)
• 移動代價(MoveCostFunction)
• 數(shù)據(jù)locality(TableSkewCostFunction)
• 每張表占據(jù)RegionServer中region個數(shù)上限(LocalityCostFunction)

對于cluster的每一種region分布， 采用6個因素加權(quán)的方式算出一個代價值，這個代價值就用來評估當(dāng)前region分布是否均衡，越均衡代價值越低。然后通過成千上萬次隨機迭代來找到一組RegionMove的序列，使得最終的代價值嚴(yán)格遞減。 得到的這一組RegionMove就是HMaster最終執(zhí)行的region遷移方案。

這里用一段偽代碼來描述這個迭代的過程:

currentCost = MAX ; plans = [] for(step = 0 ; step < 1000000; step ++ ){action = cluster.generateMove() doAction( action );newCost = computeCost(action) ;if (newCost < currentCost){currentCost = newCost;}else{undoAction(action);}plans.add( action ) }

其中g(shù)enerateMove()每次隨機選擇以下3種策略之一來生成RegionMove:

隨機選擇兩個RS, 從每個RS中隨機選擇兩個Region，然后生成一個Action, 這個Action有一半概率做RegionMove（從Region多的RS遷移到Region少的RS）, 另一半概率做RegionSwap。

選擇Region最多的RS和Region最少的RS，然后生成一個Action, 這個Action一半概率做RegionMove, 一半概率做RegionSwap。

隨機找一個RS，然后找到該RS上數(shù)據(jù)locality最差的Region，然后找到Region大部分?jǐn)?shù)據(jù)落在的RS，然后生成一個Action，該Action用來把Region遷移到它應(yīng)該所在的RS，用來提高locality.

? 對于這種策略，JavaDoc上說效果比較好，但其中的合理性個人覺得有待測試數(shù)據(jù)的證明(官方基本沒有給出這方面的測試結(jié)果)。如果6個因素每個參數(shù)占據(jù)的權(quán)重如果沒有調(diào)好的話，會導(dǎo)致線上的Region大量不均衡。按照我的一次線上經(jīng)歷，采用如下blance配置，出現(xiàn)過每次balance都只選擇60個左右的plan去移動， 但真實的情況是145個RS，其中region數(shù)量最多的有700+個， 最少的region數(shù)量有2個，然后其他RS的region數(shù)量在2~700不等，這時候按理來講應(yīng)該需要進行大量的balance，但HMaster每隔一個period只生成60個plan左右去移動，這樣balance太慢導(dǎo)致很長一段時間內(nèi)負載不均，有的RS非常清閑，有的RS非常繁忙經(jīng)常超時。

hbase.master.loadbalancer.class=\org.apache.hadoop.hbase.master.StochasticLoadBalancer hbase.master.balancer.stochastic.regionCountCost=10 hbase.master.balancer.stochastic.tableSkewCost=5 hbase.master.balancer.stochastic.readRequestCost=5 hbase.master.balancer.stochastic.writeRequestCost=5 hbase.master.balancer.stochastic.localityCost=10 hbase.master.balancer.stochastic.moveCost=4 hbase.master.balancer.stochastic.maxMovePercent=1

后面對比了下了官方的默認(rèn)配置，應(yīng)該是regionCountCost一項權(quán)重太低， 但是，我想說的是除非線下有一個測試結(jié)果支撐具體的權(quán)重配置下 balance是符合預(yù)期的，否則線上操作時一般對權(quán)重很難有一個準(zhǔn)確的把握，所以像這么復(fù)雜的策略還是要比較謹(jǐn)慎的選擇，最好有過歷史測試數(shù)據(jù)來評估balance的效果。

總結(jié)

以上是生活随笔為你收集整理的hbase中balance机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。