目录：
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的稳定性以及可运维性做一些测试。