這篇文章主要介紹HBase如何實(shí)現(xiàn)性能調(diào)優(yōu)，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

成都創(chuàng)新互聯(lián)公司成立與2013年，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站制作、成都做網(wǎng)站網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元赤城做網(wǎng)站,已為上家服務(wù),為赤城各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

節(jié)點(diǎn)管理

節(jié)點(diǎn)下線

你可以在HBase的特定的節(jié)點(diǎn)上運(yùn)行下面的腳本來停止RegionServer:

$ ./bin/hbase-daemon.sh stop regionserver

RegionServer會首先關(guān)閉所有的region然后把它自己關(guān)閉，在停止的過程中，RegionServer的會向Zookeeper報(bào)告說他已經(jīng)過期了。master會發(fā)現(xiàn)RegionServer已經(jīng)死了，會把它當(dāng)作崩潰的server來處理。他會將region分配到其他的節(jié)點(diǎn)上去。

在下線節(jié)點(diǎn)之前要停止Load Balancer

如果在運(yùn)行l(wèi)oad balancer的時(shí)候，一個(gè)節(jié)點(diǎn)要關(guān)閉， 則Load Balancer和Master的recovery可能會爭奪這個(gè)要下線的Regionserver。為了避免這個(gè)問題，先將load balancer停止，參見下面的 Load Balancer.

RegionServer下線有一個(gè)缺點(diǎn)就是其中的Region會有好一會離線。Regions是被按順序關(guān)閉的。如果一個(gè)server上有很多region,從第一個(gè)region會被下線，到最后一個(gè)region被關(guān)閉，并且Master確認(rèn)他已經(jīng)死了，該region才可以上線，整個(gè)過程要花很長時(shí)間。在HBase 0.90.2中，我們加入了一個(gè)功能，可以讓節(jié)點(diǎn)逐漸的擺脫他的負(fù)載，最后關(guān)閉。HBase 0.90.2加入了 graceful_stop.sh腳本，可以這樣用，

$ ./bin/graceful_stop.sh 
Usage: graceful_stop.sh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--rest] &hostname>
 thrift      If we should stop/start thrift before/after the hbase stop/start
 rest        If we should stop/start rest before/after the hbase stop/start
 restart     If we should restart after graceful stop
 reload      Move offloaded regions back on to the stopped server
 debug       Move offloaded regions back on to the stopped server
 hostname    Hostname of server we are to stop

要下線一臺RegionServer可以這樣做

$ ./bin/graceful_stop.sh HOSTNAME

這里的HOSTNAME是你想要下線的RegionServer的host.

關(guān)于HOSTNAME 傳遞到graceful_stop.sh的HOSTNAME必須和hbase使用的hostname一致，hbase用它來區(qū)分RegionServers。可以用master的UI來檢查RegionServers的id。通常是hostname,也可能是FQDN。不管HBase使用的哪一個(gè)，你可以將它傳到 graceful_stop.sh腳本中去，目前他還不支持使用IP地址來推斷hostname。所以使用IP就會發(fā)現(xiàn)server不在運(yùn)行，也沒有辦法下線了。

graceful_stop.sh 腳本會一個(gè)一個(gè)將region從RegionServer中移除出去，以減少改RegionServer的負(fù)載。他會先移除一個(gè)region,然后再將這個(gè)region安置到一個(gè)新的地方，再移除下一個(gè)，直到全部移除。最后graceful_stop.sh腳本會讓RegionServer stop.,Master會注意到RegionServer已經(jīng)下線了，這個(gè)時(shí)候所有的region已經(jīng)重新部署好。RegionServer就可以干干凈凈的結(jié)束，沒有WAL日志需要分割。

Load Balancer當(dāng)執(zhí)行g(shù)raceful_stop腳本的時(shí)候，要將Region Load Balancer關(guān)掉(否則balancer和下線腳本會在region部署的問題上存在沖突):

hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3590 seconds

上面是將balancer關(guān)掉，要想開啟：

hbase(main):001:0> balance_switch true
false
0 row(s) in 0.3590 seconds

14.3.2. 依次重啟 你還可以讓這個(gè)腳本重啟一個(gè)RegionServer,不改變上面的Region的位置。要想保留數(shù)據(jù)的位置，你可以依次重啟(Rolling Restart),就像這樣:

