开发者社区> 饭菜两光> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

修改HBase的rowkey设计把应用的QPS从5W提升到50W

简介: 正确设计Hbase的rowkey可以让你的应用飞起来,前提是你需要了解一些Hbase的存储机制。
+关注继续查看

UTT是Aliexpress的营销消息运营平台,运营希望促销活动时APP消息推送的QPS达到34W。

UTT刚接入APP消息推送时,QPS只能达到5W,离运营的要求有很大的距离。

通过改造,QPS达到了50W,其中最主要的改造是对Hbase的rowkey的改造。

首先介绍一下UTT大致工作流程:

1、运营人员在UTT的小二控制台配置运营任务(job),在任务中设置商品选择参数、目标人群参数和消息发送渠道;

2、UTT调用算法平台计算出要发送的消息,数据生成在阿里云飞天系统的云梯表中;

3、UTT把云梯表中的数据导入到hbase,并生成N个可以并发执行的发送任务(segment),segment的信息存储在mysql表中;

4、UTT按计划发送时间捞取segment,把存储在Hbase中的segment对应的消息读取出来调用阿里巴巴移动消息推送网关发送出去。

步骤1、2、3是提前执行的,我们要优化的是步骤4。

改造中,我们主要做了如下几件事:

1、修改了Hbase的rowkey规则和数据读取方式;

2、优化了记录发送进度的逻辑;

3、优化了消息发送到阿里巴巴移动消息推送网关的流程。

其中最主要的是对Hbase的rowkey的修改。

改造前的rowkey设计:

rowkey=segmentSalt+”_"+dataIndexInSegment+”_”+segmentId+”_”+jobTime+”_”+jobId

说明如下:

job:job对应运营在后台页面配置的任务,一个job可能多次运行,用jobId+jobTime可以唯一标识一个job的一次发送任务。

segment:一个job的一次发送任务拆分为多个segment,每个segment对应10万条消息。多个segment的消息可以并行发送。

segmentSalt:4位的随机字母,每个segment有一个salt,用于把数据均匀分散到Hbase的不同region中;

dataIndexInSegment:每条消息在segment中的序号,从0到99999;

改造前UTT按计划发送时间捞出要发送的segment后,从按0到99999的顺序从Hbase中读取消息,然后发送出去。为了提高效率使用了hbase的批量get方法。

这个设计存在一个很大的问题,同一个segment里的相邻消息的rowkey不是连续的,之间可能隔的非常远。

如下图所示,10000号消息rowkey和10000989374447c7ce6789b3d46615d3dd320
1号消息rowkey之间可能隔了很多rowkey。

这会带来啥问题?这就需要了解Hbase的存储机制。

Hbase的存储是以storeFile为单位,以LSM树(Log-structured merge tree)方式存储。

此结构优化写性能,牺牲读性能。写数据的时候先按rowkey计算出region和store,顺序写入到store的memeStoreFile中,memoStoreFile达到指定大小后flush到磁盘的storeFile中。因此同一个store里,多个storeFile的rowkey的范围是会有重叠的

按rowkey读取数据时,计算该rowkey可能存储的storeFile,把这些storeFile全部读取到内存中,最后把多个storeFile里查询到的结果合并后输出。

为了提高读性能,Hbase会在后台把多个storeFile进行merge,形成rowkey范围互不重叠的storeFile。

另外Hbase采用按列值KV方式存储数据,也就是说每个列的值都是独立存储的。每个列值KV对里的key包括了rowkey和列名,key里的大部分数据是重复的,storeFile采用压缩算法减小空间

改造前同一个segment里的消息的rowkey很分散,读取一个segment的消息时要从磁盘上装载大量的storeFile,消耗大量的cpu进行解压缩,这也会导致storeFile 的cache命中率不高。并且读出来的大部分storeFile是没有包含所需数据的。

分析UTT的场景,多个segment是并发读写的,每个segment有segmentSalt,保证了读写均匀分布到Hbase的不同region。如果读取一个segment的消息时能从尽量少的storeFile读取数据,就能够减少磁盘IO,减少解压缩及数据查找的CPU,还能提高storeFile cache的命中率。

改造后的rowkey设计:

rowkey=segmentSalt+”_”+jobTime+”_”+jobId+”_”+segmentId+”_”+dataIndexInSegment(前补零到定长5位)

这样多个segment并发读写均匀分散到不同region,同一个segment的消息顺序写到相同的storeFile中,读取的时候不再使用get方法而是使用scan方法。最后qps提升了一个数量级。

附一个hbase的知识脑图,不知道作者是谁,挺好的。
a0a55482bb8c93edfedc2eb59c678424

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

相关文章
大白话彻底搞懂 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
Hadoop原理与技术——Hbase实操
Hadoop原理与技术——Hbase实操
0 0
+关注
饭菜两光
APush物联网websocket长连接平台作者。 阿里巴巴java开发。
文章
问答
文章排行榜
最热
最新
相关电子书
更多
玩转HBase和Lindorm 大数据入门和实战
立即下载
HBase应用与发展之HBase RowKey与索引设计
立即下载
HBase Rowkey设计要点
立即下载