1、垃圾回收（GC）参数配置
Hbase是java开发的，也是运行在java虚拟机jvm中，所以也可以通过GC参数配置调优；
主要调节的是RegionServer节点的JVM垃圾回收参数;
垃圾回收策略：Parraller New Collector垃圾回收策略；并行标记回收器（Concurrent Mark-Sweep Collector），避免GC停顿
使用：一般用于用于写在hbase-env.sh
export HBASE_REGIONSERVER_OPTS="-Xmx8g -Xms8G
-Xmn128m -XX:UseParNewGC -XX:UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=70 -verbose:gc
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
-Xloggc:$HBASE_HOME/logs/gc-${hostname}-hbase.log"
2、HBase内存管理
HBase上的Regionserver的内存主要分为两部分，一部分作为Memstore，主要用来写；一部分作为BlockCache，主要用于读。
写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满128M(hbase.hregion.memstore.flush.size)以后，会启动flush刷新到磁盘，当Memstore的总大小超过限制时（heapsizehbase.regionserver.global.memstore.upperLimit0.9），会强行启动flush进程，从最大的Memstore开始flush知道低于限制
读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于ClockCache采用的是LRU（最近最少使用）策略，因此BlockCache达到上限（heapsizehfile.block.cache.size0.85）后，会启动淘汰机制，淘汰掉最老的一批数据。
在注重读响应时间的应用场景下，可以将BlockCache设置大些，Memstore设置小些，以加大缓存命中率。
如果不希望自动触发溢写，就将值调大
<name>hbase.hregion.memstore.flush.size</name>
<value>134217728</value>
一般在企业中这个参数是禁用的
<name>hbase.hregion.majorcompaction</name>
<value>604800000</value>
直接将值设置为0就可以了，表示禁用
何时执行split
<name>hbase.hregion.max.filesize</name>
<value>10737418240</value>
一般建议将值调大，在期间手动去触发split
Memstore刷写数据到磁盘时，造成RegionServer内存碎片增多，当生存时间较长的数据从堆的老年代空间刷写到磁盘，就会产生内存孔洞。由于碎片过多导致没有足够大的连续内存空间，JVM就会暂停工作进程，进行垃圾回收（GC），导致HBase的RegionServer对外服务停顿
本地Memstore缓存机制：启用本地memstore分配缓存区（Memstore-Local Allocation Buffers，MSLAB），也就是允许从堆中分配相同大小的对象，一旦这些对象分配并且最终被回收，就会在堆中留下固定大小的孔洞，这些孔洞可被重复利用，GC就无需使应用程序进程停顿来回收内存空间，配置参数hbase.hregion.memstore.mslab.enabled，默认为true。
3、启动SNAPPY压缩
HBase列存储，比较占用空间，所以一般需要采用压缩算法，（从mysql导入hbase数据时发现，原本在mysql中30G数据，在hbase中占用150G），其中snappy性能优异，而且CDH中，直接安装了snappy的库。
使用方式：
1、创建时指定格式；
hbase> create 'test', { NAME => 'c', COMPRESSION => 'SNAPPY' }
2、修改已经创建好的列簇的压缩格式
disable 'test'
alter 'test', NAME => 'c', COMPRESSION => 'snappy'
enable 'test'
major_compact 'test' --修改之后，需要做一个major合并才能养压缩格式生效
describe 'test' --查看有没有生效
注：snappy是需要单独下载并编译安装的
4、预创建Region
创建HBase时，就预先根据可能的RowKey划分出多个Region而不是默认的一个，从而可以将后续的读写操作负载均衡到不同的Region上，避免热点现象；
HBase表的预分区需哟啊紧密结合业务场景来选择分区的key值，每个region都有一个startKey和一个endKey来表示该region存储的rowKey范围；
//有以下四种创建方式：
create 'ns1:t1' , 'f1' , SPLITS => ['10','20','30','40'] ;
create 't1','f1',SPLITS_FILE => 'splits.txt', OWNER=> 'johnode' ;
——其中splits.txt文件内容是每行一个rowkey值
create 't1','f1',{NUMREGIONS => 15, SPLITALGO =>'HexStringSplit'}
JavaAPI
HTableDescriptor desc = new HTableDescriptor(TableName.valueOf(weibo_content));
HColumnDescriptor family = new HColumnDescriptor(Bytes.toBytes("cf"));
// 开启列簇 -- store的块缓存
family.setBlockCacheEnabled(true);
family.setBlocksize(1024 * 1024 * 2);
family.setCompressionType(Algorithm.SNAPPY);
family.setMaxVersions(1);
family.setMinVersions(1);
desc.addFamily(family);
// admin.createTable(desc);
byte[][] splitKeys = { Bytes.toBytes("100"), Bytes.toBytes("200"), Bytes.toBytes("300") };
admin.createTable(desc, splitKeys);
5、负载均衡
balance_switch，master用来均衡各个regionserver上region数量
6、避免Region热点
热点现象：某个小的时段内，对HBase的读写请求集中到极少数的Region上，导致这些Region所在的RegionServer处理请求量骤增，负载量明显偏大，而其他的RegionServer明显空闲；
出现的原因：主要是因为Hbase表设计时，rowKey设计不合理造成的；
解决办法：Rowkey的随机散列+创表预分区
RowKey设计原则：
1、总的原则：避免热点现象，提高读写性能；
2、长度原则：最大长度64KB，开发通常10-16个字节，因为Hbase中每个单元格是以key-value进行存储的，因此每个value都会存储rowkey，所以rowkey越来越占空间；
3、散列原则：将时间上连续产生的rowkey散列化，以避免集中到极少数Region上
4、唯一原则：必须在设计上保证rowkey的唯一性
RowKey设计结合业务：
在满足rowkey设计原则的基础上，往往需要将经常用于查询的字段整合到rowkey上，以提高检索查询效率