$ for i in `cat conf/regionservers|sort`; do ./bin/graceful_stop.sh --restart --reload --debug $i; done &> /tmp/log.txt &

Tail /tmp/log.txt來看腳本的運(yùn)行過程.上面的腳本只對RegionServer進(jìn)行操作。要確認(rèn)load balancer已經(jīng)關(guān)掉。還需要在之前更新master。下面是一段依次重啟的偽腳本,你可以借鑒它：

確認(rèn)你的版本，保證配置已經(jīng)rsync到整個(gè)集群中。如果版本是0.90.2，需要打上HBASE-3744 和 HBASE-3756兩個(gè)補(bǔ)丁。

運(yùn)行hbck確保你的集群是一致的

$ ./bin/hbase hbck

當(dāng)發(fā)現(xiàn)不一致的時(shí)候，可以修復(fù)參考http://my.oschina.net/drl/blog/683885。

重啟Master:

$ ./bin/hbase-daemon.sh stop master; ./bin/hbase-daemon.sh start master

關(guān)閉region balancer:

$ echo "balance_switch false" | ./bin/hbase

在每個(gè)RegionServer上運(yùn)行g(shù)raceful_stop.sh：

$ for i in `cat conf/regionservers|sort`; do ./bin/graceful_stop.sh --restart --reload --debug $i; done &> /tmp/log.txt &

如果你在RegionServer還開起來thrift和rest server。還需要加上--thrift or --rest 選項(xiàng) (參見 graceful_stop.sh 腳本的用法).

再次重啟Master.這會把已經(jīng)死亡的server列表清空，重新開啟balancer.

運(yùn)行 hbck 保證集群是一致的

配置優(yōu)化

zookeeper.session.timeout

默認(rèn)值：3分鐘（180000ms）

說明：RegionServer與Zookeeper間的連接超時(shí)時(shí)間。當(dāng)超時(shí)時(shí)間到后，ReigonServer會被Zookeeper從RS集群清單中移除，HMaster收到移除通知后，會對這臺server負(fù)責(zé)的regions重新balance，讓其他存活的RegionServer接管.

調(diào)優(yōu)：這個(gè)timeout決定了RegionServer是否能夠及時(shí)的failover。設(shè)置成1分鐘或更低，可以減少因等待超時(shí)而被延長的failover時(shí)間。 不過需要注意的是，對于一些Online應(yīng)用，RegionServer從宕機(jī)到恢復(fù)時(shí)間本身就很短的（網(wǎng)絡(luò)閃斷，crash等故障，運(yùn)維可快速介入），如果調(diào)低timeout時(shí)間，反而會得不償失。因?yàn)楫?dāng)ReigonServer被正式從RS集群中移除時(shí)，HMaster就開始做balance了（讓其他RS根據(jù)故障機(jī)器記錄的WAL日志進(jìn)行恢復(fù)）。當(dāng)故障的RS在人工介入恢復(fù)后，這個(gè)balance動(dòng)作是毫無意義的，反而會使負(fù)載不均勻，給RS帶來更多負(fù)擔(dān)。特別是那些固定分配regions的場景。

hbase.regionserver.handler.count

默認(rèn)值：10

說明：RegionServer的請求處理IO線程數(shù)。

調(diào)優(yōu)：這個(gè)參數(shù)的調(diào)優(yōu)與內(nèi)存息息相關(guān)。 較少的IO線程，適用于處理單次請求內(nèi)存消耗較高的Big PUT場景（大容量單次PUT或設(shè)置了較大cache的scan，均屬于Big PUT）或ReigonServer的內(nèi)存比較緊張的場景。 較多的IO線程，適用于單次請求內(nèi)存消耗低，TPS要求非常高的場景。設(shè)置該值的時(shí)候，以監(jiān)控內(nèi)存為主要參考。 這里需要注意的是如果server的region數(shù)量很少，大量的請求都落在一個(gè)region上，因快速充滿memstore觸發(fā)flush導(dǎo)致的讀寫鎖會影響全局TPS，不是IO線程數(shù)越高越好。 壓測時(shí)，開啟Enabling RPC-level logging，可以同時(shí)監(jiān)控每次請求的內(nèi)存消耗和GC的狀況，最后通過多次壓測結(jié)果來合理調(diào)節(jié)IO線程數(shù)。 這里是一個(gè)案例?Hadoop and HBase Optimization for Read Intensive Search Applications，作者在SSD的機(jī)器上設(shè)置IO線程數(shù)為100，僅供參考。

