HBase一次慢查询请求的问题排查与解决过程

本文记录了一次HBase集群遭遇慢查询问题的详细排查与解决过程。问题表现为在scan少量数据时,部分region响应时间长达10秒至几十秒。通过监控发现表有大量过期但未清除的数据,导致查询效率低下。解决方案包括导入数据后强制major compact和调整major compact周期以匹配TTL,确保过期数据及时清理。
摘要由CSDN通过智能技术生成

出自: http://www.cnblogs.com/panfeng412/archive/2013/06/08/hbase-slow-query-troubleshooting.html

最近HBase集群遇到过一次慢查询请求的问题,下面是对这一问题的具体描述及排查解决过程。

1. 发现问题

项目中有一张HBase表,每天凌晨以后会集中批量导入一批数据,导入数据量很大,在千万到亿的量级,然后白天为用户提供查询服务。某天突然发现,该表按照各个region(共计256个)分别仅scan少数几条数据时,部分region的查询请求的响应时间很慢,长达10秒甚至几十秒不等。

2. 排查问题

首先,通过查看HBase自带的region server监控界面上,看到这张表的每个region下面只有1~3个StoreFile,排除了由于StoreFile过多导致查询响应慢的情况。

接着排查,发现这张表的TTL为5天,因此会有大量过期数据存在。同时,由于这张表每天早上会导入一批数据(其中上周3.22那天集中导入了7亿多条记录),而集群的major compact周期配置是7天,虽然到今天为止3.22号的数据已经过期了,但是还没有经过major compact触发清除过期的数据,因此,存在大量过期但尚未被清除的数据,导致即使按照各个region分别仅scan少数几条数据,仍需要过滤掉一大批过期的数据(从监控看到当时的Block Cache访问量比平时高了一倍左右,如下图所示),才能扫到实际有用的数据,所以查询响应时间很慢。

3. 解决问题

针对这一问题,有以下两种解决方法:

1)每天早上导入数据后,强制触发一次major compact操作(见HBaseAdmin的majorCompct方法,异步执行),使得表中每个region中的过期数据可以被及时清除掉。

2)由于集群的major compact周期为7天,而表的TTL为5天,因此可以将major compact周期调小(配置参数为hbase.hregion.majorcompaction,单位为毫秒;同时,hbase.offpeak.start.hour可以设置major compact启动的小时,例如,设置为1,可保证在1点后触发),从集群级别保证major compact尽早触发执行。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值