hbase優化操做與建議

 

1、服務端調優

　　一、參數配置
　　　　1）、hbase.regionserver.handler.count：該設置決定了處理RPC的線程數量，默認值是10，一般能夠調大，好比：150，當請求內容很大（上MB，好比大的put、使用緩存的scans）的時候，若是該值設置過大則會佔用過多的內存，致使頻繁的GC，或者出現OutOfMemory，所以該值不是越大越好。

 

　　　　2）、hbase.hregion.max.filesize ：配置region大小，0.94.12版本默認是10G，region的大小與集羣支持的總數據量有關係，若是總數據量小，則單個region太大，不利於並行的數據處理，若是集羣需支持的總數據量比較大，region過小，則會致使region的個數過多，致使region的管理等成本太高，若是一個RS配置的磁盤總量爲3T*12=36T數據量，數據複製3份，則一臺RS服務器能夠存儲10T的數據，若是每一個region最大爲10G，則最多1000個region，如此看，94.12的這個默認配置仍是比較合適的，不過若是要本身管理split，則應該調大該值，而且在建表時規劃好region數量和rowkey設計，進行region預建，作到必定時間內，每一個region的數據大小在必定的數據量之下，當發現有大的region，或者須要對整個表進行region擴充時再進行split操做，通常提供在線服務的hbase集羣均會棄用hbase的自動split，轉而本身管理split。

 

　　　　3）、hbase.hregion.majorcompaction：配置major合併的間隔時間，默認爲1天，可設置爲0，禁止自動的major合併，可手動或者經過腳本按期進行major合併，有兩種compact：minor和major，minor一般會把數個小的相鄰的storeFile合併成一個大的storeFile，minor不會刪除標示爲刪除的數據和過時的數據，major會刪除需刪除的數據，major合併以後，一個store只有一個storeFile文件，會對store的全部數據進行重寫，有較大的性能消耗。

 

　　　　4）、hbase.hstore.compactionThreshold：HStore的storeFile數量>= compactionThreshold配置的值，則可能會進行compact，默認值爲3，能夠調大，好比設置爲6，在按期的major compact中進行剩下文件的合併。

 

　　　　5）、 hbase.hstore.blockingStoreFiles：HStore的storeFile的文件數大於配置值，則在flush memstore前先進行split或者compact，除非超過hbase.hstore.blockingWaitTime配置的時間，默認爲7，可調大，好比：100，避免memstore不及時flush，當寫入量大時，觸發memstore的block，從而阻塞寫操做。

 

　　　　6）、hbase.regionserver.global.memstore.upperLimit：默認值0.4，RS全部memstore佔用內存在總內存中的upper比例，當達到該值，則會從整個RS中找出最須要flush的region進行flush，直到總內存比例降至該數限制如下，而且在降至限制比例如下前將阻塞全部的寫memstore的操做，在以寫爲主的集羣中，能夠調大該配置項，不建議太大，由於block cache和memstore cache的總大小不會超過0.8，並且不建議這兩個cache的大小總和達到或者接近0.8，避免OOM，在偏向寫的業務時，可配置爲0.45，memstore.lowerLimit保持0.35不變，在偏向讀的業務中，可調低爲0.35，同時memstore.lowerLimit調低爲0.3，或者再向下0.05個點，不能過低，除非只有很小的寫入操做，若是是兼顧讀寫，則採用默認值便可。

 

　　　　7）、hbase.regionserver.global.memstore.lowerLimit：默認值0.35，RS的全部memstore佔用內存在總內存中的lower比例，當達到該值，則會從整個RS中找出最須要flush的region進行flush，配置時需結合memstore.upperLimit和block cache的配置。

 

　　　　8）、file.block.cache.size：RS的block cache的內存大小限制，默認值0.25，在偏向讀的業務中，能夠適當調大該值，具體配置時需試hbase集羣服務的業務特徵，結合memstore的內存佔比進行綜合考慮。

 

　　　　9）、hbase.hregion.memstore.flush.size：默認值128M，單位字節，超過將被flush到hdfs，該值比較適中，通常不須要調整。

 

