Hbase性能优化

修改Linux最大文件数

Linux系统最大可打开文件数一般默认的参数值是1024，如果你不进行修改并发量上来的时候会出现“Too ManyOpen Files”的错误，
导致整个HBase不可运行
查看：ulimit -a 结果：open files(-n) 1024
临时修改：ulimit -n 4096
持久修改：
vi /etc/security/limits.conf在文件最后加上：
*soft nofile 65535
*hard nofile 65535
*soft nproc 65535
*hard nproc 65535

JVM调优：

regionserver默认内存大小为1G,memStore占比40%，
很小容易发生写阻塞 修改hbase-env.sh中的
# export HBASE_HEAPSIZE=1G（默认注释掉）

JDK版本低于8，HBase会有一个内存泄漏的Bug，永久对象区（Permanent Generation，这个区域在非堆内存里边）

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -xx:PermSize=128m -XX:MaxPermSize=128m"
export HBASE_REGIONsERVER_OPTS="$HBASE_REGIONSERVER_OPTS -xx:PermSize=128m -XX:MaxPermSize=128m"

如果xml调的比较大了，那么需要把PermSize和maxPermSize调整的都大一些
（一般不会出现这种情况，128M已经够大了）。JDK8+优化过，以后可以直接删除掉。

注：RegionServer的内存占有率一般是除去mr（计算框架）最大的

通常认为RegionServer的堆内存越大越好，但是因为GC的缘故，内存大了之后，
FullGC时间也会线性增加，FullGC可能长达几分钟，甚至会停止响应任何请求
，相当于所有线程挂起，这种暂停叫做STW(Stop-The-World)，就会造成GC的卡顿。
在Zookeeper检测RegionServer心跳的时候，
RegionServer正在FullGc无法回应，而如果超过阈值的等待时间会被标记为宕机，
这时候会将该RegionServer上的数据向其他RegionServer迁移，
并且该RegionServer在FullGc结束后发现自己被Zookeeper判定为宕机了，
为了防止脑裂，会停止自己（RegionServer自杀，艺名朱丽叶暂停）。
原因主要是Zookeeper在RegionServer发生FULL GC的时候，由于STW期间太长，
被Zookeeper标记为宕机，当RegionerServer GC完成后，苏醒了发现被标记为宕机了，
这时候RegionerServer GC就自杀，防止脑裂发生。醒来怕脑裂就自杀，产生了朱丽叶暂停
直接的解决方法：
zookeeper的心跳检测阀值调大或者调大RegionServer的内存
不过这样解决的话，会增长时间，所以根据自己的选择来确定你的优化策略

JVM提供了四中GC回收器（避免长时间FullGC或者减少FullGc的发生）：
串行回收器：SerialGC
并行回收器：ParallelGC 对年轻代进行优化 jdk8的默认策略 性能不是特别好 FullGC的时间较短，HBase中FullGC对于rs影响很大，所以一般选用并行回收器（ 高吞吐量）
并发回收器：ConcMarkSweepGC 简称CMS 对老年代进行优化 减少老年代的暂停时间，可以保证应用不停止的情况下进行收集，缺点是会留下浮动垃圾，只能等待下次回收（ 低延迟）
G1GC回收器：Garbage-First GC 吸收了并发和并行回收的特长 大内存（32GB以上）进行优化

参数调优

hregionserver的操作线程数

hbase.hregionserver.handle.count=30

region拆分策略：

（防止一个region过大）
（某些特定的环境（数据量突然增大，会导致region不停地合并拆分，设置为-1就是关掉）

0.94版本之前默认storefile达到10G，region进行拆分

0.94版本开始

#刷新阈值
hbase.hregion.memstore.flush.size默认为128M，
#切分阈值
hbase.hregion.max.filesize默认为10G.

两种自定义拆分策略
1、KeyPrefixRegionSplitPolicy策略，即根据rowkey指定长度的前缀来划分region
2、DelimitedKeyPrefixRegionSplitPolicy策略：保证以分隔符前面的前缀为splitPoint，保证相同RowKey前缀的数据在一个Region中。

minor compact
storefile达到数量后就进行和并
只是简单的将文件合并到一起，不做任何的删除更新操作
合并速度快，效率高

major compact
设置的定期的合并（压缩）
会进行数据的更新和删除操作，会耗费大量的磁盘IO
业务高峰期不会做这种操作
这种合并都是定期定时的执行

客户端优化

1. 关闭自动刷新

ht.setAutoFlush(true,false)

2. 尽量批量写入
3. 谨慎关闭写hlog（已经存在的数据，出错了直接改就行的）
   ht.setDurability(Durability.SKIP_WAL)
4. 尽量将数据放到缓存中
5. 列族不要太多
6. rowkey优化：
   https://blog.csdn.net/qq_43755771/article/details/90720805
7. 尽量关闭可关闭的对象