案例篇-HBase RowKey 设计指南

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
简介: 吴阳平 阿里巴巴 HBase 业务架构师

1.为什么 Rowkey 这么重要

1.1 RowKey 到底是什么

_2019_01_10_10_19_07

我们常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好。可见 RowKey 在 HBase 中的地位。那么 RowKey 到底是什么?RowKey 的特点 如下:

  1. 类似于 MySQL、Oracle 中的主键,用于标示唯一的行;
  2. 完全是由用户指定的一串不重复的字符串;
  3. HBase 中的数据永远是根据 Rowkey 的字典排序来排序的。

1.2 RowKey 的作用

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

1.3 Rowkey 对查询的影响

如果我们的 RowKey 设计为 uid+phone+name,那么这种设计可以很好的支持
以下的场景:
uid = 111 AND phone = 123 AND name = iteblog uid = 111 AND phone = 123
uid = 111 AND phone = 12?
uid = 111
难以支持的场景:
phone = 123 AND name = iteblog phone = 123
name = iteblog

1.4 Rowkey 对 Region 划分影响

HBase表的数据是按照 Rowkey 来分散到不同 Region,不合理的 Rowkey 设计会导致热点问题。热点问题是大量的 Client 直接访问集群的一个或极少数个节点,而集群中的其他节点却处于相对空闲状态。

_2019_01_10_10_30_58

如上图,Region1 上的数据是 Region 2 的 5 倍,这样会导致 Region1 的访问 频率比较高,进而影响这个 Region 所在机器的其他 Region。

2.RowKey 设计技巧

我们如何避免上面说到的热点问题呢?这就是这章节谈到的三种方法。

2.1 避免热点的方法 – Salting

这里的加盐不是密码学中的加盐,而是在 rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中,加盐是很有用的。考虑下面的例子:它将写请求分散到多个RegionServers,但是对读造成了一些负面影响。
假如你有下列 rowkey,你表中每一个 region 对应字母表中每一个字母。以 'a' 开头是同一个 region, 'b'开头的是同一个 region。在表中,所有以 'f'开头的都在 同一个 region, 它们的 rowkey 像下面这样:

_2019_01_10_10_34_36

现在,假如你需要将上面这个 region 分散到 4 个 region。你可以用 4 个不同 的盐:'a', 'b', 'c', 'd'.在这个方案下,每一个字母前缀都会在不同的 region 中。 加盐之后,你有了下面的 rowkey:

_2019_01_10_10_35_12

所以,你可以向 4 个不同的 region 写,理论上说,如果所有人都向同一个 region 写的话,你将拥有之前 4 倍的吞吐量。
现在,如果再增加一行,它将随机分配 a,b,c,d 中的一个作为前缀,并以一个现有行作为尾部结束:

_2019_01_10_10_36_02

因为分配是随机的,所以如果你想要以字典序取回数据,你需要做更多工作。加盐这种方式增加了写时的吞吐量,但是当读时有了额外代价。

2.2 避免热点的方法 - Hashing

Hashing 的原理是计算 RowKey 的 hash 值,然后取 hash 的部分字符串和原来的 RowKey 进行拼接。这里说的 hash 包含 MD5、sha1、sha256 或 sha512 等算法。比如我们有如下的 RowKey:

_2019_01_10_10_37_09

我们使用 md5 计算这些 RowKey 的 hash 值,然后取前 6 位和原来的 RowKey 拼接得到新的 RowKey:

_2019_01_10_10_37_57

优缺点:可以一定程度打散整个数据集,但是不利于 Scan;比如我们使用 md5 算法,来计算 Rowkey 的 md5 值,然后截取前几位的字符串。subString(MD5(设备ID),0,x)+ 设备ID,其中x一般取5或6。

2.3 避免热点的方法 - Reversing

Reversing 的原理是反转一段固定长度或者全部的键。比如我们有以下 URL , 并作为 RowKey:

_2019_01_10_10_39_20

这些 URL 其实属于同一个域名,但是由于前面不一样,导致数据不在一起存放。 我们可以对其进行反转,如下:

_2019_01_10_10_39_54

经过这个之后,这些 URL 的数据就可以放一起了。

2.4 RowKey 的长度

