一、服務(wù)端調(diào)優(yōu)

1、參數(shù)配置

1)、hbase.regionserver.handler.count：該設(shè)置決定了處理RPC的線程數(shù)量，默認(rèn)值是10，通?？梢哉{(diào)大，比如：150，當(dāng)請求內(nèi)容很大(上MB，比如大的put、使用緩存的scans)的時(shí)候，如果該值設(shè)置過大則會占用過多的內(nèi)存，導(dǎo)致頻繁的GC，或者出現(xiàn)OutOfMemory，因此該值不是越大越好。

2)、hbase.hregion.max.filesize ：配置region大小，0.94.12版本默認(rèn)是10G，region的大小與集群支持的總數(shù)據(jù)量有關(guān)系，如果總數(shù)據(jù)量小，則單個(gè)region太大，不利于并行的數(shù)據(jù)處理，如果集群需支持的總數(shù)據(jù)量比較大，region太小，則會導(dǎo)致region的個(gè)數(shù)過多，導(dǎo)致region的管理等成本過高，如果一個(gè)RS配置的磁盤總量為3T*12=36T數(shù)據(jù)量，數(shù)據(jù)復(fù)制3份，則一臺RS服務(wù)器可以存儲10T的數(shù)據(jù)，如果每個(gè)region最大為10G，則最多1000個(gè)region，如此看，94.12的這個(gè)默認(rèn)配置還是比較合適的，不過如果要自己管理split，則應(yīng)該調(diào)大該值，并且在建表時(shí)規(guī)劃好region數(shù)量和rowkey設(shè)計(jì)，進(jìn)行region預(yù)建，做到一定時(shí)間內(nèi)，每個(gè)region的數(shù)據(jù)大小在一定的數(shù)據(jù)量之下，當(dāng)發(fā)現(xiàn)有大的region，或者需要對整個(gè)表進(jìn)行region擴(kuò)充時(shí)再進(jìn)行split操作，一般提供在線服務(wù)的hbase集群均會棄用hbase的自動(dòng)split，轉(zhuǎn)而自己管理split。

3)、hbase.hregion.majorcompaction：配置major合并的間隔時(shí)間，默認(rèn)為1天，可設(shè)置為0，禁止自動(dòng)的major合并，可手動(dòng)或者通過腳本定期進(jìn)行major合并，有兩種compact：minor和major，minor通常會把數(shù)個(gè)小的相鄰的storeFile合并成一個(gè)大的storeFile，minor不會刪除標(biāo)示為刪除的數(shù)據(jù)和過期的數(shù)據(jù)，major會刪除需刪除的數(shù)據(jù)，major合并之后，一個(gè)store只有一個(gè)storeFile文件，會對store的所有數(shù)據(jù)進(jìn)行重寫，有較大的性能消耗。

4)、hbase.hstore.compactionThreshold：HStore的storeFile數(shù)量>= compactionThreshold配置的值，則可能會進(jìn)行compact，默認(rèn)值為3，可以調(diào)大，比如設(shè)置為6，在定期的major compact中進(jìn)行剩下文件的合并。

5)、 hbase.hstore.blockingStoreFiles：HStore的storeFile的文件數(shù)大于配置值，則在flush memstore前先進(jìn)行split或者compact，除非超過hbase.hstore.blockingWaitTime配置的時(shí)間，默認(rèn)為7，可調(diào)大，比如：100，避免memstore不及時(shí)flush，當(dāng)寫入量大時(shí)，觸發(fā)memstore的block，從而阻塞寫操作。

6)、hbase.regionserver.global.memstore.upperLimit：默認(rèn)值0.4，RS所有memstore占用內(nèi)存在總內(nèi)存中的upper比例，當(dāng)達(dá)到該值，則會從整個(gè)RS中找出最需要flush的region進(jìn)行flush，直到總內(nèi)存比例降至該數(shù)限制以下，并且在降至限制比例以下前將阻塞所有的寫memstore的操作，在以寫為主的集群中，可以調(diào)大該配置項(xiàng)，不建議太大，因?yàn)閎lock cache和memstore cache的總大小不會超過0.8，而且不建議這兩個(gè)cache的大小總和達(dá)到或者接近0.8，避免OOM，在偏向?qū)懙臉I(yè)務(wù)時(shí)，可配置為0.45，memstore.lowerLimit保持0.35不變，在偏向讀的業(yè)務(wù)中，可調(diào)低為0.35，同時(shí)memstore.lowerLimit調(diào)低為0.3，或者再向下0.05個(gè)點(diǎn)，不能太低，除非只有很小的寫入操作，如果是兼顧讀寫，則采用默認(rèn)值即可。

