HBase性能优化彻底版

近期在处理HBase的业务方面经常遇到各类瓶颈，一天大概一亿条数据，在HBase性能调优方面进行相关配置和调优后取得了必定的成效，因而，特此在这里总结了一下关于HBase全面的配置，主要参考个人另外两篇文章：

（1）http://blog.csdn.net/u014297175/article/details/47975875

（2）http://blog.csdn.net/u014297175/article/details/47976909

在其基础上总结出来的性能优化方法。

1.垃圾回收优化

Java自己提供了垃圾回收机制，依靠JRE对程序行为的各类假设进行垃圾回收，可是HBase支持海量数据持续入库，很是占用内存，所以繁重的负载会迫使内存分配策略没法安全地依赖于JRE的判断：须要调整JRE的参数来调整垃圾回收策略。有关java内存回收机制的问题具体请参考：http://my.oschina.net/sunnywu/blog/332870。

（1）HBASE_OPTS或者HBASE_REGIONSERVER_OPT变量来设置垃圾回收的选项，后面通常是用于配置RegionServer的，须要在每一个子节点的HBASE_OPTS文件中进行配置。

1）首先是设置新生代大小的参数，不能太小，太小则致使年轻代过快成为老生代，引发老生代产生内存随便。一样不能过大，过大致使全部的JAVA进程中止时间长。-XX:MaxNewSize=256m-XX:NewSize=256m 这两个能够合并成为-Xmn256m这一个配置来完成。

2）其次是设置垃圾回收策略：-XX:+UseParNewGC -XX:+UseConcMarkSweepGC也叫收集器设置。

3）设置CMS的值，占比多少时，开始并发标记和清扫检查。-XX:CMSInitiatingOccupancyFraction=70

4）打印垃圾回收信息：-verbose:gc -XX: +PrintGCDetails -XX:+PrintGCTimeStamps

-Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.log

最终能够获得：HBASE_REGIONSERVER_OPT="-Xmx8g -Xms8g –Xmn256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC  \

-XX:CMSInitiatingOccupancyFraction=70   -verbose:gc \

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps \

-Xloggc:$HBASE_HOME/logs/gc-$(hostname)-hbase.log

（2）hbase.hregion.memstore.mslab.enabled默认值：true，这个是在hbase-site.xml中进行配置的值。

说明：减小因内存碎片致使的Full GC，提升总体性能。

2.启用压缩，详情自行搜索，暂时不曾尝试，后面持续更新。

3.优化Region拆分合并以及与拆分Region

（1）hbase.hregion.max.filesize默认为256M（在hbase-site.xml中进行配置），当region达到这个阈值时，会自动拆分。能够把这个值设的无限大，则能够关闭HBase自动管理拆分，手动运行命令来进行region拆分，这样能够在不一样的region上交错运行，分散I/O负载。

（2）预拆分region

用户能够在建表的时候就制定好预设定的region，这样就能够避免后期region自动拆分形成I/O负载。

4.客户端入库调优

（1）用户在编写程序入库时，HBase的自动刷写是默认开启的，即用户每一次put都会提交到HBase server进行一次刷写，若是须要高速插入数据，则会形成I/O负载太重。在这里能够关闭自动刷写功能，setAutoFlush(false)。如此，put实例会先写到一个缓存中，这个缓存的大小经过hbase.client.write.buffer这个值来设定缓存区，当缓存区被填满以后才会被送出。若是想要显示刷写数据，能够调用flushCommits()方法。

此处引伸：采起这个方法要估算服务器端内存占用则能够：hbase.client.write.buffer*hbase.regionserver.handler.count得出内存状况。

（2）第二个方法，是关闭每次put上的WAL（writeToWAL(flase)）这样能够刷写数据前，不须要预写日志，可是若是数据重要的话建议不要关闭。

（3）hbase.client.scanner.caching：默认为1

这是设计客户端读取数据的配置调优，在hbase-site.xml中进行配置，表明scanner一次缓存多少数据（从服务器一次抓取多少数据来scan）默认的过小，可是对于大文件，值不该太大。

（4）hbase.regionserver.lease.period默认值：60000

说明：客户端租用HRegion server 期限，即超时阀值。

调优：这个配合hbase.client.scanner.caching使用，若是内存够大，可是取出较多数据后计算过程较长，可能超过这个阈值，适当可设置较长的响应时间以防被认为宕机。

（5）还有诸多实践，如设置过滤器，扫描缓存等，指定行扫描等多种客户端调优方案，须要在实践中慢慢挖掘。

5.HBase配置文件

上面涉及到的调优内容或多或少在HBase配置文件中都有所涉及，所以，下面的配置不涵盖上面已有的配置。

(1) zookeeper.session.timeout（默认3分钟）

ZK的超期参数，默认配置为3分钟，在生产环境上建议减少这个值在1分钟或更小。

