HBase RowKey与索引设计 |「Hbase2.0常见问题性优化小总结续集」

大数据真好玩

发布于 2021-11-05 09:56:51

1.4K0

发布于 2021-11-05 09:56:51

文章被收录于专栏：暴走大数据暴走大数据

1. HBase的存储形式

hbase的内部使用KeyValue的形式存储，其key时rowKey：family:column:logTime,value是其存储的内容。

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

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

在做RowKey设计时，请先考虑业务是读比写多，还是读比写少，HBase本身是为写优化的，即便是这样，也可能会出现热点问题，而如果我们读比较多的话，除了考虑以上RowKey设计原则外，还可以考虑HBase的Coprocessor甚至elasticSearch结合的方法，无论哪种方式，都建议做实际业务场景下数据的压力测试以得到最优结果。

2. RowKey的设计原则

2.1 长度原则

rowKey是一个二进制，RowKey的长度被很多开发者建议说设计在10~100个字节，以byte[]形式保存，最大不能超过64kb。建议越短越好，不要超过16个字节。

太长的影响有几点点：

一是HBase的持久化文件HFile是按照KeyValue存储的，如果RowKey过长，比如说500个字节，1000万列数据，光是RowKey就要占用500*1000万=50亿个字节，将近1G数据，极大影响了HFile的存储效率。
二是缓存MemStore缓存部分数据到内存中，如果RowKey字段过长，内存的有效利用率会降低，系统无法缓存更多的数据，降低检索效率。目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。

注意：不仅RowKey的长度是越短越好，而且列簇名、列名等尽量使用短名字，因为HBase属于列式数据库，这些名字都是会写入到HBase的持久化文件HFile中去，过长的RowKey、列簇、列名都会导致整体的存储量成倍增加。

2.2 唯一原则

保证rowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若HBase中同一表插入相同RowKey，则原先的数据会被覆盖掉（如果表的version设置为1的话）。

2.3 散列原则

设计的RowKey应均匀分布在各个HBase节点上。如RowKey是按系统时间戳的方式递增，RowKey的第一部分如果是时间戳的话，将造成所有新数据都在一个RegionServer堆积的热点现象，也就是通常说的Region热点问题,热点发生在大量的client直接访问集中在个别RegionServer上(访问可能是读、写或者其他操作),导致单个RegionServer机器自身负载过高，引起性能下降甚至Region不可用，常见的是发生jvm full gc或者显示region too busy异常情况。

3. 在不同访问模式下设计行健

3.1 为写优化（解决热点问题）

当往HBase表写入大量数据时，需要在RegionServer上分散负载来进行优化。这并不难，但是你可能不得不在读模式优化上付出代价。比如，时间序列数据的例子，如果你的数据直接使用时间戳做行健，在写入时在单个region上会遇到热点问题。

许多使用场景下，并不需要基于单个时间戳访问数据。你可能要运行一个作业在一个时间区间上做聚合计算，如果对时间延迟不敏感，可以考虑跨多个region做并行扫描来完成任务。但问题是，应该如何把数据分散在多个region上呢？有几个选项可以考虑，答案取决于你想让行健包含什么信息。

散列:如果你愿意在行健里放弃时间戳信息（每次你做什么事情都要扫描全表，或者每次要读数据时你都知道精确的键，这些情况下也是可行的），使用原始数据的散列值作为行健是一种可能的解决方案:

hash('TheRealMT') -> random byte[]

每次当你需要访问以这个散列值为键的行时，需要精确知道TheRealMT。时间序列数据一般不这样处理。当你访问数据时，可能记住了一个时间范围，但不大可能知道精确的时间戳。但是有些情况下，能够计算散列值从而找到正确的行。为了得到一种跨所有region的、优秀的分布策略，你可以使用MD5、SHA-1或者其他提供随机分布的散列数。

salting:当你思考行健的构成时，salting是另一种技巧。让我们考虑之前的时间序列数据例子。假设你在读取时知道时间范围，但不想做全表扫描。对时间戳做散列运算然后把散列值作为行健的做法需要做全表扫描，这是很低效的，尤其是在你有办法限制扫描范围的时候。使用散列值作为行健在这里不是办法，但是你可以在时间戳前面加上一个随机数前缀。

例如，你可以先计算时间戳的散列码，然后用RegionServer的数量取模来生成随机salt数：

int salt = new Integer(new Long(timestamp).hashCode()).shortValue() % <number of region servers>

取到salt数后，加到时间戳的前面生成行健:

byte[] rowKey = Bytes.add(Bytes.toBytes(salt) + Bytes.toBytes("|") + Bytes.toBytes(timestamp))

现在行键如下图所示：

你可以想到，这些行将会基于键的第一部分，也就是随机salt数，分布在各个region。

但并非一切都是完美的。现在读操作需要把扫描命令分散到所有region上来查找相应的行。因为它们不再存储在一起，所以一个短扫描不能解决问题了。这是一种权衡，为了搭建成功的应用你需要做出选择。这是一个利用信息的位置来获得跨region分布的经典例子。

Reverse反转:针对固定长度的RowKey反转后存储，这样可以使RowKey中经常改变的部分放在最前面，可以有效的随机RowKey。反转RowKey的例子通常以手机举例，可以将手机号反转后的字符串作为RowKey，这样就避免了以手机号那样比较固定开头导致热点问题。这样做的缺点是牺牲了RowKey的有序性。

3.2 为读优化

