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

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

balance的流程

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

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

• create zk closing node . 該節(jié)點(diǎn)在/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文件(注意一個(gè)region有多個(gè)store，每個(gè)store又有多個(gè)store file , 所以可以實(shí)現(xiàn)并發(fā)close store file) 。最后釋放region的writeLock.
• 設(shè)置zk closing node的znode狀態(tài)為closed.

assgin region的具體流程為:

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

DefaultLoadBalancer策略

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

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

StochasticLoadBalancer策略

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

• 每臺(tái)服務(wù)器讀請(qǐng)求數(shù)(ReadRequestCostFunction)
• 每臺(tái)服務(wù)器寫請(qǐng)求數(shù)(WriteRequestCostFunction)
• Region個(gè)數(shù)(RegionCountSkewCostFunction)
• 移動(dòng)代價(jià)(MoveCostFunction)
• 數(shù)據(jù)locality(TableSkewCostFunction)
• 每張表占據(jù)RegionServer中region個(gè)數(shù)上限(LocalityCostFunction)

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

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

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()每次隨機(jī)選擇以下3種策略之一來生成RegionMove:

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

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

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

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

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

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

總結(jié)

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

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