　　　　10）、hbase.hregion.memstore.block.multiplier：默認值2，若是memstore的內存大小已經超過了hbase.hregion.memstore.flush.size的2倍，則會阻塞memstore的寫操做，直到降至該值如下，爲避免發生阻塞，最好調大該值，好比：4，不可太大，若是太大，則會增大致使整個RS的memstore內存超過memstore.upperLimit限制的可能性，進而增大阻塞整個RS的寫的概率。若是region發生了阻塞會致使大量的線程被阻塞在到該region上，從而其它region的線程數會降低，影響總體的RS服務能力，例如：

　　　　開始阻塞：　　

　　　　

　　解開阻塞：

　　　　

　　從10分11秒開始阻塞到10分20秒解開，總耗時9秒，在這9秒中沒法寫入，而且這期間可能會佔用大量的RS handler線程，用於其它region或者操做的線程數會逐漸減小，從而影響到總體的性能，也能夠經過異步寫，並限制寫的速度，避免出現阻塞。

 

　　　　11）、hfile.block.index.cacheonwrite：在index寫入的時候容許put無根（non-root）的多級索引塊到block cache裏，默認是false，設置爲true，或許讀性能更好，可是是否有反作用還需調查。

 

　　　　12）、io.storefile.bloom.cacheonwrite：默認爲false，需調查其做用。

 

　　　　13）、hbase.regionserver.regionSplitLimit：控制最大的region數量，超過則不能夠進行split操做，默認是Integer.MAX，可設置爲1，禁止自動的split，經過人工，或者寫腳本在集羣空閒時執行。若是不由止自動的split，則當region大小超過hbase.hregion.max.filesize時會觸發split操做（具體的split有必定的策略，不只僅經過該參數控制，前期的split會考慮region數據量和memstore大小），每次flush或者compact以後，regionserver都會檢查是否須要Split，split會先下線老region再上線split後的region，該過程會很快，可是會存在兩個問題：一、老region下線後，新region上線前client訪問會失敗，在重試過程當中會成功可是若是是提供實時服務的系統則響應時長會增長；二、split後的compact是一個比較耗資源的動做。

 

　　　　14）、Jvm調整
　　　　　　a、內存大小:master默認爲1G，可增長到2G，regionserver默認1G，可調大到10G，或者更大，zk並不耗資源，能夠不用調整；
　　　　　　b、垃圾回收:待研究。

 

　　二、其它調優

　　　　1）、列族、rowkey要儘可能短，每一個cell值均會存儲一次列族名稱和rowkey，甚至列名稱也要儘可能短，如下截圖是表test2的數據和存入hdfs後的文件內容：

　　　　　　

                     

　　　　由上圖可見：短的列族名稱、rowkey、列名稱對最終的文件內容大小影響很大。

　　　　　　　

　　　　2）、RS的region數量：通常每一個RegionServer不要過1000，過多的region會致使產生較多的小文件，從而致使更多的compact，當有大量的超過5G的region而且RS總region數達到1000時，應該考慮擴容。

　　　　3）、建表時：
　　　　　　a、若是不須要多版本，則應設置version=1；
　　　　　　b、開啓lzo或者snappy壓縮，壓縮會消耗必定的CPU，可是，磁盤IO和網絡IO將得到極大的改善，大體能夠壓縮4~5倍；
　　　　　　c、合理的設計rowkey，在設計rowkey時需充分的理解現有業務併合理預見將來業務，不合理的rowkey設計將致使極差的hbase操做性能；
　　　　　　d、合理的規劃數據量，進行預分區，避免在表使用過程當中的不斷split，並把數據的讀寫分散到不一樣的RS，充分的發揮集羣的做用；
　　　　　　e、列族名稱儘可能短，好比：「f」，而且儘可能只有一個列族；
　　　　　　f、視場景開啓bloomfilter，優化讀性能。

 

2、Client端調優

 

　　一、hbase.client.write.buffer：寫緩存大小，默認爲2M，推薦設置爲6M，單位是字節，固然不是越大越好，若是太大，則佔用的內存太多；

　　二、hbase.client.scanner.caching：scan緩存，默認爲1，過小，可根據具體的業務特徵進行配置，原則上不可太大，避免佔用過多的client和rs的內存，通常最大幾百，若是一條數據太大，則應該設置一個較小的值，一般是設置業務需求的一次查詢的數據條數，好比：業務特色決定了一次最多100條，則能夠設置爲100

　　三、設置合理的超時時間和重試次數，具體的內容會在後續的blog中詳細講解。

