Hbase萬億級存儲性能優化總結

hbase主集羣在生產環境已穩定運行有1年半時間，最大的單表region數已達7200多個，天天新增入庫量就有百億條，對hbase的認識經歷了懵懂到熟的過程。爲了應對業務數據的壓力，hbase入庫也由最初的單機多線程升級爲有容災機制的分佈式入庫，爲及早發現集羣中的問題，還開發了一套對hbase集羣服務和應用全面監控的報警系統。總結下hbase優化(針對0.94版本)方面的一些經驗也算對這兩年hbase工做的一個描述。

服務端

1.hbase.regionserver.handler.count：rpc請求的線程數量，默認值是10，生產環境建議使用100，也不是越大越好，特別是當請求內容很大的時候，好比scan/put幾M的數據，會佔用過多的內存，有可能致使頻繁的GC，甚至出現內存溢出。

2.hbase.master.distributed.log.splitting：默認值爲true，建議設爲false。關閉hbase的分佈式日誌切割，在log須要replay時，由master來負責重放

3.hbase.regionserver.hlog.splitlog.writer.threads：默認值是3，建議設爲10，日誌切割所用的線程數

4.hbase.snapshot.enabled：快照功能，默認是false(不開啓)，建議設爲true，特別是對某些關鍵的表，定時用快照作備份是一個不錯的選擇。

5.hbase.hregion.max.filesize：默認是10G， 若是任何一個column familiy裏的StoreFile超過這個值, 那麼這個Region會一分爲二，由於region分裂會有短暫的region下線時間(一般在5s之內)，爲減小對業務端的影響，建議手動定時分裂，能夠設置爲60G。

6.hbase.hregion.majorcompaction：hbase的region主合併的間隔時間，默認爲1天，建議設置爲0，禁止自動的major主合併，major合併會把一個store下全部的storefile重寫爲一個storefile文件，在合併過程當中還會把有刪除標識的數據刪除，在生產集羣中，主合併能持續數小時之久，爲減小對業務的影響，建議在業務低峯期進行手動或者經過腳本或者api按期進行major合併。

7.hbase.hregion.memstore.flush.size：默認值128M，單位字節，一旦有memstore超過該值將被flush，若是regionserver的jvm內存比較充足(16G以上)，能夠調整爲256M。

8.hbase.hregion.memstore.block.multiplier：默認值2，若是一個memstore的內存大小已經超過hbase.hregion.memstore.flush.size *  hbase.hregion.memstore.block.multiplier，則會阻塞該memstore的寫操做，爲避免阻塞，建議設置爲5，若是太大，則會有OOM的風險。若是在regionserver日誌中出現"Blocking updates for '<threadName>' on region <regionName> : memstore size <多少M> is >= than blocking <多少M> size"的信息時，說明這個值該調整了。

9.hbase.hstore.compaction.min：默認值爲3，若是任何一個store裏的storefile總數超過該值，會觸發默認的合併操做，能夠設置5~8，在手動的按期major compact中進行storefile文件的合併，減小合併的次數，不過這會延長合併的時間，之前的對應參數爲hbase.hstore.compactionThreshold。

10.hbase.hstore.compaction.max：默認值爲10,一次最多合併多少個storefile，避免OOM。

11.hbase.hstore.blockingStoreFiles：默認爲7，若是任何一個store(非.META.表裏的store)的storefile的文件數大於該值，則在flush memstore前先進行split或者compact，同時把該region添加到flushQueue，延時刷新，這期間會阻塞寫操做直到compact完成或者超過hbase.hstore.blockingWaitTime(默認90s)配置的時間，能夠設置爲30，避免memstore不及時flush。當regionserver運行日誌中出現大量的「Region <regionName> has too many store files; delaying flush up to 90000ms"時，說明這個值須要調整了

12.hbase.regionserver.global.memstore.upperLimit：默認值0.4，regionserver全部memstore佔用內存在總內存中的upper比例，當達到該值，則會從整個regionserver中找出最須要flush的region進行flush，直到總內存比例降到該數如下，採用默認值便可。

13.hbase.regionserver.global.memstore.lowerLimit：默認值0.35，採用默認值便可。

14.hbase.regionserver.thread.compaction.small：默認值爲1，regionserver作Minor Compaction時線程池裏線程數目,能夠設置爲5。

15.hbase.regionserver.thread.compaction.large：默認值爲1，regionserver作Major Compaction時線程池裏線程數目，能夠設置爲8。

