光能夠搭建和使用Hbase是遠遠不夠的，通過修改各種配置文件和資源對Hbase進行性能調優，使運行效率達到最高才是我們的最終目的。所以今天我們再來說說Hbase調優的幾條小建議。
一、修改Linux最大文件數
Linux系統最大可打開文件數一般默認的參數值是1024，如果你不進行修改併發量上來的時候會出現“Too Many Open Files”的錯誤，導致整個HBase不可運行
查看： ulimit -a 結果：open files (-n) 1024
臨時修改： ulimit -n 4096
持久修改：
vi /etc/security/limits.conf在文件最後加上：
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
二、修改 JVM 配置
修改hbase-env.sh文件中的配置參數
HBASE_HEAPSIZE 4000 #HBase使用的 JVM 堆的大小
HBASE_OPTS "‐server ‐XX:+UseConcMarkSweepGC" #JVM GC 選項
參數解釋：
-client，-server
這兩個參數用於設置虛擬機使用何種運行模式，client模式啓動比較快，但運行時性能和內存管理效率不如server模式，通常用於客戶端應用程序。相反，server模式啓動比client慢，但可獲得更高的運行性能。
‐XX:+UseConcMarkSweepGC：設置爲併發收集策略
三、修改HBase配置：hbase-site.xml
1、zookeeper.session.timeout
默認值：3分鐘（180000ms）,可以改成1分鐘
說明：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的場景。
2、hbase.regionserver.handler.count
默認值：10
說明：RegionServer的請求處理IO線程數。
調優：
這個參數的調優與內存息息相關。
較少的IO線程，適用於處理單次請求內存消耗較高的Big PUT場景（大容量單次PUT或設置了較大cache的scan，均屬於Big PUT）或ReigonServer的內存比較緊張的場景。
較多的IO線程，適用於單次請求內存消耗低，TPS（吞吐量）要求非常高的場景。
3、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會產生較長時間的停頓，對應用的讀寫性能衝擊非常大。
4、hfile.block.cache.size
默認值：0.2
說明：storefile的讀緩存佔用內存的大小百分比，0.2表示20%。該值直接影響數據讀的性能。
調優：當然是越大越好，如果寫比讀少很多，開到0.4-0.5也沒問題。如果讀寫較均衡，0.3左右。如果寫比讀多，果斷默認吧。
HBase上Regionserver的內存分爲兩個部分，一部分作爲Memstore，主要用來寫；另外一部分作爲BlockCache，主要用於讀。
寫請求會先寫入Memstore，Regionserver會給每個region提供一個Memstore，當Memstore滿64MB以後，會啓動 flush刷新到磁盤。
讀請求先到Memstore中查數據，查不到就到BlockCache中查，再查不到就會到磁盤上讀，並把讀的結果放入BlockCache。由於BlockCache採用的是LRU策略（Least Recently Used 近期最少使用算法），因此BlockCache達到上限(heapsize * hfile.block.cache.size * 0.85)後，會啓動淘汰機制，淘汰掉最老的一批數據。
一個Regionserver上有一個BlockCache和N個Memstore，它們的大小之和不能大於等於內存 * 0.8，否則HBase不能啓動。默認BlockCache爲0.2，而Memstore爲0.4。對於注重讀響應時間的系統，可以將 BlockCache設大些，比如設置BlockCache=0.4，Memstore=0.39，以加大緩存的命中率。
5、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所有請求，遏制風險進一步擴大。
調優： 這個參數的默認值還是比較靠譜的。如果你預估你的正常應用場景（不包括異常）不會出現突發寫或寫的量可控，那麼保持默認值即可
更多優化方法可以參考以下博文：
https://www.jianshu.com/p/3832ae37fac4
https://blog.csdn.net/yueyedeai/article/details/14648111
喜歡的朋友點個關注唄~~