hbase.hregion.max.filesize

默認(rèn)值：256M

說明：在當(dāng)前ReigonServer上單個(gè)Reigon的最大存儲空間，單個(gè)Region超過該值時(shí)，這個(gè)Region會被自動(dòng)split成更小的region。

調(diào)優(yōu)： 小region對split和compaction友好，因?yàn)椴鸱謗egion或compact小region里的storefile速度很快，內(nèi)存占用低。缺點(diǎn)是split和compaction會很頻繁。 特別是數(shù)量較多的小region不停地split, compaction，會導(dǎo)致集群響應(yīng)時(shí)間波動(dòng)很大，region數(shù)量太多不僅給管理上帶來麻煩，甚至?xí)l(fā)一些Hbase的bug。 一般512以下的都算小region。

大region，則不太適合經(jīng)常split和compaction，因?yàn)樽鲆淮蝐ompact和split會產(chǎn)生較長時(shí)間的停頓，對應(yīng)用的讀寫性能沖擊非常大。此外，大region意味著較大的storefile，compaction時(shí)對內(nèi)存也是一個(gè)挑戰(zhàn)。 當(dāng)然，大region也有其用武之地。如果你的應(yīng)用場景中，某個(gè)時(shí)間點(diǎn)的訪問量較低，那么在此時(shí)做compact和split，既能順利完成split和compaction，又能保證絕大多數(shù)時(shí)間平穩(wěn)的讀寫性能。

既然split和compaction如此影響性能，有沒有辦法去掉？ compaction是無法避免的，split倒是可以從自動(dòng)調(diào)整為手動(dòng)。 只要通過將這個(gè)參數(shù)值調(diào)大到某個(gè)很難達(dá)到的值，比如100G，就可以間接禁用自動(dòng)split（RegionServer不會對未到達(dá)100G的region做split）。 再配合RegionSplitter這個(gè)工具，在需要split時(shí)，手動(dòng)split。 手動(dòng)split在靈活性和穩(wěn)定性上比起自動(dòng)split要高很多，相反，管理成本增加不多，比較推薦online實(shí)時(shí)系統(tǒng)使用。

內(nèi)存方面，小region在設(shè)置memstore的大小值上比較靈活，大region則過大過小都不行，過大會導(dǎo)致flush時(shí)app的IO wait增高，過小則因store file過多影響讀性能。

hbase.regionserver.global.memstore.upperLimit/lowerLimit

默認(rèn)值：0.4/0.35

upperlimit說明：hbase.hregion.memstore.flush.size 這個(gè)參數(shù)的作用是當(dāng)單個(gè)Region內(nèi)所有的memstore大小總和超過指定值時(shí)，flush該region的所有memstore。RegionServer的flush是通過將請求添加一個(gè)隊(duì)列，模擬生產(chǎn)消費(fèi)模式來異步處理的。那這里就有一個(gè)問題，當(dāng)隊(duì)列來不及消費(fèi)，產(chǎn)生大量積壓請求時(shí)，可能會導(dǎo)致內(nèi)存陡增，最壞的情況是觸發(fā)OOM。 這個(gè)參數(shù)的作用是防止內(nèi)存占用過大，當(dāng)ReigonServer內(nèi)所有region的memstores所占用內(nèi)存總和達(dá)到heap的40%時(shí)，HBase會強(qiáng)制block所有的更新并flush這些region以釋放所有memstore占用的內(nèi)存。

lowerLimit說明： 同upperLimit，只不過lowerLimit在所有region的memstores所占用內(nèi)存達(dá)到Heap的35%時(shí)，不flush所有的memstore。它會找一個(gè)memstore內(nèi)存占用最大的region，做個(gè)別flush，此時(shí)寫更新還是會被block。lowerLimit算是一個(gè)在所有region強(qiáng)制flush導(dǎo)致性能降低前的補(bǔ)救措施。在日志中，表現(xiàn)為 “** Flush thread woke up with memory above low water.”

