Hbase优化

0.98.9版本，目前粗略写一下，后面可以一步步更新

对于RS的JVM优化：

export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -server -Xmx15360m -Xms15360m -Xmn2048m -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=15 -XX:CMSInitiatingOccupancyFraction=70 -XX:MaxTenuringThreshold=20 -Dcom.sun.management.jmxremote.port=10102 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data2/hadoop/logs/hbase-log/oom.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/data2/hadoop/logs/hbase-log/gc-hbase.log"

下面分解：

-Xmx ：最大堆大小

-Xms：初始堆大小，设置和最大堆大小一样，为了避免堆伸缩带来的压力

 -Xmn：年轻代大小（eden+t2个servivor）

-XX:+UseParNewGC ParNew是Serial收集器的多线程版本，对于CMS来说，除了Serial外只有它能一起分代收集；

-XX:+UseConcMarkSweepGC 使用CMS收集老年代，使用的是“标记-清除”算法实现，是真正意义上的并发收集，也就是收集过程中用户线程还在并发运行，最求的是最短停顿时间，因为并发，会产生浮动垃圾和大量内存碎片的缺点；

-XX:+CMSParallelRemarkEnabled 降低标记停顿

-XX:+UseCMSCompactAtFullCollection  CMS非常容易产生碎片，Full GC的时候启用压缩参数

-XX:CMSFullGCsBeforeCompaction=15 多少次Full GC后进行内存压缩

XX:CMSInitiatingOccupancyFraction=70  为了避免Promotion Failed，使用达到70%开始CMS收集，该参数可以稍微多于RS memstore上限和块缓存的和或者少于；

对于RS堆大小的配置，为了数据本地性，RS和DataNode都是并行安装的，机器允许可以在8G到15G之间测试调整，不建议超过15G，试过20G的情况，设大了吞吐率和并行度反而不好，还不如多开几台RS，每台设置堆小些，这样总堆一样的情况，吞吐率性能更好些；

参数：

hbase.regionserver.global.memstore.upperLimit/hbase.regionserver.global.memstore.upperLimit/lowerLimit.lowerLimit

RS节点所有region的memstores所占堆大小的上下限，默认分别为0.4/0.35，达到上限时，会block所有的更新，并flush memstore的内存，达到lowerLimit是才不flush所有的memstore，同样要根据使用场景来调整，如果 随机读比较少，频繁写和顺序读多，可以适当从块缓存中转部分过来；

hfile.block.cache.size 块缓存占堆的大小，默认0.4，该值会影响读性能；

hbase.hregion.max.filesize

RS全局上单个Reigon的最大存储空间，超过该值时，会自动split，默认是10737418240，即10G，该值可以根据业务情况来调整，比如有业务通过hive整合拉取hbase数据，一个map拉取一个region的数据，region大的话，效率和并发都不够好，而有些可能不想split，毕竟节点资源有限，更少的region数性能更好，可以将该值设更大避免split，split都是高耗的动作，导致ioIO的飙升等，单表可以相应如下调整大小：

 alter ‘mytable’, MAX_FILESIZE => ‘5368709120’

alter ‘mytable’, METHOD => ‘table_att_unset’, NAME => ‘MAX_FILESIZE’

hbase.hregion.majorcompaction

大合并过程写入请求会全部阻塞，非常耗资源，可以设置为0表示停止周期性大合并，改为自己规划手动进行大合并，默认是604800000即7天一次；

hbase.hregion.memstore.mslab.enabled

启用mslab，在频繁写的时候减少因内存碎片导致的Full GC，提高整体性能

hbase.hstore.blockingStoreFiles
默认10，如果任何Store中storeFile数超过该值，该region的更新将被block，直到合并完成，或者block时间超过blockingWaitTime设定时间；

hbase.hstore.blockingWaitTime
默认90000，也就是90s，超过该时间，Region将停止block更新，即使compaction没完成

列祖（column family）级别优化：

批量进行全表扫描的，应该将块缓存关闭，默认是打开的，全表批量扫描只读取一遍，使用缓存反而会降低扫描的效率，关闭避免频繁多次倒腾缓存，还不如多留出缓存给其他需要随机读的场景，如下方式设置关闭：

create 'mytable',{NAME=>'f',BLOCKCACHE=>'false'}

块大小，默认是65536字节，即64KB，数据块索引每个HFile数据块的起始键，所以数据块大小会影响索引的大小，数据块越小，索引越大，索引占用的内存空间就越大，加载进内存的最小单位的数据块越小，随机查询性能越好，如果是hive或者mr全扫描，则会希望加载更多的HFile数据进入内存，这时候数据块大小应该增大；

create 'mytable',{NAME=>'f',BLOCKSIZE=>65536}

BloomFilter

布隆过滤器,在0.98.13版本是默认是NONE的,还有ROW,ROWCOL两种值,其他版本又有所改变,先注意查看默认值,布隆过滤器作用是允许对每个数据块的数据做一个反向测试,对于行的请求,布隆过滤器要么回答不在,要么回答不知道.布隆过滤器这种索引会占用额外空间,行级的用ROW,列限定符级的用ROWCOL;

create 'mytable',{NAME=>'f',BLOOMFILTER=>'ROW'}

TTL

生存时间是在列祖级别设置的,处理多久后要删除数据的需求,用于将早于TTL值的数据在下一次大合并时删除;

create 'mytable',{NAME=>'f',TTL=>2592000}

有时因为TTL到期，region为空了，而且业务因为不会再写入该region可以通过以下命令来关闭region

close_region ‘REGIONNAME’

压缩

除非CPU资源很限制,一般开启压缩节省磁盘IO,默认带的SNAPPY，可以自行安装LZO压缩，

create 'mytable',{NAME=>'f',COMPRESSION=>'SNAPPY'}

VERSIONS

默认情况每个cell维护三个时间版本

create 'mytable',{NAME=>'f',VERSIONS=>1}

热点问题

1.设计rowkey的时候，避免递增的情况，可以通过散列或者加盐（salt）来随机化rowkey的分布

2.抽样来确定rowkey的分布情况，使用预分区来预创建 region，从而避免一开始的热写，如下：

     create 'mytable',‘f’, SPLITS => ['A','B', 'C','D']

3.对于还是集中region可以手动split拆分，一些集中在某RS的regions可以执行负载均衡或者move到其他空闲的节点

caching

hbase.client.scanner.caching

该参数是scanner的next方法取回的行数，数值越大，对RS远程调用次数越少，处理速度也越快，实际使用中越大越容易rpc timeout

要相应的调整hbase.client.scanner.timeout.period的数值以及hbase.rpc.timeout的数值，后者不能比前者小