HBase性能調優

因官方BookPerformanceTuning部分章節沒有按配置項進行索引，不能達到快速查閱的效果。因此我以配置項驅動，從新整理了原文，並補充一些本身的理解，若有錯誤，歡迎指正。

配置優化

zookeeper.session.timeout
默認值：3分鐘（180000ms）
說明：RegionServer與Zookeeper間的鏈接超時時間。當超時時間到後，ReigonServer會被Zookeeper從RS集羣清單中移除，HMaster收到移除通知後，會對這臺server負責的regions從新balance，讓其餘存活的RegionServer接管.
調優：
這個timeout決定了RegionServer是否可以及時的failover。設置成1分鐘或更低，能夠減小因等待超時而被延長的failover時間。
不過須要注意的是，對於一些Online應用，RegionServer從宕機到恢復時間自己就很短的（網絡閃斷，crash等故障，運維可快速介入），若是調低timeout時間，反而會得不償失。由於當ReigonServer被正式從RS集羣中移除時，HMaster就開始作balance了（讓其餘RS根據故障機器記錄的WAL日誌進行恢復）。當故障的RS在人工介入恢復後，這個balance動做是毫無心義的，反而會使負載不均勻，給RS帶來更多負擔。特別是那些固定分配regions的場景。

hbase.regionserver.handler.count
默認值：10
說明：RegionServer的請求處理IO線程數。
調優：
這個參數的調優與內存息息相關。
較少的IO線程，適用於處理單次請求內存消耗較高的BigPUT場景（大容量單次PUT或設置了較大cache的scan，均屬於BigPUT）或ReigonServer的內存比較緊張的場景。
較多的IO線程，適用於單次請求內存消耗低，TPS要求很是高的場景。設置該值的時候，以監控內存爲主要參考。
這裏須要注意的是若是server的region數量不多，大量的請求都落在一個region上，因快速充滿memstore觸發flush致使的讀寫鎖會影響全局TPS，不是IO線程數越高越好。
壓測時，開啓EnablingRPC-levellogging，能夠同時監控每次請求的內存消耗和GC的情況，最後經過屢次壓測結果來合理調節IO線程數。
這裏是一個案例HadoopandHBaseOptimizationforReadIntensiveSearchApplications，做者在SSD的機器上設置IO線程數爲100，僅供參考。

hbase.hregion.max.filesize
默認值：256M
說明：在當前ReigonServer上單個Reigon的最大存儲空間，單個Region超過該值時，這個Region會被自動split成更小的region。
調優：
小region對split和compaction友好，由於拆分region或compact小region裏的storefile速度很快，內存佔用低。缺點是split和compaction會很頻繁。
特別是數量較多的小region不停地split,compaction，會致使集羣響應時間波動很大，region數量太多不只給管理上帶來麻煩，甚至會引起一些Hbase的bug。
通常512如下的都算小region。

大region，則不太適合常常split和compaction，由於作一次compact和split會產生較長時間的停頓，對應用的讀寫性能衝擊很是大。此外，大region意味着較大的storefile，compaction時對內存也是一個挑戰。
固然，大region也有其用武之地。若是你的應用場景中，某個時間點的訪問量較低，那麼在此時作compact和split，既能順利完成split和compaction，又能保證絕大多數時間平穩的讀寫性能。

既然split和compaction如此影響性能，有沒有辦法去掉？
compaction是沒法避免的，split卻是能夠從自動調整爲手動。
只要經過將這個參數值調大到某個很難達到的值，好比100G，就能夠間接禁用自動split（RegionServer不會對未到達100G的region作split）。
再配合RegionSplitter這個工具，在須要split時，手動split。
手動split在靈活性和穩定性上比起自動split要高不少，相反，管理成本增長很少，比較推薦online實時系統使用。

內存方面，小region在設置memstore的大小值上比較靈活，大region則過大太小都不行，過大會致使flush時app的IOwait增高，太小則因storefile過多影響讀性能。

hbase.regionserver.global.memstore.upperLimit/lowerLimit

默認值：0.4/0.35
upperlimit說明：hbase.hregion.memstore.flush.size這個參數的做用是當單個Region內全部的memstore大小總和超過指定值時，flush該region的全部memstore。RegionServer的flush是經過將請求添加一個隊列，模擬生產消費模式來異步處理的。那這裏就有一個問題，當隊列來不及消費，產生大量積壓請求時，可能會致使內存陡增，最壞的狀況是觸發OOM。
這個參數的做用是防止內存佔用過大，當ReigonServer內全部region的memstores所佔用內存總和達到heap的40%時，HBase會強制block全部的更新並flush這些region以釋放全部memstore佔用的內存。
lowerLimit說明：同upperLimit，只不過lowerLimit在全部region的memstores所佔用內存達到Heap的35%時，不flush全部的memstore。它會找一個memstore內存佔用最大的region，作個別flush，此時寫更新仍是會被block。lowerLimit算是一個在全部region強制flush致使性能下降前的補救措施。在日誌中，表現爲「**Flushthreadwokeupwithmemoryabovelowwater.」
調優：這是一個Heap內存保護參數，默認值已經能適用大多數場景。
參數調整會影響讀寫，若是寫的壓力大致使常常超過這個閥值，則調小讀緩存hfile.block.cache.size增大該閥值，或者Heap餘量較多時，不修改讀緩存大小。
若是在高壓狀況下，也沒超過這個閥值，那麼建議你適當調小這個閥值再作壓測，確保觸發次數不要太多，而後還有較多Heap餘量的時候，調大hfile.block.cache.size提升讀性能。
還有一種可能性是hbase.hregion.memstore.flush.size保持不變，但RS維護了過多的region，要知道region數量直接影響佔用內存的大小。