調(diào)優(yōu)：這是一個(gè)Heap內(nèi)存保護(hù)參數(shù)，默認(rèn)值已經(jīng)能適用大多數(shù)場景。 參數(shù)調(diào)整會影響讀寫，如果寫的壓力大導(dǎo)致經(jīng)常超過這個(gè)閥值，則調(diào)小讀緩存hfile.block.cache.size增大該閥值，或者Heap余量較多時(shí)，不修改讀緩存大小。 如果在高壓情況下，也沒超過這個(gè)閥值，那么建議你適當(dāng)調(diào)小這個(gè)閥值再做壓測，確保觸發(fā)次數(shù)不要太多，然后還有較多Heap余量的時(shí)候，調(diào)大hfile.block.cache.size提高讀性能。 還有一種可能性是?hbase.hregion.memstore.flush.size保持不變，但RS維護(hù)了過多的region，要知道 region數(shù)量直接影響占用內(nèi)存的大小。

hfile.block.cache.size

默認(rèn)值：0.2

說明：storefile的讀緩存占用Heap的大小百分比，0.2表示20%。該值直接影響數(shù)據(jù)讀的性能。

調(diào)優(yōu)：當(dāng)然是越大越好，如果寫比讀少很多，開到0.4-0.5也沒問題。如果讀寫較均衡，0.3左右。如果寫比讀多，果斷默認(rèn)吧。設(shè)置這個(gè)值的時(shí)候，你同時(shí)要參考?hbase.regionserver.global.memstore.upperLimit?，該值是memstore占heap的最大百分比，兩個(gè)參數(shù)一個(gè)影響讀，一個(gè)影響寫。如果兩值加起來超過80-90%，會有OOM的風(fēng)險(xiǎn)，謹(jǐn)慎設(shè)置。

hbase.hstore.blockingStoreFiles

默認(rèn)值：7

說明：在flush時(shí)，當(dāng)一個(gè)region中的Store（Coulmn Family）內(nèi)有超過7個(gè)storefile時(shí)，則block所有的寫請求進(jìn)行compaction，以減少storefile數(shù)量。 調(diào)優(yōu)：block寫請求會嚴(yán)重影響當(dāng)前regionServer的響應(yīng)時(shí)間，但過多的storefile也會影響讀性能。從實(shí)際應(yīng)用來看，為了獲取較平滑的響應(yīng)時(shí)間，可將值設(shè)為無限大。如果能容忍響應(yīng)時(shí)間出現(xiàn)較大的波峰波谷，那么默認(rèn)或根據(jù)自身場景調(diào)整即可。

hbase.hregion.memstore.block.multiplier

默認(rèn)值：2

說明：當(dāng)一個(gè)region里的memstore占用內(nèi)存大小超過hbase.hregion.memstore.flush.size兩倍的大小時(shí)，block該region的所有請求，進(jìn)行flush，釋放內(nèi)存。 雖然我們設(shè)置了region所占用的memstores總內(nèi)存大小，比如64M，但想象一下，在最后63.9M的時(shí)候，我Put了一個(gè)200M的數(shù)據(jù)，此時(shí)memstore的大小會瞬間暴漲到超過預(yù)期的hbase.hregion.memstore.flush.size的幾倍。這個(gè)參數(shù)的作用是當(dāng)memstore的大小增至超過hbase.hregion.memstore.flush.size 2倍時(shí)，block所有請求，遏制風(fēng)險(xiǎn)進(jìn)一步擴(kuò)大。

調(diào)優(yōu)： 這個(gè)參數(shù)的默認(rèn)值還是比較靠譜的。如果你預(yù)估你的正常應(yīng)用場景（不包括異常）不會出現(xiàn)突發(fā)寫或?qū)懙牧靠煽兀敲幢３帜J(rèn)值即可。如果正常情況下，你的寫請求量就會經(jīng)常暴長到正常的幾倍，那么你應(yīng)該調(diào)大這個(gè)倍數(shù)并調(diào)整其他參數(shù)值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以預(yù)留更多內(nèi)存，防止HBase server OOM。

hbase.hregion.memstore.mslab.enabled

默認(rèn)值：true

說明：減少因內(nèi)存碎片導(dǎo)致的Full GC，提高整體性能。