7)、hbase.regionserver.global.memstore.lowerLimit：默認(rèn)值0.35，RS的所有memstore占用內(nèi)存在總內(nèi)存中的lower比例，當(dāng)達(dá)到該值，則會從整個(gè)RS中找出最需要flush的region進(jìn)行flush，配置時(shí)需結(jié)合memstore.upperLimit和block cache的配置。

8)、file.block.cache.size：RS的block cache的內(nèi)存大小限制，默認(rèn)值0.25，在偏向讀的業(yè)務(wù)中，可以適當(dāng)調(diào)大該值，具體配置時(shí)需試hbase集群服務(wù)的業(yè)務(wù)特征，結(jié)合memstore的內(nèi)存占比進(jìn)行綜合考慮。

9)、hbase.hregion.memstore.flush.size：默認(rèn)值128M，單位字節(jié)，超過將被flush到hdfs，該值比較適中，一般不需要調(diào)整。

10)、hbase.hregion.memstore.block.multiplier：默認(rèn)值2，如果memstore的內(nèi)存大小已經(jīng)超過了hbase.hregion.memstore.flush.size的2倍，則會阻塞memstore的寫操作，直到降至該值以下，為避免發(fā)生阻塞，最好調(diào)大該值，比如：4，不可太大，如果太大，則會增大導(dǎo)致整個(gè)RS的memstore內(nèi)存超過memstore.upperLimit限制的可能性，進(jìn)而增大阻塞整個(gè)RS的寫的幾率。如果region發(fā)生了阻塞會導(dǎo)致大量的線程被阻塞在到該region上，從而其它region的線程數(shù)會下降，影響整體的RS服務(wù)能力，例如：

開始阻塞：

解開阻塞：

從10分11秒開始阻塞到10分20秒解開，總耗時(shí)9秒，在這9秒中無法寫入，并且這期間可能會占用大量的RS handler線程，用于其它region或者操作的線程數(shù)會逐漸減少，從而影響到整體的性能，也可以通過異步寫，并限制寫的速度，避免出現(xiàn)阻塞。

11)、hfile.block.index.cacheonwrite：在index寫入的時(shí)候允許put無根(non-root)的多級索引塊到block cache里，默認(rèn)是false，設(shè)置為true，或許讀性能更好，但是是否有副作用還需調(diào)查。

12)、io.storefile.bloom.cacheonwrite：默認(rèn)為false，需調(diào)查其作用。

13)、hbase.regionserver.regionSplitLimit：控制最大的region數(shù)量，超過則不可以進(jìn)行split操作，默認(rèn)是Integer.MAX，可設(shè)置為1，禁止自動(dòng)的split，通過人工，或者寫腳本在集群空閑時(shí)執(zhí)行。如果不禁止自動(dòng)的split，則當(dāng)region大小超過hbase.hregion.max.filesize時(shí)會觸發(fā)split操作(具體的split有一定的策略，不僅僅通過該參數(shù)控制，前期的split會考慮region數(shù)據(jù)量和memstore大小)，每次flush或者compact之后，regionserver都會檢查是否需要Split，split會先下線老region再上線split后的region，該過程會很快，但是會存在兩個(gè)問題：1、老region下線后，新region上線前client訪問會失敗，在重試過程中會成功但是如果是提供實(shí)時(shí)服務(wù)的系統(tǒng)則響應(yīng)時(shí)長會增加；2、split后的compact是一個(gè)比較耗資源的動(dòng)作。

14)、Jvm調(diào)整

a、內(nèi)存大小:master默認(rèn)為1G，可增加到2G，regionserver默認(rèn)1G，可調(diào)大到10G，或者更大，zk并不耗資源，可以不用調(diào)整；

b、垃圾回收:待研究。

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

1)、列族、rowkey要盡量短，每個(gè)cell值均會存儲一次列族名稱和rowkey，甚至列名稱也要盡量短，以下截圖是表test2的數(shù)據(jù)和存入hdfs后的文件內(nèi)容：

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

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)決定了一次最多100條，則可以設(shè)置為100

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ò)消耗；

作為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，可配置上千

hdfs調(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)整。

總結(jié)

以上是生活随笔為你收集整理的hbase 读写调优_hbase优化操作与建议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。