hbase的热点问题

需求描述:
扫描(查询)某个区间—》列用hbase多节点的资源,分布式扫描,加快速度==》 然后拼接到一起 如何打散数据 冠字号逆序,hash
并不一定数据连续就会造成热点,这个是由数据访问模式决定的。
ex:时间作为rowkey,但查询经常按一个时间段来查询=====》 时间作为rowkey会造成时间差不多的在一个region,这就会造成region server 压力大,=》形成热点
ex:不按照时间段查询,简单的全局扫描,这个就不是热点=》例如爬虫的需求。
人民币冠字号作为rowkey,是连续的 ,会造成热点,所以要经过 hash打撒
爬虫是hostid_pid_urlid 就希望他存储到一块去,方便扫描,不担心热点
why why why why~~
访问次数少,但是连续读(也就是排序)的需求强的,就要放在一起。
访问次数多的,比如冠字号这种的,就得哈希打撒~~~
避免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的性能。

你可能感兴趣的:(hbase的热点问题)