HBase之rowkey如何设计

ゝ一世哀愁。 2022-10-05 05:46 187阅读 1赞

## 1.HBase的存储形式 ##

Key由RowKey(行键)+ColumnFamily（列族）+Column Qualifier（列修饰符）+TimeStamp（时间戳–版本）+KeyType（类型）组成，而Value就是实际上的值。修改一条数据其实上是在原来的基础上增加一个版本的，那我们要**准确定位**一条数据，那就得（RowKey+Column+时间戳）。

其在region内大多以升序的形式排列，唯一的时logTime是以降序的形式进行排列。

所以，rowKey里越靠近左边的信息越容易被检索到。其设计时，要考虑把重要的信息放左边，不重要的信息放到右边。这样可以提高查询数据的速度。最重要的提高索引速度的就是设计合适的rowKey。

## 2.RowKey的作用 ##

#### 2.1 RowKey在查询中的作用 ####

HBase是三维有序存储的，通过rowkey（行键），column key（column family和qualifier）和TimeStamp（时间戳）这个三个维度可以对HBase中的数据进行快速定位。

HBase中RowKey可以唯一标识一行记录，在HBase中检索数据有以下三种方式：

> 1.  通过 **get** 方式，指定 **RowKey** 获取唯一一条记录
> 2.  通过 **scan** 方式，设置 **startRow** 和 **stopRow** 参数进行范围匹配
> 3.  **全表扫描**，即直接扫描整张表中所有行记录

当大量请求访问HBase集群的一个或少数几个节点，造成少数RegionServer的读写请求过多、负载过大，而其他RegionServer负载却很小，这样就造成**热点现象**。大量访问会使热点Region所在的主机负载过大，引起性能下降，甚至导致Region不可用。所以我们在向HBase中插入数据的时候，应尽量均衡地把记录分散到不同的Region里去，平衡每个Region的压力

#### 2.2 RowKey在Region的作用 ####

在 HBase 中，Region 相当于一个数据的分片，每个 Region 都有`StartRowKey`和`StopRowKey`，这是表示 Region 存储的 RowKey 的范围，HBase 表的数据时按照 RowKey 来分散到不同的 Region，要想将数据记录均衡的分散到不同的Region中去，因此需要 RowKey 满足这种散列的特点。此外，在数据读写过程中也是与RowKey 密切相关，RowKey在读写过程中的作用：

> 1.读写数据时通过 RowKey 找到对应的 Region
> 
> 2.MemStore 中的数据是按照 RowKey 的字典序排序
> 
> 3.HFile 中的数据是按照 RowKey 的字典序排序

#### 2.3 RowKey的设计原则 ####

**唯一原则**

必须在设计上保证RowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若向HBase中同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据覆盖。rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

**长度原则**

RowKey是一个二进制码流，可以是任意字符串，最大长度为64kb，实际应用中一般为10-100byte，以byte\[\]形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：

> 1.  数据的持久化文件HFile中时按照Key-Value存储的，如果RowKey过长，例如超过100byte，那么1000w行的记录，仅RowKey就需占用近1GB的空间。这样会极大影响HFile的存储效率。
> 2.  MemStore会缓存部分数据到内存中，若RowKey字段过长，内存的有效利用率就会降低，就不能缓存更多的数据，从而降低检索效率。
> 3.  目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。

**散列原则**

设计的RowKey应均匀的分布在各个HBase节点上。例如rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer

> 上面的情况是针对通过RowKey单个查询的业务的，如果我们是根据RowKey范围查询的，那没必要上面那样做。HBase将RowKey设计为字典序排序，如果不做限制，那很可能类似的RowKey存储在同一个HRegion中。那我正好有这个场景上的业务，那我查询的时候不是快多了吗？**在同一个HRegion就可以拿到我想要的数据了**。
> 
> 举个例子：如何间隔几秒采集直播间热度，将这份数据写到HBase中，然后业务方经常要把主播的一段时间内的热度给查询出来。
> 
> 我设计好的RowKey，将该主播的一段时间内的热度都写到同一个HRegion上，拉取的时候只要访问一个HRegionServer就可以得到全部我想要的数据了，那查询的速度就快很多。

#### 2.4 避免热点数据的方法 ####

##### 1、加盐 #####

这里所说的加盐不是密码学中的加盐，而是在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得它和之前的rowkey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的rowkey就会根据随机生成的前缀分散到各个region上，以避免热点。

> **缺点：**
> 
> 因为添加的是随机数，基于原RowKey查询时无法知道随机数是什么，那样在查询的时候就需要去各个可能的Regions中查找，Salting对于读取是利空的。并且加盐这种方式增加了读写时的吞吐量。

##### 2、反转 #####

第三种防止热点的方法时反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。

反转rowkey的例子以手机号为rowkey，可以将手机号反转后的字符串作为rowkey，这样的就避免了以手机号那样比较固定开头导致热点问题

> **缺点：**
> 
> 利于Get操作，但不利于Scan操作，因为数据在原RowKey上的自然顺序已经被打乱。

##### 3、哈希 #####

哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使用get操作准确获取某一个行数据

> **缺点：**
> 
> 与 反转类似，哈希也不利于 Scan，因为打乱了原RowKey的自然顺序。

#### 2.5 RowKey案例分析 ####

**1. 查询某用户在某应用中的操作记录**

> reverse(userid) + appid + timestamp

**2. 查询订单状态（优先展现最近的数据）**