HBase Rowkey 设计指南

标签: | 发表时间:2018-12-27 20:41 | 作者:
出处:https://mp.weixin.qq.com

为什么Rowkey这么重要

RowKey 到底是什么

如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号: iteblog_hadoop

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

  • 类似于 MySQL、Oracle中的主键,用于标示唯一的行;

  • 完全是由用户指定的一串不重复的字符串;

  • HBase 中的数据永远是根据 Rowkey 的字典排序来排序的。

RowKey的作用

  • 读写数据时通过 RowKey 找到对应的 Region;

  • MemStore 中的数据按 RowKey 字典顺序排序;

  • HFile 中的数据按 RowKey 字典顺序排序。

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

Rowkey对Region划分影响

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

如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号: iteblog_hadoop

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

RowKey设计技巧

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

避免热点的方法 - Salting
这里的加盐不是密码学中的加盐,而是在rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀 以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。 如果你有一些 热点 rowkey 反复出现在其他分布均匀的 rwokey 中,加盐是很有用的。考虑下面的例子:它将写请求分散到多个 RegionServers,但是对读造成了一些负面影响。

假如你有下列 rowkey,你表中每一个 region 对应字母表中每一个字母。 以 'a' 开头是同一个region, 'b'开头的是同一个region。在表中,所有以 'f'开头的都在同一个 region, 它们的 rowkey 像下面这样:

  foo0001   
foo0002
foo0003
foo0004

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

  a-foo0003   
b-foo0001
c-foo0004
d-foo0002

所以,你可以向4个不同的 region 写,理论上说,如果所有人都向同一个region 写的话,你将拥有之前4倍的吞吐量。

现在,如果再增加一行,它将随机分配a,b,c,d中的一个作为前缀,并以一个现有行作为尾部结束:

  a-foo0003   
b-foo0001
c-foo0003
c-foo0004
d-foo0002

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

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

  foo0001   
foo0002
foo0003
foo0004

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

  95f18cfoo0001   
6ccc20foo0002
b61d00foo0003
1a7475foo0004

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

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

  flink.iteblog.com   
www.iteblog.com
carbondata.iteblog.com
def.iteblog.com

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

  moc.golbeti.knilf   
moc.golbeti.www
moc.golbeti.atadnobrac
moc.golbeti.fed

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

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

  • 数据的持久化文件HFile中是按照KeyValue存储的,如果rowkey过长,比如超过100字节,1000w行数据,光rowkey就要占用100*1000w=10亿个字节,将近1G数据,这样会极大影响HFile的存储效率;

  • MemStore将缓存部分数据到内存,如果rowkey字段过长,内存的有效利用率就会降低,系统不能缓存更多的数据,这样会降低检索效率;

  • 目前操作系统都是64位系统,内存8字节对齐,控制在16个字节,8字节的整数倍利用了操作系统的最佳特性。

RowKey 设计案例剖析

交易类表 Rowkey 设计

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

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

  • 根据订单号查询
    orderNo

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

    • 全表 Scan

    • 按照 sellerId 查询

    • 按照 sellerId + timestamp 查询

金融风控 Rowkey 设计

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

  • prefix + uid

  • prefix + idcard

  • prefix + tele

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

车联网 Rowkey 设计

  • 查询某辆车在某个时间范围的交易记录
    carId + timestamp

  • 某批次的车太多,造成热点
    prefix + carId + timestamp 其中 prefix = substr(md5(uid),0 ,x)

查询最近的数据

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

  • 查询用户最新的操作记录
    Scan [uid] startRow [uid][000000000000] stopRow [uid][Long.Max_Value - timestamp]

  • 查询用户某段时间的操作记录
    Scan [uid] startRow [uid][Long.Max_Value – startTime] stopRow [uid][Long.Max_Value - endTime]

OpenTSDB 的 Rowkey 设计

参见  OpenTSDB 底层 HBase 的 Rowkey 是如何设计的

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

相关 [hbase rowkey 设计] 推荐:

