关于热点问题，我简单陈述容易理解：
我们最开始hbase创建表默认是一个region，而我们所谓的热点问题其实就是对某一个region的过量访问造成的
Hbase当发现一个region存储数据量大于阈值（默认10G）时，会分裂region变成两个，此时访问此表数据会被阻塞，直到分裂成功才可继续访问
综上问题，我们需要在建表的时候就预分区(分区就是region)，分区语句例如：
create ‘test_region’,‘info’,‘info2’,SPLITS => [‘1’,‘2’,‘3’,‘4’,‘5’,‘6’,‘7’,‘8’,‘9’]
此时我们region个数是九个，可以通过hbaseUI看到，端口号为：16010
进去后点击表:
Regin的取值范围分别是：
[无穷小, 1)
[1, 2)
[2, 3)
等等
[9, 无穷大]
记住是左闭右开区间
要记住hbase默认是字典排序，例如：
第一个region:
-123
0
01
0123
0232
第二个region:
1
123
134234asdsa
198343
等等
这里我强调一下，你的数据到底放到哪个region中，关键在于你的rowkey第一个元素,如果元素开头是3，那么会放在region4中！
因为region4的取值范围是[3,4)
那么当我们预分区做好后，只完成了第一步，并不算解决热点问题，还需要我们在程序中设计好我们的rowkey
举个例子，如果我们的rowkey设计成手机号，那就还是有热点问题
因为手机号都是1开头，自然我们所有的数据都会放到第一个region中
Region1:
136……
158…
185….
等等
那么简单的做法是将手机号倒序，这样就可以均匀的放置在各个region中了
取数据的时候先将手机号倒序去查找表中的region即可找到
那么有人会问，我们既然预分区为10个region，hbase还会自动给我们region分区吗
答案是：会的
当我们某一个region大于了默认阈值10G后，此region会被hbase自动分区
但这并不可怕，我们只需要在创建表的时候，先预估出我们可能需要的数据量
和服务器个数即可以提前预分区实现负载均衡
即使后期数据增大，例如，我们预分区了100个region，随着数据增加有1，2个region自动分区，对我们也是透明的，也不会太影响性能, 一台服务器最好放2~3个region即可，也就是说region个数最好等于服务器总数*3 即可
继续回到rowkey设计，rowkey还可以有另一种设计，可以用hash散列的方式：
将你的rowkey(手机号) % 分区数 取余 做为rowkey的第一个元素即可，例如
0_18518885160
1_11111111111
等等
这样rowkey的首个元素就会将此rowkey放置到对应的region中
后期取数也是手机号 % 分区数 取余 + 原本rowkey 即可获取数据
此时相同的手机号还放在了同一个region中，解决了跨region读取数据问题
那么如果我们觉得一个手机号好多年的数据都放在一个region不太好，想要按月份将此手机号放在一个分区中，也可以实现：
用(手机号(18518885161)+年份(2020)+月份(02)) % 分区数 取余作为rowkey的第一个元素即可，例如:
(18518885161202002 % 10)_18518885161
此时region的分区是按照手机号和年份月份来存储的！
如果想要按年份存储也可以：(手机号+年份) % 分区数 取余作为rowkey的第一个元素即可
那么，如果我们还想让rowkey根据最近时间排序，我们可以再在后面加上Long.maxValue - 时间戳，例如：
0_18518885160_Long.maxValue - 时间戳
1_111111111111_Long.maxValue - 时间戳
时间戳是递增的，而Long.maxValue是固定的，所以时间戳越大
此时的后缀值就越小，那么也就最靠前
即使后面region分裂也不影响，为什么呢，因为即使一个region分裂为两个region
这两个region范围和，依然是之前的一个region的范围：
比如，region [2,3) 分裂了，假设分裂后的两个region是
Region1
[2,2555555555)
Region2:
[2555555555,3)
对我们程序而言依然是透明的，无需担心
至此hbase热点问题解决，还有不懂得小伙伴可以下面评论，看到后会解答
