推荐大家去看原文博主的文章，条理清晰阅读方便，转载是为了方便以后个人查阅 https://www.cnblogs.com/i80386/p/3696492.html 需求描述： 扫描（查询）某个区间---》列用hbase多节点的资源，分布式扫描，加快速度==》 然后拼接到一起 如何打散数据 冠字号逆序，hash并不一定数据连续就会造成热点，这个是由数据访问模式决定的。 ex:时间作为rowkey，但查询经常按一个时间段来查询=====》 时间作为rowkey会造成时间差不多的在一个region，这就会造成region server 压力大，===》形成热点 ex：不按照时间段查询，简单的全局扫描，这个就不是热点===》例如爬虫的需求。 http://www.udpwork.com/item/11992.html 人民币冠字号作为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的性能。