时间戳反转。一个常见的数据处理问题是快速获取数据的最新版本，使用反转的时间戳作为RowKey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp追加到key的末尾。举例，在设计推帖流表时，你的焦点是为读优化行健，目的是把推帖流里最新的推帖存储在一起，以便于它们可以被快速读取，而不用做开销很大的硬盘搜索。在推贴流表里，你使用倒序时间戳（Long.MAX_VALUE - 时间戳）然后附加上用户ID来构成行健。现在你基于用户ID扫描紧邻的n行就可以找到用户需要的n条最新推帖。这里行健的结构对于读性能很重要。把用户ID放在开头有助于你设置扫描，可以轻松定义起始键。

4. HBase的RowKey设计应用实例

4.1 设计订单状态表

设计模式：反转+时间戳反转

RowKey：reverser(order_id) + (Long.MAX_VALUE - timestamp)

这样设计的好处一是通过reverse订单号避免Region热点，二是可以按时间倒排显示，可以获取到最新的订单。

同样适用于需要保存一个用户的操作记录，按照操作时间倒序排序。设计的rowKey为:reverser(userId) + (Long.MAX_VALUE - timestamp)。如果需要查询某段时间的操作记录,startRow是[userId反转][Long.MAX_VALUE - 结束时间],stopRow是[userId反转][Long.MAX_VALUE - 起始时间]。

4.2 登录、下单等等统称事件(event)的临时存储

HBase只存储了最近10分钟的热数据。

设计模式：salt加盐。

RowKey：两位随机数Salt + eventId + Date + kafka的Offset

这样设计的好处是：设计加盐的目的是为了增加查询的并发性，假如Salt的范围是0~n，那我们在查询的时候，可以将数据分为n个split同时做scan操作。经过我们的多次测试验证，增加并发度能够将整体的查询速度提升5~20倍以上。随后的eventId和Date是用来做范围Scan来使用的。在我们的查询场景中，大部分都是指定了eventId的，因此我们在eventId放在了第二个位置上，同时呢，通过Salt + eventId的方式可以保证不会形成热点。把date放在RowKey的第三个位置上可以实现date做scan，批量Scan性能甚至可以做到毫秒级返回。

这样的RowKey设计能够很好的支持如下几个查询场景:

全表scan。在这种情况下，我们仍然可以将全表数据切分成n份并发查询，从而实现查询的实时响应。
只按照event_id查询。
按照event_id和date查询。

5. HBase索引设计

数据库查询可简单分解为两个步骤：1）键的查找；2) 数据的查找

因这两种数据组织方式的不同，在RDBMS领域有两种常见的数据组织表结构：

索引组织表：键与数据存放在一起，查找到键所在的位置则意味着查找到数据本身。

堆表：键的存储与数据的存储是分离的。查找到键的位置，只能获取到数据的物理地址，还需要基于该地址去获取数据。

HBase数据表其实是一种索引组织表结构：查找到RowKey所在的位置则意味着找到数据本身。因此，RowKey本身就是一种索引。

5.1 RowKey查询的局限性/二级索引需求背景

如果提供的查询条件能够尽可能丰富的描述RowKey的前缀信息，则查询时延越能得到保障。如下面几种组合条件场景：

Name + Phone + ID
Name + Phone
Name

如果查询条件不能提供Name信息，则RowKey的前缀条件是无法确定的，此时只能通过全表扫描的方式来查找结果。

一种业务模型的用户数据RowKey，只能采用单一结构设计。但事实上，查询场景可能是多纬度的。例如，在上面的场景基础上，还需要单独基于Phone列进行查询。这是HBase二级索引出现的背景。即，二级索引是为了让HBase能够提供更多纬度的查询能力。

注：HBase原生并不支持二级索引方案，但基于HBase的KeyValue数据模型与API，可以轻易的构建出二级索引数据。Phoenix提供了两种索引方案，而一些大厂家也都提供了自己的二级索引实现。

5.2 HBase 二级索引方案

5.2.1 基于Coprocessor方案

从0.94版本，HBase官方文档已经提出了HBase上面实现二级索引的一种路径：

基于Coprocessor（0.92版本引入，达到支持类似传统RDBMS的触发器的行为）。开发自定义数据处理逻辑，采用数据“双写”策略，在有数据写入同时同步到二级索引表。

5.2.1.1 开源方案：

业界比较知名的基于Coprocessor的开源方案：

华为的hindex：基于0.94版本，但版本比较旧，github上几年都没更新过。
Apache Phoenix：功能围绕SQL On HBase，支持和兼容多个hbase版本，二级索引只是其中一块功能。二级索引的创建和管理直接有SQL语法支持，适用起来简便，该项目目前社区活跃度和版本更新迭代情况都比较好。

Apache Phoenix在目前开源的方案中，是一个比较优的选择，主打SQL On HBase，基于SQL能完成HBase的CRUD操作，支持JDBC协议。

5.2.1.2 Phoenix二级索引特点

Covered Indexes（覆盖索引）：把关注的数据字段也附在索引表上，只需要通过索引表就能返回所要查询的数据（列），所以索引的列必须包含所需查询的列（SELECT的列和WHERE的列）。
Functional Indexes（函数索引）：索引不局限于列，支持任意的表达式来创建索引。
Global Indexes（全局索引）：适用于读多写少场景。通过维护全局索引表，所有的更新和写操作都会引起索引的更新，写入性能受到影响。在读数据时，Phoenix SQL会基于索引字段，执行快速查询。
Local Indexes（本地索引）：适用于写多读少场景。在数据写入时，索引数据和表数据都会存储在本地。在数据读取时，由于无法预先确定region的位置，所以在读取数据时需要检查每个region（以找到索引数据），会带来一定性能（网络）开销。