广州中企动力网站制作,wordpress 开通json,网站域名验证,公司变更经营范围摘要#xff1a; 正确设计Hbase的rowkey可以让你的应用飞起来#xff0c;前提是你需要了解一些Hbase的存储机制。 UTT是Aliexpress的营销消息运营平台#xff0c;运营希望促销活动时APP消息推送的QPS达到34W。 UTT刚接入APP消息推送时#xff0c;QPS只能达到5W#xff0…摘要 正确设计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个可以并发执行的发送任务segmentsegment的信息存储在mysql表中 4、UTT按计划发送时间捞取segment把存储在Hbase中的segment对应的消息读取出来调用阿里巴巴移动消息推送网关发送出去。 步骤1、2、3是提前执行的我们要优化的是步骤4。 改造中我们主要做了如下几件事 1、修改了Hbase的rowkey规则和数据读取方式 2、优化了记录发送进度的逻辑 3、优化了消息发送到阿里巴巴移动消息推送网关的流程。 其中最主要的是对Hbase的rowkey的修改。 改造前的rowkey设计 rowkeysegmentSalt”_dataIndexInSegment”_”segmentId”_”jobTime”_”jobId 说明如下 jobjob对应运营在后台页面配置的任务一个job可能多次运行用jobIdjobTime可以唯一标识一个job的一次发送任务。 segment一个job的一次发送任务拆分为多个segment每个segment对应10万条消息。多个segment的消息可以并行发送。 segmentSalt4位的随机字母每个segment有一个salt用于把数据均匀分散到Hbase的不同region中 dataIndexInSegment每条消息在segment中的序号从0到99999 改造前UTT按计划发送时间捞出要发送的segment后从按0到99999的顺序从Hbase中读取消息然后发送出去。为了提高效率使用了hbase的批量get方法。 这个设计存在一个很大的问题同一个segment里的相邻消息的rowkey不是连续的之间可能隔的非常远。 如下图所示10000号消息rowkey和10000 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设计 rowkeysegmentSalt”_”jobTime”_”jobId”_”segmentId”_”dataIndexInSegment前补零到定长5位 这样多个segment并发读写均匀分散到不同region同一个segment的消息顺序写到相同的storeFile中读取的时候不再使用get方法而是使用scan方法。最后qps提升了一个数量级。 附一个hbase的知识脑图不知道作者是谁挺好的。 原文链接  本文为云栖社区原创内容未经允许不得转载。