hbase优化小结

  

目录：

　　1，背景

　　2，GC

　　3，hbase cache

　　4，compaction

　　5，其余

 

1，背景

 

项目组中，hbase主要用来备份mysql数据库中的表。主要经过接入mysql binlog，经storm存储到hbase。因为是实时接入binlog写入，写的压力不是很大，主要是晚上离线计算的时候，须要将hbase中的表同步到HDFS中，这个时候对hbase的读性能以及全表扫描性能要求有些高，以尽可能较少数据导入时间。因为以前时间仓促，以及对hbase了解有限等缘由，hbase这块问题多多。当前阶段比较突出的问题主要有两个方面：第一，full GC频繁。 第二，尽可能提高hbase的读性能，尤为是scan的性能。

 

2，GC

问题：经过jstat命令发现regionserver进程full GC很是的频繁，甚至发现full GC的次数比young gc的次数还要多。full gc严重致使region server不稳定，常常运行几天后regionserver会死掉。

缘由：经过分析gc log以及实时观察，发现主要是读频发的时候，young区的S1，S2会很快到达100%，致使新的对象快速进入old区，此外，old区full gc不能有效快速回收内存，致使old去的内存一直维持在高位（老是高于设定的CMSInitiatingOccupancyFraction），因此致使old gc比young gc还多。

尝试办法：因为young区在hbase读频繁的时候很快被填满，因此很天然的尝试即是增大young区的大小。可是大了之后产生了两个负面效果，一是young gc时间变长了，二是仍是不能解决read的时候young区被快速填满的问题。这时意识到，单纯经过GC调参来解决full gc频繁问题的思路行不通了。

mark一下优化后的GC配置：

 

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=70"

 

export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx16000m -Xms16000m -Xmn7000m -XX:MaxDirectMemorySize=5g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=75 -Xloggc:${HOME}/hdp_data/hbase/rs.log-`date +'%Y%m%d%H%M'` -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:SurvivorRatio=2 -XX:+PrintTenuringDistribution"

 

 

3，hbase cache

hbase中与内存相关的主要是memstore和block cache，memstore主要服务于写，而block cache主要服务与读。有关block cache的详细介绍，能够参看block cache。hbase默认的block cache策略是LRU block cache，这时全部的cache都放在java进程的heap中，因此致使对hbase读的时候heap中的内存快速增加。bucket cache经过将date block缓存到direct buffer管理的堆外内存中，有效解决了这个问题。一般采用一种混合的策略即combined block cache(LRU block cache + bucket cache). LRU block cache主要用来缓存bloom过滤器，索引等。配置以下：

GC参数设置：-XX:MaxDirectMemorySize=5g，设置java进程使用direct memory的最大值。

hbase-site.xml中配置以下：

<!--LRU Cache-->

  <property>

     <name>hfile.block.cache.size</name>

     <value>0.4</value>

  </property>

  <!--Bucket cache-->

  <property>

    <name>hbase.bucketcache.ioengine</name>

    <value>offheap</value>

  </property>

  <property>

    <name>hbase.bucketcache.size</name>

    <value>4196</value>

  </property>

设置之后，hbase regionsever进程full gc问题圆满解决。

 

4，hbase compaction

hbase compaction主要是合并memstore flush到磁盘上的HFile文件。主要分minor compaction和major compaction。minor compaction只会合并不多的hfile，这个花费的时间也不是很长。而major compaction会合并指定table的全部的HFile，因此花费的时间也比较长，可是可以显著提升hbase的读性能。考虑到白天hbase集群的负载并非很高，因此很天然想到就是作手工major compaction。写一个简单的脚本就行了。其实就一行语句：echo "major_compact 'tablename'" | hbase shell，而后经过crontab定时启动就行了。作了major compaction之后region server的block locality明显好转，hbase读的性能提高提高了50%以上，晚上导表时间几乎缩短了一半。

 

5，其余

 

其余的方法也尝试了一些，比方说设置hbase.client.scanner.caching参数，以及在每台datenode的机器上都部署region sever以加强data locality，还有增大hbase导表的并发数等，这些有一些效果，可是不是太明显。

总的来讲，此次主要是熟悉hbase相关的原理和配置，而后经过设置一些策略和参数来提高hbase的性能，虽然比较简单粗暴，可是以上方法已基本知足当前需求，因此对hbase读性能的优化暂时告一段落。接下来会对hbase的稳定性以及可运维性作一些测试。