HBase Prefix Scan性能问题思考

在双十一促销期间,业务发开反馈线上的一个集群的scan性能很差。打开Ambari Grafana监控看了一下rpc性能数据,确实有几个节点的RPC max.process.time响应时间稳定在1s以上。

从开发哪里得知scan请求是按照prefix条件进行的,而该集群是1.1.2老版本集群,没有用到2.x以上的prefix Bloom filter特性。

一、Scan性能异常和排查过程

1)通过开发提供的信息,可以排除热点问题,因为rowkey进过hash,请求也不是相同的。

2)开发按照prefix查询,每次返回100条,我手动手动hbase shell验证,请求时间在3s左右。

scan 't1', { ROWPREFIXFILTER => 'row2', LIMIT => 10 } 

3)因为hbase 1.1的slowlog日志很粗糙,没法看具体的执行状态,无法直接定位原因。

4)于是决定去看看数据的分布和locality信息,发布rpc响应时间较长的节点该表region的locality比较低,(恰好该表在该节点只有这个region),怀疑远程读取(remote read)比较消耗性能,对改region手动执行了major compact操作,该节点的RPC max.process.time恢复到50ms一下。

5)但是另外的节点上,数据的locality是1,RPC max.process.time 指标仍然在1s以上,说明hdfs remote read不是问题的根本原因。(磁盘读取量很小,用的SSD存储性能也比较好)

7)这时候想到另外一个东西,major comapct不仅可以提高locality,而且可以合并文件和删除过期和标记为删除状态的数据。之前和开发沟通过程中也了解大盘,数据scan出去之后,会从表中删除该行操作,该表可能会存在大量的删除数据。

8) 手动对整表做了major comapct,磁盘空间从10GB下降到不到800M。之后,业务scan操作恢复正常,没有任何的scan请求超时。

二、关于prefix scan性能思考

在2.0版本之前,prefix scan仅仅是在client scan发送请求时设置一下startRow和stopRow参数,在server端没有任何的更多的处理。

client端的实现比较简单,先按照row的有序性,把prefix scan转化成范围扫描(range scan,[startRow,endRow)闭开区间),减少数据扫描的范围。


转化后startRowkey为prefix,而endRowkey为紧邻prefix的一个字符串。比如prefix为abc,那么stop rowkey为abd;

计算算法如下:

此条目发表在hbase分类目录,贴了标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据