調(diào)優(yōu)：詳見 http://kenwublog.com/avoid-full-gc-in-hbase-using-arena-allocation

其他

啟用LZO壓縮

LZO對比Hbase默認(rèn)的GZip，前者性能較高，后者壓縮比較高，具體參見?Using LZO Compression 。對于想提高HBase讀寫性能的開發(fā)者，采用LZO是比較好的選擇。對于非常在乎存儲空間的開發(fā)者，則建議保持默認(rèn)。

不要在一張表里定義太多的Column Family

Hbase目前不能良好的處理超過包含2-3個(gè)CF的表。因?yàn)槟硞€(gè)CF在flush發(fā)生時(shí)，它鄰近的CF也會因關(guān)聯(lián)效應(yīng)被觸發(fā)flush，最終導(dǎo)致系統(tǒng)產(chǎn)生更多IO。

批量導(dǎo)入

在批量導(dǎo)入數(shù)據(jù)到Hbase前，你可以通過預(yù)先創(chuàng)建regions，來平衡數(shù)據(jù)的負(fù)載。詳見?Table Creation: Pre-Creating Regions

避免CMS concurrent mode failure

HBase使用CMS GC。默認(rèn)觸發(fā)GC的時(shí)機(jī)是當(dāng)年老代內(nèi)存達(dá)到90%的時(shí)候，這個(gè)百分比由 -XX:CMSInitiatingOccupancyFraction=N 這個(gè)參數(shù)來設(shè)置。concurrent mode failed發(fā)生在這樣一個(gè)場景： 當(dāng)年老代內(nèi)存達(dá)到90%的時(shí)候，CMS開始進(jìn)行并發(fā)垃圾收集，于此同時(shí)，新生代還在迅速不斷地晉升對象到年老代。當(dāng)年老代CMS還未完成并發(fā)標(biāo)記時(shí)，年老代滿了，悲劇就發(fā)生了。CMS因?yàn)闆]內(nèi)存可用不得不暫停mark，并觸發(fā)一次stop the world（掛起所有jvm線程），然后采用單線程拷貝方式清理所有垃圾對象。這個(gè)過程會非常漫長。為了避免出現(xiàn)concurrent mode failed，建議讓GC在未到90%時(shí)，就觸發(fā)。

通過設(shè)置-XX:CMSInitiatingOccupancyFraction=N

這個(gè)百分比， 可以簡單的這么計(jì)算。如果你的hfile.block.cache.size 和hbase.regionserver.global.memstore.upperLimit 加起來有60%（默認(rèn)），那么你可以設(shè)置 70-80，一般高10%左右差不多。

Hbase客戶端優(yōu)化

AutoFlush

將HTable的setAutoFlush設(shè)為false，可以支持客戶端批量更新。即當(dāng)Put填滿客戶端flush緩存時(shí)，才發(fā)送到服務(wù)端。 默認(rèn)是true。

Scan Caching

scanner一次緩存多少數(shù)據(jù)來scan（從服務(wù)端一次抓多少數(shù)據(jù)回來scan）。 默認(rèn)值是 1，一次只取一條。

Scan Attribute Selection

scan時(shí)建議指定需要的Column Family，減少通信量，否則scan操作默認(rèn)會返回整個(gè)row的所有數(shù)據(jù)（所有Coulmn Family）。

Close ResultScanners

通過scan取完數(shù)據(jù)后，記得要關(guān)閉ResultScanner，否則RegionServer可能會出現(xiàn)問題（對應(yīng)的Server資源無法釋放）。

Optimal Loading of Row Keys

當(dāng)你scan一張表的時(shí)候，返回結(jié)果只需要row key（不需要CF, qualifier,values,timestaps）時(shí)，你可以在scan實(shí)例中添加一個(gè)filterList，并設(shè)置 MUST_PASS_ALL操作，filterList中add?FirstKeyOnlyFilter或KeyOnlyFilter。這樣可以減少網(wǎng)絡(luò)通信量。

Turn off WAL on Puts

