开发者社区> 王知无> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

设计HBase RowKey需要注意的二三事

简介:
+关注继续查看

在HBase中,定位一条数据(即一个Cell)需要4个维度的限定:行键(RowKey)、列族(Column Family)、列限定符(Column Qualifier)、时间戳(Timestamp)。其中,RowKey是最容易出现问题的。除了根据业务和查询需求来设计之外,还需要注意以下三点。

  1. 打散RowKey
    HBase中的行是按照RowKey字典序排序的。

这对Scan操作非常友好,因为RowKey相近的行总是存储在相近的位置,顺序读的效率比随机读要高。
但是,如果大量的读写操作总是集中在某个RowKey范围,那么就会造成Region热点,拖累RegionServer的性能。
因此,要适当地将RowKey打散。
加盐(salting)+哈希(hashing)
这里的“加盐”与密码学中的“加盐”不是一回事。
它是指在RowKey的前面增加一些前缀。
加盐的前缀种类越多,RowKey就被打得越散。
前缀不可以是随机的,因为必须要让客户端能够完整地重构RowKey。
我们一般会拿原RowKey或其一部分计算hash值,然后再对hash值做运算作为前缀。
反转固定格式的数值
以手机号为例,手机号的前缀变化比较少(如152、185等),但后半部分变化很多。
如果将它反转过来,可以有效地避免热点。
不过其缺点就是失去了有序性。
反转时间
这个操作严格来讲不算“打散”,但可以调整数据的时间排序。
如果将时间按照字典序排列,最近产生的数据会排在旧数据后面。
如果用一个大值减去时间(比如用99999999减去yyyyMMdd,或者Long.MAX_VALUE减去时间戳),最新的数据就可以排在前面了。

  1. 控制RowKey长度
    在HBase中,RowKey、列族、列名等都是以byte[]形式传输的。

RowKey的最大长度限制为64KB,但在实际应用中最多不会超过100B。
设计短RowKey有以下两方面考虑:
在HBase的底层存储HFile中,RowKey是KeyValue结构中的一个域。假设RowKey长度100B,那么1000万条数据中,只算RowKey就占用掉将近1G空间,会影响HFile的存储效率。

image

HBase中设计有MemStore和BlockCache,分别对应列族/Store级别的写入缓存,和RegionServer级别的读取缓存。如果RowKey过长,缓存中存储数据的密度就会降低,影响数据落地或查询效率。

image

另外,我们目前使用的服务器操作系统都是64位系统,内存是按照8B对齐的,因此设计RowKey时一般做成8B的整数倍,如16B或者24B,可以提高寻址效率。
同样地,列族、列名的命名在保证可读的情况下也应尽量短。HBase官方不推荐使用3个以上列族,因此实际上列族命名几乎都用一个字母,比如‘c’或‘f’。

  1. 保证RowKey唯一性
    这个就是显而易见的了,不再赘述。

举个例子
我们的业务中,有一部分是用户在日历上记录自己的行为。需要储存在RowKey中的维度有:用户ID(uid,不会超过十亿)、日历上的日期(date,yyyyMMdd格式)、记录行为的类型(type,0~99之间)。记录的详细数据则存储在列f:data中。根据查询逻辑,我们设计的RowKey格式如下:
9~79809782~05~0008839540
长度正好是24B。以字符‘~’为分界(‘~’的ASCII码是最大的,方便),各个部分的含义如下:

uid.toString().hashCode() % 10

99999999 - date

StringUtils.leftPad(type, 2, "0")

StringUtils.leftPad(uid, 10, "0")

基于这种设计,我们在建表阶段就可以将其预分区,使得数据在一开始就均匀分布在不同的Region上。建表语句参考:

create 'user_calendar_record', {
NAME => 'f',
VERSIONS => '1',
BLOCKCACHE => 'true',
BLOCKSIZE => '65536',
BLOOMFILTER => 'row',
COMPRESSION => 'SNAPPY'
}, {
SPLITS => ['1', '2', '3', '4', '5', '6', '7', '8', '9']
}

如果不做预分区,那么表刚开始只会有一个Region。随着数据量增大,就会频繁触发Region split,影响效率。关于Region split应该另外写文章讨论,这里就不提了。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
大白话彻底搞懂 HBase Rowkey 设计和实现方式
大白话彻底搞懂 HBase Rowkey 设计和实现方式
0 0
Hbase的Rowkey设计以及如何进行预分区
今天有人问我Hbase的rowkey设计和预分区的问题,这篇文字就简单介绍一下.,关于Hbase的表的一些基本概念这里就不说了,直接说重点,尽可能说的简单一点,废话就不写了. 1.什么是Rowkey? 我们知道Hbase是一个分布式的、面向列的数据库,它和一般关系型数据库的最大区别是:HBase很适合于存储非结构化的数据,还有就是它基于列的而不是基于行的模式.
0 0
Hbase入门(四)——表结构设计-RowKey
Hbase的表结构设计与关系型数据库有很多不同,主要是Hbase有Rowkey和列族、timestamp这几个全新的概念,如何设计表结构就非常的重要。
0 0
Hbase rowkey设计原则,热点问题
Hbase rowkey设计原则,热点问题
0 0
案例篇-HBase RowKey 设计指南
吴阳平 阿里巴巴 HBase 业务架构师
14522 0
HBase实战 | HBase Rowkey 设计指南
本文来自于2018年12月25日在 HBase生态+Spark社区钉钉大群直播,本群每周二下午18点-19点之间进行 HBase+Spark技术分享。加群地址:https://dwz.cn/Fvqv066s。
10113 0
修改HBase的rowkey设计把应用的QPS从5W提升到50W
正确设计Hbase的rowkey可以让你的应用飞起来,前提是你需要了解一些Hbase的存储机制。
5863 0
Hadoop原理与技术——Hbase实操
Hadoop原理与技术——Hbase实操
0 0
+关注
王知无
Github: https://github.com/wangzhiwubigdata/God-Of-BigData
文章
问答
文章排行榜
最热
最新
相关电子书
更多
玩转HBase和Lindorm 大数据入门和实战
立即下载
HBase应用与发展之HBase RowKey与索引设计
立即下载
HBase Rowkey设计要点
立即下载