RowKey 可以是任意的字符串,最大长度 64KB(因为 Rowlength 占 2 字节)。 建议越短越好,原因如下:

  1. 数据的持久化文件 HFile 中是按照 KeyValue 存储的,如果 rowkey 过长,比 如超过 100 字节,1000w 行数据,光 rowkey 就要占用 100*1000w=10 亿个字 节,将近 1G 数据,这样会极大影响 HFile 的存储效率;
  2. MemStore 将缓存部分数据到内存,如果 rowkey 字段过长,内存的有效利用率就会降低,系统不能缓存更多的数据,这样会降低检索效率;
  3. 目前操作系统都是 64 位系统,内存 8 字节对齐,控制在 16 个字节,8 字节的整数倍利用了操作系统的最佳特性。

3.RowKey 设计案例剖析

3.1 交易类表 Rowkey 设计

查询某个卖家某段时间内的交易记录
sellerId + timestamp + orderId

查询某个买家某段时间内的交易记录
buyerId + timestamp +orderId

根据订单号查询 orderNo
如果某个商家卖了很多商品,可以如下设计 Rowkey 实现快速搜索salt+sellerId + timestamp 其中,salt 是随机数。
可以支持的场景:

  1. 全表 Scan
  2. 按照 sellerId 查询
  3. 按照 sellerId + timestamp 查询

3.2 金融风控 Rowkey 设计

查询某个用户的用户画像数据

  1. prefix + uid
  2. prefix + idcard
  3. prefix + tele
    其中 prefix = substr(md5(uid),0 ,x), x 取 5-6。uid、idcard 以及 tele 分别表示 用户唯一标识符、身份证、手机号码。

3.3 车联网 Rowkey 设计 查询某辆车在某个时间范围的交易记录
carId + timestamp
某批次的车太多,造成热点
prefix + carId + timestamp 其中 prefix = substr(md5(uid),0 ,x)

3.4 查询最近的数据
查询用户最新的操作记录或者查询用户某段时间的操作记录,RowKey 设计如下: uid + Long.Max_Value - timestamp
支持的场景

查询用户最新的操作记录
Scan [uid] startRow uid stopRow uid

查询用户某段时间的操作记录
Scan [uid] startRow uid stopRow uid

如果 RowKey 无法满足我们的需求,可以尝试二级索引。Phoenix、Solr 以及 ElasticSearch 都可以用于构建二级索引。

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
  相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情: https://cn.aliyun.com/product/hbase   ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
7月前
|
SQL 关系型数据库 MySQL
Sqoop【付诸实践 01】Sqoop1最新版 MySQL与HDFS\Hive\HBase 核心导入导出案例分享+多个WRAN及Exception问题处理(一篇即可学会在日常工作中使用Sqoop)
【2月更文挑战第9天】Sqoop【付诸实践 01】Sqoop1最新版 MySQL与HDFS\Hive\HBase 核心导入导出案例分享+多个WRAN及Exception问题处理(一篇即可学会在日常工作中使用Sqoop)
284 7
|
7月前
|
数据可视化 JavaScript 关系型数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(五)FineBI可视化
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(五)FineBI可视化
133 0
|
7月前
|
SQL 消息中间件 关系型数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(四)实时计算需求及技术方案
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(四)实时计算需求及技术方案
202 0
|
7月前
|
SQL 消息中间件 分布式数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(三)离线分析
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(三)离线分析
131 0
|
7月前
|
消息中间件 存储 数据采集
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(二)数据源
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(二)数据源
109 0
|
7月前
|
存储 消息中间件 分布式数据库
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(一)案例需求
基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(一)案例需求
103 0
|
存储 SQL 分布式数据库
分布式数据恢复-hbase+hive分布式存储数据恢复案例
hbase+hive分布式存储数据恢复环境: 16台某品牌R730XD服务器节点,每台物理服务器节点上有数台虚拟机,虚拟机上配置的分布式,上层部署hbase数据库+hive数据仓库。 hbase+hive分布式存储故障&初检: 数据库文件被误删除,数据库无法使用。 通过现场对该分布式环境的初步检测,发现虚拟机还可以正常启动,虚拟机里面的数据库块文件丢失。好在块文件丢失之后没有对集群环境写入数据,底层数据损坏可能性比较小。
|
SQL 分布式数据库 Apache
|
存储 关系型数据库 分布式数据库
|
分布式计算 分布式数据库 Scala
Spark查询Hbase小案例
写作目的 1)正好有些Spark连接HBase的需求,当个笔记本,到时候自己在写的时候,可以看 2)根据rowkey查询其实我还是查询了好久才找到,所以整理了一下 3)好久没发博客了,水一篇
212 0
Spark查询Hbase小案例