hfile.block.cache.size

默認值：0.2
說明：storefile的讀緩存佔用Heap的大小百分比，0.2表示20%。該值直接影響數據讀的性能。
調優：固然是越大越好，若是寫比讀少不少，開到0.4-0.5也沒問題。若是讀寫較均衡，0.3左右。若是寫比讀多，果斷默認吧。設置這個值的時候，你同時要參考hbase.regionserver.global.memstore.upperLimit，該值是memstore佔heap的最大百分比，兩個參數一個影響讀，一個影響寫。若是兩值加起來超過80-90%，會有OOM的風險，謹慎設置。

hbase.hstore.blockingStoreFiles

默認值：7
說明：在flush時，當一個region中的Store（CoulmnFamily）內有超過7個storefile時，則block全部的寫請求進行compaction，以減小storefile數量。
調優：block寫請求會嚴重影響當前regionServer的響應時間，但過多的storefile也會影響讀性能。從實際應用來看，爲了獲取較平滑的響應時間，可將值設爲無限大。若是能容忍響應時間出現較大的波峯波谷，那麼默認或根據自身場景調整便可。

hbase.hregion.memstore.block.multiplier

默認值：2
說明：當一個region裏的memstore佔用內存大小超過hbase.hregion.memstore.flush.size兩倍的大小時，block該region的全部請求，進行flush，釋放內存。
雖然咱們設置了region所佔用的memstores總內存大小，好比64M，但想象一下，在最後63.9M的時候，我Put了一個200M的數據，此時memstore的大小會瞬間暴漲到超過預期的hbase.hregion.memstore.flush.size的幾倍。這個參數的做用是當memstore的大小增至超過hbase.hregion.memstore.flush.size2倍時，block全部請求，遏制風險進一步擴大。
調優：這個參數的默認值仍是比較靠譜的。若是你預估你的正常應用場景（不包括異常）不會出現突發寫或寫的量可控，那麼保持默認值便可。若是正常狀況下，你的寫請求量就會常常暴長到正常的幾倍，那麼你應該調大這個倍數並調整其餘參數值，好比hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以預留更多內存，防止HBaseserverOOM。

hbase.hregion.memstore.mslab.enabled

默認值：true
說明：減小因內存碎片致使的FullGC，提升總體性能。
調優：詳見http://kenwublog.com/avoid-full-gc-in-hbase-using-arena-allocation

其餘

啓用LZO壓縮
LZO對比Hbase默認的GZip，前者性能較高，後者壓縮比較高，具體參見UsingLZOCompression。對於想提升HBase讀寫性能的開發者，採用LZO是比較好的選擇。對於很是在意存儲空間的開發者，則建議保持默認。

不要在一張表裏定義太多的ColumnFamily

Hbase目前不能良好的處理超過包含2-3個CF的表。由於某個CF在flush發生時，它鄰近的CF也會因關聯效應被觸發flush，最終致使系統產生更多IO。

批量導入

在批量導入數據到Hbase前，你能夠經過預先建立regions，來平衡數據的負載。詳見TableCreation:Pre-CreatingRegions

避免CMSconcurrentmodefailure

HBase使用CMSGC。默認觸發GC的時機是當年老代內存達到90%的時候，這個百分比由-XX:CMSInitiatingOccupancyFraction=N這個參數來設置。concurrentmodefailed發生在這樣一個場景：
當年老代內存達到90%的時候，CMS開始進行併發垃圾收集，於此同時，新生代還在迅速不斷地晉升對象到年老代。當年老代CMS還未完成併發標記時，年老代滿了，悲劇就發生了。CMS由於沒內存可用不得不暫停mark，並觸發一次stoptheworld（掛起全部jvm線程），而後採用單線程拷貝方式清理全部垃圾對象。這個過程會很是漫長。爲了不出現concurrentmodefailed，建議讓GC在未到90%時，就觸發。

經過設置-XX:CMSInitiatingOccupancyFraction=N

這個百分比，能夠簡單的這麼計算。若是你的hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit加起來有60%（默認），那麼你能夠設置70-80，通常高10%左右差很少。

Hbase客戶端優化

AutoFlush

將HTable的setAutoFlush設爲false，能夠支持客戶端批量更新。即當Put填滿客戶端flush緩存時，才發送到服務端。
默認是true。

ScanCaching

scanner一次緩存多少數據來scan（從服務端一次抓多少數據回來scan）。
默認值是1，一次只取一條。

ScanAttributeSelection

scan時建議指定須要的ColumnFamily，減小通訊量，不然scan操做默認會返回整個row的全部數據（全部CoulmnFamily）。

CloseResultScanners

經過scan取完數據後，記得要關閉ResultScanner，不然RegionServer可能會出現問題（對應的Server資源沒法釋放）。

OptimalLoadingofRowKeys

當你scan一張表的時候，返回結果只須要rowkey（不須要CF,qualifier,values,timestaps）時，你能夠在scan實例中添加一個filterList，並設置MUST_PASS_ALL操做，filterList中addFirstKeyOnlyFilter或KeyOnlyFilter。這樣能夠減小網絡通訊量。

TurnoffWALonPuts

當Put某些非重要數據時，你能夠設置writeToWAL(false)，來進一步提升寫性能。writeToWAL(false)會在Put時放棄寫WALlog。風險是，當RegionServer宕機時，可能你剛纔Put的那些數據會丟失，且沒法恢復。

啓用BloomFilter

BloomFilter經過空間換時間，提升讀操做性能。

轉載請註明原文連接：http://kenwublog.com/hbase-performance-tuning

感謝嬴北望同窗對」hbase.hregion.memstore.flush.size」和「hbase.hstore.blockingStoreFiles」錯誤觀點的修正。