16.hbase.regionserver.lease.period：默認值60000(60s)，客戶端鏈接regionserver的租約超時時間，客戶端必須在這個時間內彙報，不然則認爲客戶端已死掉。這個最好根據實際業務狀況進行調整

17.hfile.block.cache.size：默認值0.25，regionserver的block cache的內存大小限制，在偏向讀的業務中，能夠適當調大該值，須要注意的是hbase.regionserver.global.memstore.upperLimit的值和hfile.block.cache.size的值之和必須小於0.8。

18.dfs.socket.timeout：默認值60000(60s)，建議根據實際regionserver的日誌監控發現了異常進行合理的設置，好比咱們設爲900000，這個參數的修改須要同時更改hdfs-site.xml

19.dfs.datanode.socket.write.timeout：默認480000(480s),有時regionserver作合併時，可能會出現datanode寫超時的狀況，480000 millis timeout while waiting for channel to be ready for write，這個參數的修改須要同時更改hdfs-site.xml

jvm和垃圾收集參數：

export HBASE_REGIONSERVER_OPTS="-Xms36g -Xmx36g -Xmn1g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=15 -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/data/logs/gc-$(hostname)-hbase.log"

因爲咱們服務器內存較大(96G),咱們給一部分regionserver的jvm內存開到64G，到如今爲止，尚未發生過一次full gc，hbase在內存使用控制方面確實下了很多功夫，好比各類blockcache的實現，細心的同窗能夠看源碼。

Client端

1.hbase.client.write.buffer：默認爲2M，寫緩存大小，推薦設置爲5M，單位是字節，固然越大佔用的內存越多，此外測試過設爲10M下的入庫性能，反而沒有5M好

2.hbase.client.pause：默認是1000(1s),若是你但願低延時的讀或者寫，建議設爲200，這個值一般用於失敗重試，region尋找等

3.hbase.client.retries.number：默認值是10，客戶端最多重試次數,能夠設爲11，結合上面的參數，共重試時間71s

4.hbase.ipc.client.tcpnodelay：默認是false，建議設爲true，關閉消息緩衝

5.hbase.client.scanner.caching：scan緩存，默認爲1，避免佔用過多的client和rs的內存，通常1000之內合理，若是一條數據太大，則應該設置一個較小的值，一般是設置業務需求的一次查詢的數據條數 

若是是掃描數據對下次查詢沒有幫助，則能夠設置scan的setCacheBlocks爲false，避免使用緩存；

6.table用完需關閉，關閉scanner

7.限定掃描範圍：指定列簇或者指定要查詢的列，指定startRow和endRow

8.使用Filter可大量減小網絡消耗

9.經過java多線程入庫和查詢，並控制超時時間。後面會共享下個人hbase單機多線程入庫的代碼

10.建表注意事項：

開啓壓縮

合理的設計rowkey

進行預分區

開啓bloomfilter

zookeeper調優

1.zookeeper.session.timeout：默認值3分鐘，不可配置過短，避免session超時，hbase中止服務，線上生產環境因爲配置爲1分鐘，若是太長，當regionserver掛掉，zk還得等待這個超時時間(已有patch修復)，從而致使master不能及時對region進行遷移。

2.zookeeper數量：建議5個或者7個節點。給每一個zookeeper 4G左右的內存，最好有獨立的磁盤。

3.hbase.zookeeper.property.maxClientCnxns：zk的最大鏈接數，默認爲300，無需調整。

4.設置操做系統的swappiness爲0，則在物理內存不夠的狀況下才會使用交換分區，避免GC回收時會花費更多的時間，當超過zk的session超時時間則會出現regionserver宕機的誤報

hdfs調優

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

2.dfs.namenode.handler.count：namenode節點RPC的處理線程數，默認爲10，能夠設置爲60

3.dfs.datanode.handler.count：datanode節點RPC的處理線程數，默認爲3，能夠設置爲30

4.dfs.datanode.max.xcievers：datanode同時處理文件的上限，默認爲256，能夠設置爲8192

其它

列族名、column名、rowkey均會存儲到hfile中，所以這幾項在設計表結構時都儘可能短些

regionserver的region數量不要過1000，過多的region會致使產生不少memstore，可能會致使內存溢出，也會增長major compact的耗時

轉載請註明原文連接：http://blog.csdn.net/odailidong/article/details/41794403