HBase数据热点问题

讨论一个问题。
对于 用户ID + 某记录ID 这样的key。查询场景为查询 用户ID 对应的所有记录。
多数情况下,普通用户记录数不超过1万条,如果用户ID是散列的,那个整个表基本算散列。
但是如果有个别大用户,他的某记录数是百/千万级别的,那么就可能会产生热点。
这种用户可能多数情况下又不一定能提前识别。
如果前面再加salt,又会增加查询复杂度。
这个情况如何去规避。
已邀请:

hmaster

赞同来自: isnker

好问题,目前我的方法是在数据早期的时候,发现某些分区数据表较多,然后自己去split的。
通常我的业务是按月建表,所以某个分区段,数据量比较多,然后split后,选取最终合适的splitkey。
下一个月建表的时候,进行修正,可以控制某个region有一定的数据范围。
 
但是有些业务确实没法搞。
 
如果记录的ID可以在业务中生成带有数字范围的标记的话,比如记录的id是1~1000万。
是不是可以设置这样的slat(用户id+hash_partition_of_记录id),
如用户为1,但是用户记录id按照1万单位做partition。如100_xxx,100000_xxx两个记录id,
则100属于0的partition,
100000属于10的partition。
 
rowkey 为:
hash_slat(用户id+0)+用户id :1万以下大部分为0 ,
hash_slat(用户id+10)+用户id:属于100000哪个范围的数据
 
查询的时候,则比较麻烦一些:
 
hash_slat(用户id+0)+用户id ,
 
hash_slat(用户id+1)+用户id 
 
hash_slat(用户id+...)+用户id 
 
 
不知道是否可行,业务中没有实践过
 

lvwenyuan

赞同来自:

我在想如果可以实现一个表级别的balance,那么问题就解决了

qgxiaozhan

赞同来自:

个别大用户,他的某记录数是百/千万级别 ,只能慢慢scan了,而且也可能返回这么多吧,所以我觉得id + 记录就可以,剩下的业务妥协一下。别搞的太复杂了。

要回复问题请先登录注册