聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

Pora2应用中HBase高并发读写性能优化

2014-03-21 23:20 浏览: 1724041 次 我要评论(0 条) 字号:

淘宝搜索的个性化离线实时分析系统Pora已升级至Pora2,Pora2是在基于Yarn的流式计算框架IStream基础上开发的,同时为保证数据和消息的实时处理系统中较多地使用了HBase,是一个典型的高并发读写HBase的分布式应用。

系统在发布之初遇到了比较严重的性能问题,表现为处理速度跟不上实时日志,并且整个Hadoop/HBase集群压力大,连带其它应用受影响。经过排查发现问题主要都出现在了对HBase的使用上,现将遇到的几个典型的使用HBase的问题总结如下,希望能为其它类似应用正确使用HBase提供参考。

HBase的Periodic Flusher

从系统的各种统计指标分析,系统主要慢在了读写HBase的环节,观察HBase日志发现每个RegionServer都在频繁地flush和compact。分析后发现当前hbase版本里有一个Periodic Flusher的机制,memstore中的数据如果持续一段时间没有flush的话hbase会自动触发flush,这个时间间隔默认是1小时。了解了一下这是hbase 0.94.8以后引入的新feature,初衷是防止有些memstore长时间不flush,在没有开启wal且遇到region server挂掉时导致数据丢失。

由于我们的 hbase每个region server有将近100个region,几乎每分钟都有region因为达到一小时的时间间隔触发flush,而多数情况下每次flush的文件都很小,flush次数多了之后又会引起compaction,如此频繁的flush和compaction使得region server处理速度明显变慢。在我们将这个配置调整为10小时后,可以从下图中看到hbase flush queue size和fs pread latency都有明显变小。

altalt

注:个人觉得hbase的这个新feature应用场景很有限,实在不应该作为一个默认开启的配置,建议可以通过配置直接禁用。​

​不间断的频繁scan对region server造成较大压力

​​Pora2采用了一个基于HBase实现的消息队列Hqueue,下游使用方通过读这个消息队列,第一时间获取最新的消息进行处理。

读消息的过程相当于一次Scan,在一开始的Pora2版本中我们未对读Hqueue的频率进行控制,导致某些读HQueue的worker不停地发起新的Scan,即便Hqueue数据已经读完,仍会立刻重新创建Scan,而这个Scan会因为读不到数据很快结束之后又重新创建。这样不停地新建Scanner对Region Server端构成了不小的且是不必要的压力。

发现这个问题后我们修改了这部分程序代码,在读完数据后sleep几秒后再重新scan。

​在修改完hbase的配置并且加上读Hqueue的scan频率控制后,Pora2情况明显好转,但处理累积数据时的速度还是不够快。

​超大并发下的hbase问题

从统计指标上分析,系统还是慢在访问hbase上,访问hbase的日志中不时出现各种TimeOutException也可以说明这一点。跟踪日志中某些频繁报超时的regionserver发现,有些region server日志持续报以下异常:

alt

所在机器连接数很多,但load很低,而一旦pora2停了,这些现象就会很快消失。

从这一现象分析判断是Pora2对HBase的并发连接数太多了,使得region server的handler不够用,server端还没来得及处理请求,client端已经到了超时时间而断开。

为此我们大幅度减少了访问hbase的进程数以减少对hbase的并发连接,为了不降低处理能力,在进程内部使用更多的处理线程。由于线程间是共享对hbase的连接的,所以增加线程数不会增加对hbase的连接数。

通过这一调整,很大程度缓解了hbase region server的压力。

避免HBase访问热点

在作了较多优化改进后发现仍有几个worker比较慢,跟踪那几个慢的worker日志发现读HBase经常超时,找到超时的region server,从HMaster UI上观察到这个server的读写请求数明显是其它server的好几倍。开始怀疑是数据有倾斜,有热点region落到了这台机器上。在HBase UI上逐个检查Pora2用到的HBase表,果然在其中的一张表上发现它的第一个region的请求数比其它region高出一两个数量级。

按我们的设计预期,这个表的rowkey是加了hash前缀的,理论上不该有热点region,最终检查代码后才发现是生成rowkey的代码存在bug,生成前缀的代码用了 key.hashCode() % regionNum,结果有很多key的hashcode返回是负数,使得很多前缀是负数,全都落在了第一个region上。

而对hbase来说,一旦有一个region有热点,就会导致该region所在的region server变慢,进而使得这个server上其它表的region访问也慢,从而影响了整个hbase的性能。

Bulk load数据的Major Compaction

调查中还发现了一个Bulk load数据未执行Major Compaction引起的问题。

我们有一张表的数据是每天定时从HDFS中Bulk load到HBase里的,而且这张表的数据是只读的。结果几天下来后,因为没有数据写入,不会触发任何compaction,而每天都有新的HFile被Load进来,导致每个region下的HFile数越来越多,最终拖慢了这张表的读取性能。

发现问题后我们在每天的Bulk load结束后对这个表执行一次Major Compaction,有效解决了问题。

总结

高并发读写HBase的应用需要尽量保证对HBase的合理使用,不合理的使用有可能会导致某一个region server甚至整个hbase集群的性能出现问题,而hbase的性能问题又反过来使得所有应用性能下降,此时如果应用选择继续加大对hbase的并发访问,甚至有可能因此陷入一个性能继续变差的恶性循环。



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复