HBase系列（四）、HBase优化之RowKey 设计

古城微笑少年丶 2022-12-06 01:17 358阅读 0赞

**目录**

前言

RowKey设计

设计原则

解决热点问题

Salt加盐

Reverse反转

Hash散列或Mod取余

--------------------

**HBase系列：**

*  [HBase系列（一）、数据模型][HBase] 
 *  [HBase系列（二）、架构原理][HBase 1]
 *  [HBase系列（三）、读写原理，Flush刷写，HFile Compact合并，Region Split切分][HBase_Flush_HFile Compact_Region Split]

--------------------

# 前言 #

上一篇中我们提到了HBase的读写原理，可以看出HBase是为写操作优化，更适合写多读少的场景，尤其是因为数据按列族和Region切分成一个个的StoreFile，在跨多文件查询数据的时候就会很慢。同时，由于Region切分策略，会让HFile出现数据倾斜的情况，因此我们在实际应用中首先要先设置预分区，指定HBase表有几个分区，每个分区内的RowKey范围，然后我们只要将RowKey的值尽可能均匀的放置在这些Region内即可。本篇我们就来介绍如何通过RowKey的设计提升HBase的读性能。

前面的文章中也提到，HBase只能通过RowKey查询数据：指定RowKey查询、指定RowKey区间查询、全表扫描。所以通常我们也会利用第三方组件如solr，elasticsearch对HBase做二级索引，提升查询效率，在后面的文章中再具体介绍。

# RowKey设计 #

## 设计原则 ##

Rowkey设计的优劣直接影响读写性能，HBase中的数据是按照RowKey的ASCII 字典顺序进行全局排序。ASCII码表：

![fde1300271526c9d42ed78469b01ef4d.png][]

**RowKey设计应遵循以下原则：**

**长度原则**

RowKey是一个二进制存储的值，RowKey的长度尽量控制在10~100个字节，建议是越短越好。 原因如下：

*  HFile 按照KeyValue存储，如果RowKey过长比如500个字节，1000万列数据光是RowKey就要占用500\*1000万=50亿个字节≈5GB数据，非常影响HFile的存储效率；
 *  MemStore中维护着Flush之前的数据，如果RowKey字段过长的话会占用很多内存，导致系统无法缓存更多的数据，影响查询效率；

**唯一原则**

由于RowKey用来唯一标识一行记录，所以必须在设计上保证RowKey的唯一性：

*  HBase中数据存储是Key-Value形式，若HBase中同一表插入相同Rowkey，则原先的数据会被覆盖掉(如果表的version设置为1的话)，所以务必保证Rowkey的唯一性；

**排序原则**

HBase会把RowKey按照ASCII进行自然有序排序，所以反过来我们在设计RowKey的时候可以根据这个特点来设计完美的RowKey，好好的利用这个特性就是排序原则；

**散列原则**

在上面也提到，只要我们尽量将数据均衡的分布在每个Region内，就可以预防数据倾斜的情况。假如按照时间戳作为rowkey的前缀会导致大量数据堆积在一个RegionServer上导致Region热点问题，当大量读写请求到该RegionServer上时会对该RS的负载压力过高从而影响性能甚至出现故障；

## 解决热点问题 ##

解决RegionServer热点现象需要良好的RowKey设计，让数据尽可能均匀的分布在每个Region下，通常有三种方案：加盐、反转、散列。

### Salt加盐 ###

在原RowKey的前面添加固定长度的随机数，也就是给RowKey分配一个随机前缀使它和之前的RowKey的开头不同。

**例**：在一个有3个Region以(,h)、\[h,x)、\[x,z)为Region分区的HBase表中，有下面三个rowkey：wykcsdn001,wykcsdn002,wykcsdn003 ，这三个rowkey会被分布在\[x,z)这个region内，加盐后变成**qwe\_**wykcsdn001,**asd\_**wykcsdn002,**zxc\_**wykcsdn003，这三个rowkey会被均匀分布在三个region分区内。

wykcsdn001-->**qwe\_**wykcsdn001

wykcsdn002-->**asd\_**wykcsdn002

wykcsdn003 -->**zxc\_**wykcsdn003

加盐之后的吞吐量是之前的三倍，但加盐也有缺点：盐是随机字符串，在查找的时候不知道该盐的内容，读这些数据时需要耗费更多的时间，所以加盐增加了写操作的吞吐量，不过缺点是同时增加了读操作的开销。

### Reverse反转 ###

针对固定长度的Rowkey进行反转，将Rowkey中经常改变的部分放在最前面，可以有效的随机Rowkey。典型的比如手机号，时间戳这类数据前缀几乎都是一样的，最后几位更有随机性。反转之后得到的字符串即保证了随机性又不会像加盐一样无法得知rowkey的真实值。但反转也牺牲了Rowkey的有序性。

**例**：

*182xxxx7890-->0987xxx281*

