HBase RowKey与索引设计

时间:2022-12-14 22:03:58

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上呢?有几个选项可以考虑,答案取决于你想让行健包含什么信息。

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

HBase RowKey与索引设计

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

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

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

HBase RowKey与索引设计

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

HBase RowKey与索引设计

   现在行健如下所示:

HBase RowKey与索引设计

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

   0|timestamp1,0|timestamp5和0|timestamp6将进入一个region,除非发生region拆分(拆分的情况下会分散到两个region)。1|timestamp2,1|timestamp9进入另一个不同的region,2|timestamp4,2|timestamp8进入第三个region。连续时间戳的数据散列进入了多个region。

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

3. 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设计能够很好的支持如下几个查询场景:

  1. 全表scan。在这种情况下,我们仍然可以将全表数据切分成n份并发查询,从而实现查询的实时响应。
  2. 只按照event_id查询。
  3. 按照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(以找到索引数据),会带来一定性能(网络)开销。

5.2.2 非Coprocessor方案

选择不基于Coprocessor开发,自行在外部构建和维护索引关系也是另外一种方式。

常见的是采用底层基于Apache Lucene的ElasticSearch(下面简称ES)或Apache Solr,来构建强大的索引能力、搜索能力,例如支持模糊查询、全文检索、组合查询、排序等。

其实对于在外部自定义构建二级索引的方式,有自己的大数据团队的公司一般都会针对自己的业务场景进行优化,自行构建ES/Solr的搜索集群。例如数说故事企业内部的百亿级数据全量库,就是基于ES构建海量索引和检索能力的案例。主要有优化点包括:

  • 对企业的索引集群面向的业务场景和模式定制,对通用数据模型进行抽象和平台话复用
  • 需要针对多业务、多项目场景进行ES集群资源的合理划分和运维管理
  • 查询需要针对多索引集群、跨集群查询进行优化
  • 共用集群场景需要做好防护、监控、限流

下面显示了数说基于ES做二级索引的两种构建流程,包含:

  • 增量索引:日常持续接入的数据源,进行增量的索引更新
  • 全量索引:配套基于Spark/MR的批量索引创建/更新程序,用于初次或重建已有HBase库表的索引。

HBase RowKey与索引设计

数据查询流程:

HBase RowKey与索引设计

6. HBase表设计关注点

HBase表设计通常可以是宽表(wide table)模式,即一行包括很多列。同样的信息也可以用高表(tall table)形式存储,通常高表的性能比宽表要高出50%以上,所以推荐大家使用高表来完成表设计。表设计时,我们也应该要考虑HBase数据库的一些特性:

  1. 在HBase表中是通过RowKey的字典序来进行数据排序的。
  2. 所有存储在HBase表中的数据都是二进制的字节。
  3. 原子性只在行内保证,HBase不支持跨行事务。
  4. 列簇(Column Family)在表创建之前就要定义好
  5. 列簇中的列标识(Column Qualifier)可以在表创建完以后动态插入数据时添加。

总结

参考资料:

《HBase实战》

https://www.cnblogs.com/parent-absent-son/p/10200202.html

https://blog.csdn.net/wangshuminjava/article/details/80575864

https://www.cnblogs.com/yuguoshuo/p/6265649.html

http://www.nosqlnotes.com/technotes/hbase/hbase-rowkey/

https://zhuanlan.zhihu.com/p/43972378