HBase性能调优

HBase性能调优

1.设计原则

  • 预分区
create 'user', 'info', SPLITS => ['1001', '2001', '3001', '4001']

在创建表的时候提前创建多个空region,提前预估每个region开始和结束的rowkey,尽量使设计的rowkey能均匀命中各个region(region split分裂的时候始终会占用系统IO资源)。

  • Rowkey
    Rowkey底层存储是一个二进制流,可以是任意字符串,最大长度 64kb ,实际应用中一般是10-100字节,以 byte[] 形式保存,一般设计为定长,Rowkey越短越好,一般建议不要超过16字节(Rowkey越小缓存可以存放的数据越多,操作系统一般为64位,内存8字节对齐);
    Rowkey需要尽量散列,避免数据热点问题(与预分区一起规划考虑);
    Rowkey是HBase里面唯一的索引,对于某些查询频繁的限定条件可以把它的内容存放在Rowkey里面,提高查询效率。
  • 列族
    在设计列族的时候,建议把经常读取的字段存储到一个列族中,不经常读取的字段放到另一个列族中。
    这样在读取部分数据的时候,就只需要读取一个列族文件即可,可以提高读取效率。

2.列族设置

  • 生存时间(TTL-单位为秒)
 create 'user', {NAME => 'info', TTL => '18000'}

当系统在某些场景下需要删除历史数据时,可以通过配置TTL来设置数据的存放时间,过期的数据会在大合并的时候被真正删除;

  • 版本数
  create 'user', {NAME => 'info', VERSIONS => 3}

在0.96版本之前默认每个列族有3个version,0.96之后默认每个列族有一个版本,在大合并时会删除掉过期的版本数据;

  • 压缩
  create 'user',{NAME => 'info', COMPRESSION => 'SNAPPY'}

HFile可以被压缩存放在HDFS上,这样有助于节省硬盘IO,但是读写数据时的压缩和解压会额外占用CPU的利用率;
压缩是表定义的一部分,可以在建表或者修改表结构时设定;
在正式的生产环境中建议打开表的压缩;
HBase可以使用的压缩编码包括LZO、SNAPPY和GZIP;
在这里插入图片描述
综合来看,Snappy的压缩率最低,但是编解码速率最高,对CPU的消耗也最小,目前一般建议使用Snappy。

  • 数据块(BLOCKSIZE)大小的配置(单位为字节)
  create 'user',{NAME => 'info', BLOCKSIZE => '65537'}

随机查询:数据块越小,索引越大,查询性能越好;
顺序查询:更好的顺序扫描,需要更大的数据块;
在实际使用的时候还是要根据实际业务来定。

  • 数据块缓存
  create 'user',{NAME => 'info', BLOCKCACHE => 'false'}

如果一张表或表里的某个列族只被顺序访问或很少被访问,这个时候就算get或scan花费的时间长点也是没关系的,这种情况下,可以关闭那些表或者列族的缓存,否则当程序执行很多顺序访问的时候不但会多次操作缓存,而且还会把应该存放在缓存的数据给挤出缓存。

  • 布隆过滤器(Bloom filters)
  create 'user',{NAME => 'info', BLOOMFILTER => 'ROWCOL'}

HBase中存储额外的索引会占用额外的空间。布隆过滤器随着它们的索引对象的数据增长而增长,所以行级布隆过滤器比列标识符级布隆过滤器占用空间要少。
BLOOMFILTER参数的默认值是ROW,表示是行级布隆过滤器。
使用行级布隆过滤器需要设置为ROW,使用列标识符级布隆过滤器需要设置为ROWCOL。
行级布隆过滤器在数据块里检查特定行键是否不存在,列标识符级布隆过滤器检查行和列标识符联合体是否不存在。
ROWCOL布隆过滤器的开销要高于ROW布隆过滤器。

3.核心参数优化(hbase-site.xml)

  • hbase.hregion.majorcompaction
    大合并的间隔时间,默认为604800000毫秒(7天),如果设置为0则表示禁止自动的大合并,大合并的执行可能会持续数小时,为了减少对业务的影响,最好在业务低峰期进行手动或者通过API手动触发进行大合并。
  • hbase.hregion.max.filesize
    默认为10737418240 Byte(10G),当Region达到这个阈值时,会自动分裂。Region分裂会有短暂的Region下线时间(通常在5s以内),为减少对业务端的影响,建议调大该值,并在业务低峰期定时手动进行分裂。
  • hbase.regionserver.handler.count
    该配置参数用于定义regionserver上用于等待响应用户表级请求的线程数,默认30,对于大负载的Put(达到了M范围)或是大范围的Scan操作,handler数目不易过大,易造成OOM(内存溢出)。 对于小负载的put、get,delete等操作,handler数要适当调大。
  • hbase.hregion.memstore.flush.size
    默认值134217728 Byte (128M),单位字节,这个参数是Memstore中数据持久化到Storefile的时机,超过该阈值,则会把Memstore中的数据持久化到Storefile中,如果Regionserver的JVM内存比较充足(例如:16G以上),可以适当调大该值,例如:调整为256M。这样可以减少Memstore中数据溢写文件的次数。
  • hbase.hregion.memstore.block.multiplier
    默认值4,当一个 Region 中所有 MemStore 总大小达到或超过hbase.hregion.memstore.flush.size * hbase.hregion.memstore.block.multiplier,则会阻塞该Region所有的写操作(当一个 MemStore 大小达到阈值 hbase.hregion.memstore.flush.size(默认128M)时,会触发 MemStore 的刷写。但是这个时候不会阻塞写请求),为避免阻塞,可以适当调大,例如6~8,但如果太大,则会有OOM的风险。 如果在Regionserver日志中出现"Blocking updates for ‘’ on region : memstore size <多少M> is >= than blocking <多少M> size"的信息时,说明这个值该调整了。
  • hbase.hstore.compaction.min
    默认值为3,如果任何一个Store里的Storefile总数超过该值,会触发默认的合并操作,可以设置5~8,在手动的定期大合并中进行Storefile文件的合并,减少合并的次数,不过这会延长合并的时间。
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值