*182xxxx6379-->9736xxx281*

*182xxxx1355-->5531xxx281*

*20200911145043-->34054111900202*

*20200911145058-->85054111900202*

*20200911145501-->10554111900202*

### Hash散列或Mod取余 ###

hash比较好理解，将原来的rowkey内容或部分前缀通过hash算法（MD5、sha1、sha256、sha512）生成更加随机的字符串。相比于加盐的方式，hash后的字符串既可以使负载分散到整个集群，又可以通过原rowkey的值算出hash值来读取数据。

对于纯数字型的rowkey，也可以使用mod取余的方式来将其打散。

**例**：

*wyk001-->66079de6861d926bcd08da5878283601*

*wyk002-->344fd201bd135f5ad7d45ad5668e1438*

*wyk003-->81264b3ace502fec8c76a6991c0eeaed*

*123456789%21-->15*

*123459999%21-->12*

*123458888%21-->14*

在工作中，我们也可以结合项目的实际情况结合这几种方式来设计RowKey，以预防Region热点。

希望本文对你有帮助，请点个赞鼓励一下作者吧~ 谢谢！

[HBase]: https://blog.csdn.net/wsdc0521/article/details/108505644
[HBase 1]: https://blog.csdn.net/wsdc0521/article/details/108514052
[HBase_Flush_HFile Compact_Region Split]: https://blog.csdn.net/wsdc0521/article/details/108526266
[fde1300271526c9d42ed78469b01ef4d.png]: /images/20221123/0ef0a8baa15b4a0b9d12ef9994a76da5.png

发表评论取消回复

表情：

评论列表（有 0 条评论，358人围观）

还没有评论，来说两句吧...

相关阅读

相关 HBase的RowKey设计

base的rowkey设计是使用Hbase的重中之重，rowkey的设计会直接影响Hbase的使用效率。而且，基本可以保证的是，如果你简历中出现了Hbase这个关键词，那...

╰半夏微凉°/ 2024年04月18日 12:03/ 0 赞/ 74 阅读

相关 HBase之Rowkey设计总结

HBase之Rowkey设计总结及易观方舟实战篇 ![original.png][] [代立冬][Link 1] 2018-06-02 21:52:46 ![artic

痛定思痛。/ 2023年02月15日 12:48/ 0 赞/ 157 阅读

相关 HBase系列（四）、HBase优化之RowKey 设计

目录前言 RowKey设计设计原则解决热点问题 Salt加盐 Reverse反转 Hash散列或Mod取余 -------------------- H

古城微笑少年丶/ 2022年12月06日 01:17/ 0 赞/ 359 阅读

相关 HBase Rowkey 设计指南

HBase 的 Rowkey 设计可以说是使用 HBase 最为重要的事情，直接影响到HBase的性能 -------------------- 前言 RowKey 到底

￡神魔★判官ぃ/ 2022年11月27日 08:54/ 0 赞/ 161 阅读

相关 HBase之rowkey如何设计

1.HBase的存储形式 Key由RowKey(行键)+ColumnFamily（列族）+Column Qualifier（列修饰符）+TimeStamp（时间戳–版本）

ゝ一世哀愁。/ 2022年10月05日 05:46/ 1 赞/ 230 阅读

相关 hbase rowkey的设计

热点 HBase中的行按行按键按字典顺序排序。这种设计优化了扫描，允许您将相关的行或彼此靠近的行一起读取。但是，设计不佳的行键是热点的常见来源。当大量客户端流量针对群集中

╰半橙微兮°/ 2022年05月22日 00:26/ 0 赞/ 199 阅读

相关 HBase之Rowkey设计总结

本文转载自：[HBase之Rowkey设计总结及易观方舟实战篇][HBase_Rowkey] 一、引言 HBase由于其存储和读写的高性能，在OLAP即时分析中越来越发

雨点打透心脏的1/2处/ 2022年05月16日 04:22/ 0 赞/ 213 阅读

相关 Hbase优化之RowKey设计

1. Hbase的预分区 HBase默认建表时有一个region，这个region的rowkey是没有边界的，即没有startkey和endkey。在数据写入时，所有数据

迷南。/ 2022年05月08日 11:54/ 0 赞/ 295 阅读

相关 HBase RowKey设计原则

1. Hbase中定位一条数据对于关系型数据库，数据定位可以理解为“二维坐标”；但是hbase中需要四维来定位一个单元格，即\[行健、列族、列限定符、时间戳\] 2

刺骨的言语ヽ痛彻心扉/ 2022年05月08日 11:38/ 0 赞/ 210 阅读

相关 HBase Rowkey 设计

HBase中的rowkey唯一的决定了一行数据，使用HBase的场景多种多样， rowkey设计的好坏很大程度上决定了应用场景中的执行效率。通过具体的一个场景样例，简单的研

た入场券/ 2022年03月30日 09:15/ 0 赞/ 315 阅读