HBase RowKey 设计

- - IT瘾-dev
1.1 RowKey对查询的影响. HBase中 RowKey 用来唯一标识一行记录. 在 HBase 中检索数据有以下三种方式:. 通过 get 方式,指定 RowKey 获取唯一一条记录. 通过 scan 方式,设置 startRow 和 endRow 参数进行范围匹配. 全表扫描,即直接扫描整张表中所有行记录.

HBase Rowkey 设计指南

- -
为什么Rowkey这么重要. RowKey 到底是什么. 如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号: iteblog_hadoop. 我们常说看一张 HBase 表设计的好不好,就看它的 RowKey 设计的好不好. 可见 RowKey 在 HBase 中的地位.

hbase rowkey 设计(三维有序)

- - 经验沉淀 知识结晶
此文原创,转载请说明出处:http://ronxin999.blog.163.com/blog/static/4221792020130109202973/. 看这篇文章,你首先要了解hbase的基本存储模型,不懂的可以看我的文章,有做特别的说明. 今天难得有时间,写博文,特地总结下一直想写hbase的实践经验,在用hbase的过程中,我们都知道,rowkey设计的好坏,是我们能最大发挥hbase的架构优势,也是我们是否正确理解hbase的一个关键点.

HBase RowKey与索引设计 - 牧梦者 - 博客园

- -
hbase的内部使用KeyValue的形式存储,其key时rowKey:family:column:logTime,value是其存储的内容. 其在region内大多以升序的形式排列,唯一的时logTime是以降序的形式进行排列. 所以,rowKey里越靠近左边的信息越容易被检索到. 其设计时,要考虑把重要的信息放左边,不重要的信息放到右边.

HBase表设计

- - 互联网 - ITeye博客
默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据, 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按 照 region分区情况,在集群内做数据的负载均衡.

HBase Schema 设计

- - IT瘾-dev
HBase 与传统关系数据库(例如MySQL,PostgreSQL,Oracle等)在架构的设计以及为应用程序提供的功能方面有很大的不同. HBase 权衡了其中一些功能,以实现更好的可扩展性以及更灵活的模式. 与关系数据库相比,HBase 表的设计有很大的不同. 下面将通过解释数据模型向您介绍 HBase 表设计的基础知识,并通过一个例子深入探讨 HBase 表的设计.

HBase的一些应用设计tip

- - BlogJava_首页
1,对于HBase的存储设计,要考虑它的存储结构是:rowkey+columnFamily:columnQualifier+timestamp(version)+value = KeyValue in HBase,一个KeyValue依次按照rowkey,columnkey和timestamp有序.

Solr与HBase架构设计 - aitanjupt

- - 博客园_首页
摘要:本篇是本人在做一个大数据项目. ,对于系统架构总结的一点想法,如何在保证存储量的情况下,又能保证数据的检索速度. 前提:      Solr、SolrCloud提供了一整套的数据检索方案,HBase提供了完善的大数据存储机制. 需求:      1、对于添加到HBase中的结构化数据,能够检索出来.

HBase表设计原则整理

- - 互联网 - ITeye博客
因为每个列簇是存在一个独立的HFile里的,flush和compaction操作都是针对一个Region进行的,当一个列簇的数据很多需要flush的时候,其它列簇即使数据很少也需要flush,这样就产生的大量不必要的io操作. 在多列簇的情况下,注意各列簇数据的数量级要一致. 如果两个列簇的数量级相差太大,会使数量级少的列簇的数据扫描效率低下.

HBase 原理、设计与优化实践

- - leejun_2005的个人页面
HBase —— Hadoop Database的简称,Google BigTable的另一种开源实现方式,从问世之初,就为了解决用大量廉价的机器高速存取海量数据、实现数据分布式存储提供可靠的方案. 从功能上来讲,HBase不折不扣是一个数据库,与我们熟悉的Oracle、MySQL、MSSQL等一样,对外提供数据的存储和读取服务.