　　四、client應用讀寫分離
　　　　讀和寫分離，位於不一樣的tomcat實例，數據先寫入redis隊列，再異步寫入hbase，若是寫失敗再回存redis隊列，先讀redis緩存的數據（若是有緩存，須要注意這裏的redis緩存不是redis隊列），若是沒有讀到再讀hbase。
　　　　當hbase集羣不可用，或者某個RS不可用時，由於HBase的重試次數和超時時間均比較大（爲保證正常的業務訪問，不可能調整到比較小的值，若是一個RS掛了，一次讀或者寫，通過若干重試和超時可能會持續幾十秒，或者幾分鐘），因此一次操做可能會持續很長時間，致使tomcat線程被一個請求長時間佔用，tomcat的線程數有限，會被快速佔完，致使沒有空餘線程作其它操做，讀寫分離後，寫因爲採用先寫redis隊列，再異步寫hbase，所以不會出現tomcat線程被佔滿的問題， 應用還能夠提供寫服務，若是是充值等業務，則不會損失收入，而且讀服務出現tomcat線程被佔滿的時間也會變長一些，若是運維介入及時，則讀服務影響也比較有限。

　　五、若是把org.apache.hadoop.hbase.client.HBaseAdmin配置爲spring的bean，則需配置爲懶加載，避免在啓動時連接hbase的Master失敗致使啓動失敗，從而沒法進行一些降級操做。

　　六、Scan查詢編程優化：
　　　　1）、調整caching；
　　　　2）、若是是相似全表掃描這種查詢，或者按期的任務，則能夠設置scan的setCacheBlocks爲false，避免無用緩存；
　　　　3）、關閉scanner，避免浪費客戶端和服務器的內存；
　　　　4）、限定掃描範圍：指定列簇或者指定要查詢的列；
　　　　5)、若是隻查詢rowkey時，則使用KeyOnlyFilter可大量減小網絡消耗；

做爲hbase依賴的狀態協調者ZK和數據的存儲則HDFS，也須要調優：

ZK調優：
　　一、zookeeper.session.timeout：默認值3分鐘，不可配置過短，避免session超時，hbase中止服務，線上生產環境因爲配置爲1分鐘，出現過2次該緣由致使的hbase中止服務，也不可配置太長，若是太長，當rs掛掉，zk不能快速知道，從而致使master不能及時對region進行遷移。

　　二、zookeeper數量：至少5個節點。給每一個zookeeper 1G左右的內存，最好有獨立的磁盤。 (獨立磁盤能夠確保zookeeper不受影響).若是集羣負載很重，不要把Zookeeper和RegionServer運行在同一臺機器上面。就像DataNodes 和 TaskTrackers同樣，只有超過半數的zk存在纔會提供服務，好比：共5臺，則最多隻運行掛2臺，配置4臺與3臺同樣，最多隻運行掛1臺。

　　三、hbase.zookeeper.property.maxClientCnxns：zk的最大鏈接數，默認爲300，可配置上千

hdfs調優：

　　一、dfs.name.dir： namenode的數據存放地址，能夠配置多個，位於不一樣的磁盤並配置一個NFS遠程文件系統，這樣nn的數據能夠有多個備份

　　二、dfs.data.dir：dn數據存放地址，每一個磁盤配置一個路徑，這樣能夠大大提升並行讀寫的能力

　　三、dfs.namenode.handler.count：nn節點RPC的處理線程數，默認爲10，需提升，好比：60

　　四、dfs.datanode.handler.count：dn節點RPC的處理線程數，默認爲3，需提升，好比：20

　　五、dfs.datanode.max.xcievers：dn同時處理文件的上限，默認爲256，需提升，好比：8192

　　六、dfs.block.size：dn數據塊的大小，默認爲64M，若是存儲的文件均是比較大的文件則能夠考慮調大，好比，在使用hbase時，能夠設置爲128M，注意單位是字節

　　七、dfs.balance.bandwidthPerSec：在經過start-balancer.sh作負載均衡時控制傳輸文件的速度，默認爲1M/s，可配置爲幾十M/s，好比：20M/s

　　八、dfs.datanode.du.reserved：每塊磁盤保留的空餘空間，應預留一些給非hdfs文件使用，默認值爲0

　　九、dfs.datanode.failed.volumes.tolerated：在啓動時會致使dn掛掉的壞磁盤數量，默認爲0，即有一個磁盤壞了，就掛掉dn，能夠不調整。

 

本文檔轉載自 HBase性能調優