hbase参数调整升级

最近对hbase进行了参数升级，并整理了下其中发现的问题。

hbase参数调整记录：
2018年9月初：
1、hbase.regionserver.thread.compaction.small 默认1 --> 3 =》6
一个region的hfile文件数量达到该值，启动压缩，将多个文件合并成一个。
调整原因：减少合并次数
2、hbase.hregion.memstore.flush.size：１２８　＝＞６４
1）memStoreFile大于此值刷数据到磁盘
2）如 memstore 的大小增加到 'hbase.hregion.block.memstore' 的值乘以 'hbase.hregion.flush.size' 字节的值，则块将写入。
调整原因：因为2），值减小，期望减少刷数据到磁盘的条件。
3、hbase.regionserver.maxlogs 32 --> 64
单个regionserver上wal的文件数量
调整原因：由于达到wal的文件数量，会flush内存数据到磁盘，导致很多几K的文件落地。
效果：有一定效果，调整后没有因为这个原因刷文件，其他原因出现：由于是memstore满了或wal日志到1小时了刷数据

2018年9月12日凌晨：
1、hbase.hstore.compactionThreshold 默认3 =》6
增加压缩的线程数据量
调整原因：增加压缩的线程数据量，期望压缩的并行度高一些
效果：观察到同时运行的压缩是1-2个，没有超过两个的，感觉没有起到效果
2、hbase.hregion.max.filesize: 10G =>30G
单个region文件的大小，大于这个拆分为两个文件
调整原因：增加单个region的大小，控制region数量再增长
效果：与预期一致

2018年9月12日晚上：（只调整了22）
1、hbase.regionserver.global.memstore.lowerLimit 0.38 =》0.9
增大比例 Memstore
调整原因：原来分配给regionServer的20G内存Memstore只有3G 算法 200.43.8
调整效果：调整后Memstore确实增加到了6G多，但是增加了很多rpc等待，估计对服务影响较大
2、hbase.hstore.compaction.max 10-》15
每次压缩最大的压缩文件数量
调整原因，期望一次压缩多个文件，减少压缩次数
效果：不是很明显，还是有压缩积压

计划要调整的参数：
1、 hbase.hstore.compaction.max.size Long.MAX_VALUE -》5G
大于此大小的文件不参与Minor压缩
调整原因：每次压缩5G+1M+1M+1M 的文件 需要10多分钟
如果只合并1M+1M+1m的文件 可以只需几秒钟
当然调整问5G之后，也会出现 4G+1M+1M的情况
效果：
2、wal日志刷新时间：1小时=》2小时
因为日志到期刷内存的数据到磁盘
调整原因：一个region一个小时刷出一个文件，6个文件合并异常，一个region一天就要最少合并4次，所以希望减少
效果：
3、hbase.regionserver.global.memstore.upperLimit 0.4=》0.7
hfile.block.cache.size 0.4=》0
取消读的cache，增加memstore
调整原因：目前cache的概率是1.2%很小，所以取消，增加memstore大小，增加写入性能

给客户端建议针对我们现在的问题：
1、减少超大表
1张表的数据量不超过1T，1T=200个region
超大表的缺点：1、安全风险：超大表一单出问题，恢复比较慢，而且很容易出问题。
2、数据删除性能差
3、一张表出问题会引起灾难性后果。
2、写入线程在一条记录或者一次写入超过一定时间（10秒--1分钟）后，需要重试重新写入，不要一直等待下去
3、减少hbase数据量
如：只有部分业务需要周期较长的数据，
可以考虑将该业务需要的数据单独拆分出来，放在单独的表里

Client端 建议
1 hbase.client.write.buffer：默认为2M，写缓存大小，推荐设置为5M，单位是字节，当然越大占用的内存越多，此外测试过设为10M下的入库性能，反而没有5M好
2 hbase.client.pause：默认是1000(1s),如果你希望低延时的读或者写，建议设为200，这个值通常用于失败重试，region寻找等
3 hbase.client.retries.number：默认值是10，客户端最多重试次数,可以设为11，结合上面的参数，共重试时间71s
4 hbase.ipc.client.tcpnodelay：默认是false，建议设为true，关闭消息缓冲
5 hbase.client.scanner.caching：scan缓存，默认为1，避免占用过多的client和rs的内存，一般1000以内合理，如果一条数据太大，则应该设置一个较小的值，通常是设置业务需求的一次查询的数据条数
如果是扫描数据对下次查询没有帮助，则可以设置scan的setCacheBlocks为false，避免使用缓存；
6 table用完需关闭，关闭scanner
7 限定扫描范围：指定列簇或者指定要查询的列，指定startRow和endRow
8 使用Filter可大量减少网络消耗
9 通过java多线程入库和查询，并控制超时时间