HBase：RowKey的设计与优化 ——防止数据倾斜

一、RowKey的设计目的

一条数据的唯一标识就是 rowkey，那么这条数据存储于哪个分区，取决于rowkey 处于哪个一个预分区的区间内，设计 rowkey 的主要目的 ，就是让数据均匀的分布于所有的 region 中，在一定程度上防止数据倾斜

二、RowKey的设计原则

2.1 Rowkey长度原则

Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议设计在10-100个字节，不过建议是越短越好，不要超过16个字节。
原因如下：
（1）数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响Hfile的存储效率；
（2）MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率降低，系统将无法缓存更多的数据，这会降低检索效率，因此Rowkey的字节长度越短越好。
（3）目前操作系统一般都是64位系统，内存8字节对齐，空值在16个字节，8字节的整数倍利用操作系统的最佳特性。

2.2 Rowkey散列原则

如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。

2.3 Rowkey唯一原则

必须在设计Rowkey上保证其唯一性。

2.4 访问hbase table中的行，只有三种方式：

• 通过单个row key访问
• 通过row key的range
• 全表扫描

HBase的查询实现只提供两种方式：
1、按指定RowKey获取唯一一条记录，get方法（org.apache.hadoop.hbase.client.Get）
2、按指定的条件获取一批记录，scan方法（org.apache.hadoop.hbase.client.Scan）

实现条件查询功能使用的就是scan方式，scan在使用时有以下几点值得注意：

① scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；
② scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。
通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个 Region下），可以在遍历结果时获得很好的性能。
③scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。

三、RowKey的设计方案

3.1. SHA1 加密

散列值通常的呈现形式为40个十六进制数

比如：
原本 rowKey 为 1001 的， SHA1 后变成：
dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本 rowKey 为 3001 的， SHA1 后变成：
49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本 rowKey 为 5001 的， SHA1 后变成：
7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前，一般我们会选择从数据集中抽取样本，来决定什么样的 rowKey来 Hash 后作为每个分区的临界值

3.2. 字符串反转

反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没有意义的部分）放在前面。这样可以有效的随机rowkey，但是牺牲了rowkey的有序性。
例如：时间戳反转
20170524000001 转成 10000042507102
20170524000002 转成 20000042507102

在一定程度上散列逐步 put 进来的数据。

3.3.加盐（加随机数）

加盐能解决HBASE读写热点问题，例如:单调递增rowkey数据的持续写入，使得负载集中在某一个RegionServer上引起的热点问题。

3.4 哈希

对字段先加盐再哈希，散列开数据到不同的区或节点。目标要的结果是要均匀散列，避免某个节点积累大量的数据，出现倾斜情况。

3.5 拼接

两个字段拼在一起
例如：
20170524000001_a12e
20170524000001_93i7

以上方法都可以有效防止数据倾斜