标签：热点问题 region RowKey 全表 rowkey 设计 HBase 分区

　　但凡使用到HBase，数据量绝对不会少，这时候就需要考虑到查询的效率问题，以及可能出现的数据倾斜问题（热点问题）。我们可以同过对rowkey进行设计，规划一个合理的预分区，让数据散列的分布在各个分区上。

　　因此：rowkey设计时就要考虑到一个预分区的问题；同样，预分区也不可背离开rowkey而随意设置

• 　　预分区的个数大体上取决于两个方面：

1. 集群规模大小；（一般一个节点上三个分区）
2. 数据量的大小；（主要是估算以后的数据）

• 　　RowKey设计原则：

1. 散列性（重点）
2. 唯一性（rowkey唯一）
3. 长度原则（生产环境中一般70-100位）

散列性： 

• 1. 生成随机数、hash值、散列值
• 2. 字符串反转
• 3. 字符串拼接

　　由此可见，避免热点的关键操作：

　　　　　　1.预分区　　　　2.rowkey设计

• 1.预分区

　　　　在创建表的时候，配置一些策略，让一张表有多个region，分布在不同的regionserver上；

　　　  HBase自身会进行split，默认一个region，当他过大超过阈值（默认10G），会切分为两个Region，分布到新的regionserver上，父region下线。

• 2.rowkey设计

1. 反转：例如时间戳，手机号。（缺点：将原表数据打乱分布在不同region上，进行全表扫描时，会从多个甚至所有region来获取数据）
2. 加盐：在rowkey前面增加随机数。（缺点：无法指定rowkey进行查询，因为你不知道rowkey前面增加的随机数是什么）
3. Hash：根据rowkey中的某个部分或全部取hash，这样即便之后我们需要指定rowkey查询，也可以先进性hash得出新的rowkey来查找。（但也会造成全表扫描时，会从多个甚至所有region来获取数据）

　　综上：以上的rowkey设计原则，都是为了将数据离散、均匀地分布在集群中的每个regionserver上，对rowkey进行打散，势必会造成原表中的数据在存储时不再有序，导致scan全表扫描性能下降。

　　所以我们通常会添加二级索引进来，弥补以上设计原则带来的不便。

标签：热点问题,region,RowKey,全表,rowkey,设计,HBase,分区
来源： https://www.cnblogs.com/zyp0519/p/15621148.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。