hbase参数调整升级

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

hbase参数调整记录:
2018年9月初:
1、hbase.regionserver.thread.compaction.small 默认1 --> 3 =》6
一个region的hfile文件数量达到该值,启动压缩,将多个文件合并成一个。
调整原因:减少合并次数
2、hbase.hregion.memstore.flush.size:128 =>64
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多线程入库和查询,并控制超时时间

推荐阅读更多精彩内容

  • 参考:https://www.jianshu.com/p/569106a3008f 最近在逐步跟进Hbase的相关...
    博弈史密斯阅读 476评论 1 1
  • 本文首先简单介绍了HBase,然后重点讲述了HBase的高并发和实时处理数据 、HBase数据模型、HBase物理...
    达微阅读 1,963评论 1 13
  • 最近在逐步跟进Hbase的相关工作,由于之前对Hbase并不怎么了解,因此系统地学习了下Hbase,为了加深对Hb...
    飞鸿无痕阅读 48,565评论 19 266
  • HBase那些事 @(大数据工程学院)[HBase, Hadoop, 优化, HadoopChen, hbase]...
    分痴阅读 3,263评论 3 17
  • 夜行·偶遇 斯襌 朦胧月色十八圆, 众里寻她楼宇间。 归来偶逢观音宴, 沿街香火红烛献。 夜行人至凭栏处, ...
    斯禅阅读 108评论 0 0