hbase如何優化配置

這篇文章主要為大家展示了“hbase如何優化配置”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“hbase如何優化配置”這篇文章吧。

配置優化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線程，適用于處理單次請求內存消耗較高的Big PUT場景（大容量單次PUT或設置了較大cache的scan，均屬于Big PUT）或ReigonServer的內存比較緊張的場景。
較多的IO線程，適用于單次請求內存消耗低，TPS要求非常高的場景。設置該值的時候，以監控內存為主要參考。
這里需要注意的是如果server的region數量很少，大量的請求都落在一個region上，因快速充滿memstore觸發flush導致的讀寫鎖會影響全局TPS，不是IO線程數越高越好。
壓測時，開啟Enabling RPC-level logging，可以同時監控每次請求的內存消耗和GC的狀況，最后通過多次壓測結果來合理調節IO線程數。
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的IO wait增高，過小則因store file過多影響讀性能。

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導致性能降低前的補救措施。在日志中，表現為 “** Flush thread woke up with memory above low water.”
調優：這是一個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（Coulmn Family）內有超過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.size 2倍時，block所有請求，遏制風險進一步擴大。
調優： 這個參數的默認值還是比較靠譜的。如果你預估你的正常應用場景（不包括異常）不會出現突發寫或寫的量可控，那么保持默認值即可。如果正常情況下，你的寫請求量就會經常暴長到正常的幾倍，那么你應該調大這個倍數并調整其他參數值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以預留更多內存，防止HBase server OOM。

hbase.hregion.memstore.mslab.enabled
默認值：true


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

不要在一張表里定義太多的Column Family
Hbase目前不能良好的處理超過包含2-3個CF的表。因為某個CF在flush發生時，它鄰近的CF也會因關聯效應被觸發flush，最終導致系統產生更多IO。

批量導入
在批量導入數據到Hbase前，你可以通過預先創建regions，來平衡數據的負載。詳見 Table Creation: Pre-Creating Regions

避免CMS concurrent mode failure
HBase使用CMS GC。默認觸發GC的時機是當年老代內存達到90%的時候，這個百分比由 -XX:CMSInitiatingOccupancyFraction=N 這個參數來設置。concurrent mode failed發生在這樣一個場景：
當年老代內存達到90%的時候，CMS開始進行并發垃圾收集，于此同時，新生代還在迅速不斷地晉升對象到年老代。當年老代CMS還未完成并發標記時，年老代滿了，悲劇就發生了。CMS因為沒內存可用不得不暫停mark，并觸發一次stop the world（掛起所有jvm線程），然后采用單線程拷貝方式清理所有垃圾對象。這個過程會非常漫長。為了避免出現concurrent mode failed，建議讓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。

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

Scan Attribute Selection
scan時建議指定需要的Column Family，減少通信量，否則scan操作默認會返回整個row的所有數據（所有Coulmn Family）。

Close ResultScanners
通過scan取完數據后，記得要關閉ResultScanner，否則RegionServer可能會出現問題（對應的Server資源無法釋放）。

Optimal Loading of Row Keys
當你scan一張表的時候，返回結果只需要row key（不需要CF, qualifier,values,timestaps）時，你可以在scan實例中添加一個filterList，并設置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。這樣可以減少網絡通信量。

Turn off WAL on Puts
當Put某些非重要數據時，你可以設置writeToWAL(false)，來進一步提高寫性能。writeToWAL(false)會在Put時放棄寫WAL log。風險是，當RegionServer宕機時，可能你剛才Put的那些數據會丟失，且無法恢復。

啟用Bloom Filter
Bloom Filter通過空間換時間，提高讀操作性能。

以上是“hbase如何優化配置”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！