设置原则：这个值越小，当RS故障时Hmaster获知越快，Hlog分裂和region 部署越快，集群恢复时间越短。 可是，设置这个值得原则是留足够的时间进行GC回收，不然会致使频繁的RS宕机。通常就作默认便可

（2）hbase.regionserver.handler.count（默认10）

对于大负载的put（达到了M范围）或是大范围的Scan操做，handler数目不易过大，易形成OOM。 对于小负载的put或是get，delete等操做，handler数要适当调大。根据上面的原则，要看咱们的业务的状况来设置。（具体状况具体分析）。

（3）HBASE_HEAPSIZE（hbase-env.sh中配置）

个人前两篇文章Memstoresize40%（默认） blockcache 20%（默认）就是依据这个而成的，整体HBase内存配置。设到机器内存的1/2便可。

（4）选择使用压缩算法，目前HBase默认支持的压缩算法包括GZ，LZO以及snappy（hbase-site.xml中配置）

（5）hbase.hregion.max.filesize默认256M

上面说过了，hbase自动拆分region的阈值，能够设大或者无限大，无限大须要手动拆分region，懒的人别这样。

（6）hbase.hregion.memstore.flush.size

单个region内全部的memstore大小总和超过指定值时，flush该region的全部memstore。

（7）hbase.hstore.blockingStoreFiles  默认值：7

说明：在flush时，当一个region中的Store（CoulmnFamily）内有超过7个storefile时，则block全部的写请求进行compaction，以减小storefile数量。

调优：block写请求会严重影响当前regionServer的响应时间，但过多的storefile也会影响读性能。从实际应用来看，为了获取较平滑的响应时间，可将值设为无限大。若是能容忍响应时间出现较大的波峰波谷，那么默认或根据自身场景调整便可。

（8）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。

（9）hbase.regionserver.global.memstore.upperLimit：默认40%

当ReigonServer内全部region的memstores所占用内存总和达到heap的40%时，HBase会强制block全部的更新并flush这些region以释放全部memstore占用的内存。

hbase.regionserver.global.memstore.lowerLimit：默认35%

同upperLimit，只不过lowerLimit在全部region的memstores所占用内存达到Heap的35%时，不flush全部的memstore。它会找一个memstore内存占用最大的region，作个别flush，此时写更新仍是会被block。lowerLimit算是一个在全部region强制flush致使性能下降前的补救措施。在日志中，表现为 “** Flushthread woke up with memory above low water.”。

调优：这是一个Heap内存保护参数，默认值已经能适用大多数场景。

（10）hfile.block.cache.size：默认20%

  这是涉及hbase读取文件的主要配置，BlockCache主要提供给读使用。读请求先到memstore中查数据，查不到就到blockcache中查，再查不到就会到磁盘上读，并把读的结果放入blockcache。因为blockcache是一个LRU,所以blockcache达到上限(heapsize * hfile.block.cache.size)后，会启动淘汰机制，淘汰掉最老的一批数据。对于注重读响应时间的系统，应该将blockcache设大些，好比设置blockcache=0.4，memstore=0.39，这会加大缓存命中率。

（11）hbase.regionserver.hlog.blocksize和hbase.regionserver.maxlogs

之因此把这两个值放在一块儿，是由于WAL的最大值由hbase.regionserver.maxlogs*hbase.regionserver.hlog.blocksize (2GB by default)决定。一旦达到这个值，Memstore flush就会被触发。因此，当你增长Memstore的大小以及调整其余的Memstore的设置项时，你也须要去调整HLog的配置项。不然，WAL的大小限制可能会首先被触发，于是，你将利用不到其余专门为Memstore而设计的优化。抛开这些不说，经过WAL限制来触发Memstore的flush并不是最佳方式，这样作可能会会一次flush不少Region，尽管“写数据”是很好的分布于整个集群，进而颇有可能会引起flush“大风暴”。

提示：最好将hbase.regionserver.hlog.blocksize* hbase.regionserver.maxlogs 设置为稍微大于hbase.regionserver.global.memstore.lowerLimit* HBASE_HEAPSIZE。

6.HDFS优化部分

HBase是基于hdfs文件系统的一个数据库，其数据最终是写到hdfs中的，所以涉及hdfs调优的部分也是必不可少的。

（1）dfs.replication.interval:默认3秒

能够调高，避免hdfs频繁备份，从而提升吞吐率。

（2）dfs.datanode.handler.count:默认为10

能够调高这个处理线程数，使得写数据更快

（3）dfs.namenode.handler.count：默认为8

（4）dfs.datanode.socket.write.timeout：默认480秒，并发写数据量大的时候能够调高一些，不然会出现我另一篇博客介绍的的错误。

（5）dfs.socket.timeout:最好也要调高，默认的很小。

同上，能够调高，提升总体速度与性能。