[HBase] - Hbase调优1

版本：HBase-0.98.6-cdh5.3.6

HBase参数调优

1. zookeeper.session.timeout: 默认90000(毫秒), 控制连接zk的timeout时间。由于hbase的集群是由zk管理的，所以当一个regionserver挂掉的时候，master是从zk集群上得到的，如果该值比较大，那么可能就会有比较高的延时；如果该值比较小，那么当有一个较长时间的gc发生的时候，可能会出现假宕机。

2. dfs.datanode.failed.volumes.tolerated: 默认为0，表示不允许datanode节点上发生磁盘错误，如果发生，立马将这个datanode设置为不可用，如果你是挂载多个磁盘(>3or4个)，那么就可以将这个值设高，比如1或者更高.

3. hbase.regionserver.handler.count: 默认10，定义连接用户表的客户端并发线程数量。默认值比较小的原因，主要是为了预防用户用一个比较大的写缓冲，然后还有很多客户端并发，这样region servers会垮掉；一般的设置规则是：当请求的内容很大的时候(比如打的put或者scans)，那么将该值修改成比较小的值；当请求为较小的get、delete的时候，那么设置一个较大的值(可以和并发数类似)。该值比较大的时候可能会出现停顿或者严重的时候出现OutOfMemery，因为如果请求的内存要求比较大的时候，会导致频繁GC的发生，那么就会产生这种问题。

4. 压缩(机器内存8G+)：能够降低存储文件大小以及IO，绝大多数情况下能够提高性能。hbase.regionserver.codecs指定压缩方法，默认为为空，可以指定gz,lzo等多个，用','分割。

5. 较大的region / 自管理region split(机器内存8G+): 更大的Region可以使你集群上的Region的总数量较少。 一般来言，更少的Region可以使你的集群运行更加流畅(也可以手动的分割region)。一般一个regionserver在20~500之间算是比较好的一个值。hbase.hregion.max.filesize默认10G，当达到该值的时候，才开始进行分割。hbase.regionserver.region.split.policy指定分割文件的策略IncreasingToUpperBoundRegionSplitPolicy。hbase.regionserver.regionSplitLimit(该参数是一个指导性的参数，不是一个硬性指标)指定最大region的个数，默认INT_MAX。一般情况下，如果可以的话，选择手动管理region，也就是禁用hbase自带的region分割机制，在集群空闲的时候再进行region的分割，选择将hbase.regionserver.regionSplitLimit设置1以及hbase.hregion.max.filesize设的更大(比如100G,但是不推荐设置为LONG_MAX)。

6. 管理Compactions：进行主紧缩(major)管理是必须的，我们可以控制的只是间隔时间，在0.96.x之前版本是每隔一天进行一次，以后版本是7天执行一次。有两种类型的紧缩，主紧缩(major)和次(minor)紧缩。minor紧缩通常会将数个小的相邻的文件合并成一个大的。Minor不会删除打上删除标记的数据，也不会删除过期的数据，Major紧缩会删除过期的数据，在执行major紧缩后会变成一个storefile文件，通常可以提高性能。major会进行数据的重写操作，所有在一个负载较高的系统中，会采用取消自动紧缩机制，采用手动紧缩机制。紧缩是不会对分区进行合并的，如果需要合并，那么需要使用merge。

   major：hbase.hregion.majoucompaction=604800000  间隔毫秒数(7days)， hbase.hregion.majorcompaction.jetter=0.5 浮动值比率， 也就是说最终是间隔3.5~10.5天。

   minor：hbase.hstore.compaction.min最小文件数(默认值3)；hbase.hstore.compaction.max最多文件数(默认值10，不管合适的文件个数)；hbase.hstore.compaction.min.size可以继续minor的文件最大大小，超过该值的文件大小由ratio参数决定(默认128M)；hbase.hstore.compaction.max.size大于该值的文件一定不会进行minor(默认LONG_MAX)；hbase.hstore.compaction.ratio决定超过min.size的文件是否进行minor，只要文件大小小于后面所有文件大小总和的ratio倍就可以了，比如说X5M，Y2M，Z3M，那么计算5<1.2*(2+3)，那么表示X也进行minor，如果X为7M那么就不进行minor(默认1.2F，选择的时候文件按照时间排序olded->newed)；hbase.hstore.compaction.ratio.offpeak在负载低的时候的ratio值，默认0.5，要求开启设置offpeak。hbase.offpeak.start/end.hour指定低负载起始时间和结束时间(0-23,默认-1表示不启用)。选择文件的时候，只要求数据数量小于max，而且前面的文件要进行压缩，那么当前文件就直接需要进行压缩。三个实例：

   

7. 预测执行(speculative execution)：mapreduce默认是打开的，推荐在系统级/集群级别关闭，只有当需要的时候再手动通过配置项打开mapreduce.map.speculative(旧版本mapred.map.tasks.speculative.execution)和mapreduce.reduce.speculative(旧版本mapred.reduce.tasks.speculative.execution)。

8. 负载均衡：在master节点上执行的重新分配region的方式，参数hbase.balancer.period(默认值300000,5分钟)。

9. hfile.block.cache.size，默认值为0.4，设置块缓存的内存大小占比；设置为0表示不使用，但是不推荐设置为0，至少需要将hfile文件的目录保存在内存中，在读比较多的应用中，调高该值，在写应用中，调低该值。需要和memstore.upperLimit同时考虑。

10. Nagle算法：当出现大量延时40ms左右的情况的时候，可以开启tcpNoDelay。

11. hadoop相关连接time out：hbase.lease.recovery.dfs.timeout默认64000(毫秒),租赁过期时间;dfs.client.socket-time默认60000(毫秒);hbase中推荐使用23000和10000.<作用就是为了快速的通知节点失效>。

12. hbase.regionserver.global.memstore.upperLimit，默认值0.4，表示rs中的memstore占内存的比例最大值，当达到这个值的时候，就一定进行flush到磁盘的操作。在读比较多的应用中，采用将该值减小的方式，在写比较多的应用中，采用将该值增大的方式，一般改变0.5即可。同cache的限制一般在全部内存的0.8左右为好，这样不太可能出现oom的错误。

13. hbase.regionserver.global.memstore.lowerLimit，默认值0.38，表示rs的memstore占内存比例达到该值的时候，就可能触发flush操作。

14. hbase.hregion.memstore.flush.size,默认值134217728(128M)，当memstore的值大于该值的时候，进行flush操作。

15. hbase.hregion.memstore.block.multiplier,默认值4，表示memstore阻塞的块大小(*hbase.hregion.memstore.flush.size)，当超过这个值的时候，就会出现阻塞，当该值比较大的时候可能出现oom情况。即如果memstore的内存大小已经超过了hbase.hregion.memstore.flush.size的4倍，则会阻塞memstore的写操作，直到降至该值以下，为避免发生阻塞，最好调大该值，不过一般情况下，使用默认值即可。

16. JVM调整，hbase默认为1G，master节点可以调为2/4G，regionserver节点可以调整为10G，zk基本不消耗内存，可以不用调整。