當(dāng)Put某些非重要數(shù)據(jù)時(shí)，你可以設(shè)置writeToWAL(false)，來進(jìn)一步提高寫性能。writeToWAL(false)會在Put時(shí)放棄寫WAL log。風(fēng)險(xiǎn)是，當(dāng)RegionServer宕機(jī)時(shí)，可能你剛才Put的那些數(shù)據(jù)會丟失，且無法恢復(fù)。

啟用Bloom Filter

Bloom Filter通過空間換時(shí)間，提高讀操作性能。

major_compact 'testtable'

通常生產(chǎn)環(huán)境會關(guān)閉自動(dòng)major_compact(配置文件中hbase.hregion.majorcompaction設(shè) 為0)，選擇一個(gè)晚上用戶少的時(shí)間窗口手工major_compact，如果hbase更新不是太頻繁，可以一個(gè)星期對所有表做一次 major_compact，這個(gè)可以在做完一次major_compact后，觀看所有的storefile數(shù)量，如果storefile數(shù)量增加到 major_compact后的storefile的近二倍時(shí)，可以對所有表做一次major_compact，時(shí)間比較長，操作盡量避免高鋒期。

hbase的遷移

1，copytable方式

bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=zookeeper1,zookeeper2,zookeeper3:/hbase 'testtable'

目前0.92之前的版本的不支持多版本的復(fù)制，0.94已經(jīng)支持多個(gè)版本的復(fù)制。當(dāng)然這個(gè)操作需要添加hbase目錄里的conf/mapred-site.xml，可以復(fù)制hadoop的過來。 2，Export/Import

bin/hbase org.apache.hadoop.hbase.mapreduce.Export testtable /user/testtable [versions] [starttime] [stoptime]
    bin/hbase org.apache.hadoop.hbase.mapreduce.Import testtable  /user/testtable

跨版本的遷移，我覺得是一個(gè)不錯(cuò)的選擇，而且copytable不支持多版本，而export支持多版本，比copytable更實(shí)用一些。 3，直接拷貝hdfs對應(yīng)的文件

首先拷貝hdfs文件，如bin/hadoop distcp hdfs://srcnamenode:9000/hbase/testtable/ hdfs://distnamenode:9000/hbase/testtable/
然后在目的hbase上執(zhí)行bin/hbase org.jruby.Main bin/add_table.rb /hbase/testtable

生成meta信息后，重啟hbase 這個(gè)操作是簡單的方式，操作之前可以關(guān)閉hbase的寫入，執(zhí)行flush所有表（上面有介紹）,再distcp拷貝，如果hadoop版本不一致，可以用hftp接口的方式，我推薦使用這種方式，成本低

Jvm調(diào)整：

• a、內(nèi)存大小： master默認(rèn)為1G，可增加到2G，regionserver默認(rèn)1G，可調(diào)大到10G，或者更大，zk并不耗資源，可以不用調(diào)整，需要注意的是，調(diào)整了rs的內(nèi)存大小后，需調(diào)整hbase.regionserver.maxlogs和hbase.regionserver.hlog.blocksize這兩個(gè)參數(shù)，WAL的最大值由hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize決定（默認(rèn)32*32M~=1G），一旦達(dá)到這個(gè)值，就會被觸發(fā)flush memstore，如果memstore的內(nèi)存增大了，但是沒有調(diào)整這兩個(gè)參數(shù)，實(shí)際上對大量小文件沒有任何改進(jìn)，調(diào)整策略：hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 設(shè)置為略大于hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE。

• b、垃圾回收： export HBASE_OPTS="$HBASE_OPTS -Xms30720m -Xmx30720m -XX:NewSize=512m -XX:MaxPermSize=128m -XX:PermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/local/hbase-0.94.0/logs/gc-hbase.log"。

其它調(diào)優(yōu)

1）列族、rowkey要盡量短，每個(gè)cell值均會存儲一次列族名稱和rowkey，甚至列名稱也要盡量短

2）RS的region數(shù)量：一般每個(gè)RegionServer不要過1000，過多的region會導(dǎo)致產(chǎn)生較多的小文件，從而導(dǎo)致更多的compact，當(dāng)有大量的超過5G的region并且RS總region數(shù)達(dá)到1000時(shí)，應(yīng)該考慮擴(kuò)容。

3）建表時(shí)： a、如果不需要多版本，則應(yīng)設(shè)置version=1； b、 開啟lzo或者snappy壓縮，壓縮會消耗一定的CPU，但是，磁盤IO和網(wǎng)絡(luò)IO將獲得極大的改善，大致可以壓縮4~5倍； c、合理的設(shè)計(jì)rowkey，在設(shè)計(jì)rowkey時(shí)需充分的理解現(xiàn)有業(yè)務(wù)并合理預(yù)見未來業(yè)務(wù)，不合理的rowkey設(shè)計(jì)將導(dǎo)致極差的hbase操作性能； d、合理的規(guī)劃數(shù)據(jù)量，進(jìn)行預(yù)分區(qū)，避免在表使用過程中的不斷split，并把數(shù)據(jù)的讀寫分散到不同的RS，充分的發(fā)揮集群的作用； e、列族名稱盡量短，比如：“f”，并且盡量只有一個(gè)列族； f、視場景開啟bloomfilter，優(yōu)化讀性能。

Client端調(diào)優(yōu)

1、hbase.client.write.buffer：寫緩存大小，默認(rèn)為2M，推薦設(shè)置為6M，單位是字節(jié)，當(dāng)然不是越大越好，如果太大，則占用的內(nèi)存太多；

2、hbase.client.scanner.caching：scan緩存，默認(rèn)為1，太小，可根據(jù)具體的業(yè)務(wù)特征進(jìn)行配置，原則上不可太大，避免占用過多的client和rs的內(nèi)存，一般最大幾百，如果一條數(shù)據(jù)太大，則應(yīng)該設(shè)置一個(gè)較小的值，通常是設(shè)置業(yè)務(wù)需求的一次查詢的數(shù)據(jù)條數(shù)，比如：業(yè)務(wù)特點(diǎn)決定了一次最多50條，則可以設(shè)置為50

3、設(shè)置合理的超時(shí)時(shí)間和重試次數(shù)，具體的內(nèi)容會在后續(xù)的blog中詳細(xì)講解。

4、client應(yīng)用讀寫分離 讀和寫分離，位于不同的tomcat實(shí)例，數(shù)據(jù)先寫入redis隊(duì)列，再異步寫入hbase，如果寫失敗再回存redis隊(duì)列，先讀redis緩存的數(shù)據(jù)（如果有緩存，需要注意這里的redis緩存不是redis隊(duì)列），如果沒有讀到再讀hbase。 當(dāng)hbase集群不可用，或者某個(gè)RS不可用時(shí)，因?yàn)镠Base的重試次數(shù)和超時(shí)時(shí)間均比較大（為保證正常的業(yè)務(wù)訪問，不可能調(diào)整到比較小的值，如果一個(gè)RS掛了，一次讀或者寫，經(jīng)過若干重試和超時(shí)可能會持續(xù)幾十秒，或者幾分鐘），所以一次操作可能會持續(xù)很長時(shí)間，導(dǎo)致tomcat線程被一個(gè)請求長時(shí)間占用，tomcat的線程數(shù)有限，會被快速占完，導(dǎo)致沒有空余線程做其它操作，讀寫分離后，寫由于采用先寫redis隊(duì)列，再異步寫hbase，因此不會出現(xiàn)tomcat線程被占滿的問題， 應(yīng)用還可以提供寫服務(wù)，如果是充值等業(yè)務(wù)，則不會損失收入，并且讀服務(wù)出現(xiàn)tomcat線程被占滿的時(shí)間也會變長一些，如果運(yùn)維介入及時(shí)，則讀服務(wù)影響也比較有限。

5、如果把org.apache.hadoop.hbase.client.HBaseAdmin配置為spring的bean，則需配置為懶加載，避免在啟動(dòng)時(shí)鏈接hbase的Master失敗導(dǎo)致啟動(dòng)失敗，從而無法進(jìn)行一些降級操作。

6、Scan查詢編程優(yōu)化：

1）調(diào)整caching；
2）如果是類似全表掃描這種查詢，或者定期的任務(wù)，則可以設(shè)置scan的setCacheBlocks為false，避免無用緩存；
3）關(guān)閉scanner，避免浪費(fèi)客戶端和服務(wù)器的內(nèi)存；
4）限定掃描范圍：指定列簇或者指定要查詢的列；
5)、如果只查詢r(jià)owkey時(shí)，則使用KeyOnlyFilter可大量減少網(wǎng)絡(luò)消耗；

7、對響應(yīng)時(shí)間有嚴(yán)格要求的在線實(shí)時(shí)系統(tǒng)，可以通過封裝hbase client api，通過線程池執(zhí)行g(shù)et等操作，通過Future.get()設(shè)置超時(shí)時(shí)間，超過時(shí)間沒有返回則執(zhí)行其它邏輯，實(shí)現(xiàn)快速失敗的效果。

作為hbase依賴的狀態(tài)協(xié)調(diào)者ZK和數(shù)據(jù)的存儲則HDFS，也需要調(diào)優(yōu)：

ZK調(diào)優(yōu)：

1、zookeeper.session.timeout：默認(rèn)值3分鐘，不可配置太短，避免session超時(shí)，hbase停止服務(wù)，線上生產(chǎn)環(huán)境由于配置為1分鐘，出現(xiàn)過2次該原因?qū)е碌膆base停止服務(wù)，也不可配置太長，如果太長，當(dāng)rs掛掉，zk不能快速知道，從而導(dǎo)致master不能及時(shí)對region進(jìn)行遷移。

2、zookeeper數(shù)量：至少5個(gè)節(jié)點(diǎn)。給每個(gè)zookeeper 1G左右的內(nèi)存，最好有獨(dú)立的磁盤。 (獨(dú)立磁盤可以確保zookeeper不受影響).如果集群負(fù)載很重，不要把Zookeeper和RegionServer運(yùn)行在同一臺機(jī)器上面。就像DataNodes 和 TaskTrackers一樣，只有超過半數(shù)的zk存在才會提供服務(wù)，比如：共5臺，則最多只運(yùn)行掛2臺，配置4臺與3臺一樣，最多只運(yùn)行掛1臺。

3、hbase.zookeeper.property.maxClientCnxns：zk的最大連接數(shù)，默認(rèn)為300，應(yīng)根據(jù)集群規(guī)模進(jìn)行調(diào)整。

hdf調(diào)優(yōu)：

1. dfs.name.dir： namenode的數(shù)據(jù)存放地址，可以配置多個(gè)，位于不同的磁盤并配置一個(gè)NFS遠(yuǎn)程文件系統(tǒng)，這樣nn的數(shù)據(jù)可以有多個(gè)備份

2. dfs.data.dir：dn數(shù)據(jù)存放地址，每個(gè)磁盤配置一個(gè)路徑，這樣可以大大提高并行讀寫的能力

3. dfs.namenode.handler.count：nn節(jié)點(diǎn)RPC的處理線程數(shù)，默認(rèn)為10，需提高，比如：60

4. dfs.datanode.handler.count：dn節(jié)點(diǎn)RPC的處理線程數(shù)，默認(rèn)為3，需提高，比如：20

5. dfs.datanode.max.xcievers：dn同時(shí)處理文件的上限，默認(rèn)為256，需提高，比如：8192

6. dfs.block.size：dn數(shù)據(jù)塊的大小，默認(rèn)為64M，如果存儲的文件均是比較大的文件則可以考慮調(diào)大，比如，在使用hbase時(shí)，可以設(shè)置為128M，注意單位是字節(jié)

7. dfs.balance.bandwidthPerSec：在通過start-balancer.sh做負(fù)載均衡時(shí)控制傳輸文件的速度，默認(rèn)為1M/s，可配置為幾十M/s，比如：20M/s

8. dfs.datanode.du.reserved：每塊磁盤保留的空余空間，應(yīng)預(yù)留一些給非hdfs文件使用，默認(rèn)值為0

9. dfs.datanode.failed.volumes.tolerated：在啟動(dòng)時(shí)會導(dǎo)致dn掛掉的壞磁盤數(shù)量，默認(rèn)為0，即有一個(gè)磁盤壞了，就掛掉dn，可以不調(diào)整。

以上是“HBase如何實(shí)現(xiàn)性能調(diào)優(yōu)”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

分享名稱：HBase如何實(shí)現(xiàn)性能調(diào)優(yōu)
地址分享：http://vcdvsql.cn/article46/gjgdhg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、服務(wù)器托管、網(wǎng)站改版、、微信小程序、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)