基于HBase做Storm 实时计算指标存储

  • 时间:
  • 浏览:0
  • 来源:爱乐彩网站_爱乐彩下载_爱乐彩官网

每个JVM实例会构建另一有有1个 拥有10个守护线程的守护线程。

顶端就让今天分享的内容了。

HBase 表行态设计,充分李永乐 HBase 自身的特点,有效的减少Key的数量,提高查询带宽。

写入大伙儿也做了些优化,不可能 写的守护线程和 Storm 是混用的(实在就让 Storm 在写)。大伙儿不到堵住了 Storm。

其次,内存是有限的,不到存当天的。就让 的数据需用转存。

第5个圆圈和第5个圆圈是为了做维度一键复制,比如我计算了五分钟的值,哪些地方地方值实在还需用自动叠加到对应的小时和天上。大伙儿称为分裂守护线程

大伙儿首先就想到了 HBase,不可能 HBase 还是具有蛮强悍的写入性功能以及优秀的可扩展性。而事实上经过调研,大伙儿发现 HBase 还是非常适合指标查询的,还需用有效的通过列来减少 key 的数量。

本文作者:祝海林

而 HBase 的 Client 也是非常的奇特,比如 HTablePool 竟然是对象池而完整都是链接池,多个 HTable 对象是共享另一有有1个 Connection 链接的。当然,这里 HTable 的 Connection 会比较比较复杂,不可能 要连 Zookeeper 还有各个 Region。

但实际并发应该是不到 40 左右的。50 个守护线程并没有 起到太久作用。

一次责。次责分享内容实在还发生实施阶段。架构方案设计得话应该是仁者见仁智者见智,也会有什么都有考虑不周的地方,欢迎大伙儿批评指正。说不定大伙儿听完分享后好的提议大伙儿会用到工程上,也为顶端的实际课程做好准备。

将N条分成10份,每份N/10条。

Storm 写入方案,用以保证出現数据延时不可能 Storm 拓扑当掉后太久意味着着 数据不可用。

当用户提交了N条记录进行更新操作,我会做如下操作:

基于 HBase 做 Storm 实时计算指标存储

做这名优化的意味着着 是我顶端提到的,HTable 的连接池是共享 Connnection 的。大伙儿这里是为了让每个守护线程完整都是另一有有1个 Connection。具体分成几只份(我这里采用的是 10),是需用根据 CPU 来考量的。大伙儿的服务器 CPU 并完整都是什么都有。值完整都是越大越好。不可能 太久,比如我起了 40 个虚拟机。每个虚拟机 10 个守护线程,没有 会有 50 个到 Zookeeper 和 HBase 的连接。值设置的过大,会对 Zookeeper 有一定的压力。

大伙儿还需用想象一下,不可能 我计算另一有有1个 五分钟的指标,到第三分钟挂掉了,此时累计值是 50,接着拓扑重启了,五分钟还没完,剩下的两分钟它会接着累计,此时是 50。不可能 是覆盖写,就会得到不正确的结果,实际上整个完整的计数是 50。

Storm 计算这名块,还有另一有有1个 比较有意思的地方。假设 A 指标是五分钟粒度的,也就让说大伙儿会存储 A 指标每个五分钟的值。就让在实际做存储的就让 ,他并完整都是五分钟结束了了英文英语 后就往 HBase 里存储,就让每隔(几秒/不可能 一定条数后)就 increment 到 HBase 中,就让清除重新计数。

顶端的整体架构中,分裂守护线程是为了缓解实时写入 HBase 的压力,共同大伙儿还利用 MR/Spark 做为恢复机制,不可能 实时计算产生问题,大伙儿还需用在小时内完成恢复操作,比如日志的收集守护线程、分拣守护线程、以及格式化守护线程。格式化守护线程避免完就让 是 kafka,Storm 对接的是 Kafka 和 HBase。

丢数据比如你 kill-9 了。

避免拓扑当掉并完整都是另一有有1个 设计的主要意味着着 ,还有或多或少是计算延时了,比如某个数据片段不可能 某个意味着着 ,延时了十分钟才到 Storm 实时计算集群,这名就让 新得到的值还还需用加回去,不可能 是覆盖,数据就错误了。

我取过半年 的,整个 HTTP 响应时间还需用控制 50ms 左右(本机测试)。

来源:51CTO

又没有 批量接口,另一有有1个 Client 不到有另一有有1个 Connection 链接,什么都有意味着着 客户端的写入量死活上不去。16 台 32G,24 核的服务器,我做了预分区 (50个左右),用了四5个守护线程,50 个左右的守护线程去写,也就不到写到 50000/s 而已。

大伙儿总结下顶端的内容:

什么都有我就让 收集了几天的 key,就让预先根据 key 的分布做了分区。我测试过,在大伙儿的集群上,到了 50 个分区就让另一有有1个 瓶颈,打上去分区不可能 不到提升写入量。

HBase 写入性能优化

大伙儿对查询做另一有有1个 推演。不可能 我要给用户绘制流量的另一有有1个 月曲线图。曲线的最小粒度是小时,小时的值是取 12 个五分钟里最高的值,大伙儿看看需用取几只条记录完成这名查询。

守护线程会对个人的这N/10条数据顺序进行incrementColumnValue。

守护线程中的每个守护线程完整都是维护另一有有1个 Connection(通过ThreadLocal完成)。

大伙儿再看看整个存储体系完整的拓扑图。

这名方案我测试的结果是:

HBase 实时指标存储是我入职乐视云后对原有的实时系统改造的

鉴于以上意味着着 ,大伙儿就想着有没有 更大概的方案。

查询的就让 ,可根据天的区间查出根小相应的记录。大伙儿是直接把记录都取出来,Column 就让另一有有1个 Int/Long 类型,什么都有 1440 个 Column 数据就让算大。

第5个圆圈是为了在实时计算出错时,通过 Spark/MR 进行数据恢复。

峰值略微提升了或多或少。就让 大概 6.1w/s,现在还需用达到 6.6w/s。

大伙儿需用取 31 条五分钟的记录,每条记录有 288 个点,对这 288 个点分成 24 份(具体就让把分钟打上去 groupBy 一下),求出每份里的最大值(每组 SortBy 一下),另一有有1个 就得到了 24 个值。

但在大伙儿的测试中,还是比较平稳的,整个写入情况报告。抖动不大。

与传统方案 (Redis/MySQL) 对比

不可能 我用同一集群上的 Spark 模拟的提交,什么都有不可能 会对 HBase 的写入有或多或少影响,不可能 我应该 继续提升写入性能,不到重写 HBase 这块客户端的代码。

还有就让,HBase 的 incrementColumnValue 的性能实在不高。大概和批量 Put 差距很大。

这里要强调或多或少,HBase 看场景,在大伙儿这名场景下是预分区是非常重要的。就让一结束了了英文英语 都集中在一台机器的另一有有1个 Regin 上写,估计放慢写的守护线程就都堵住了。上线就会挂。

不可能 采用 Redis/Memcached 写入带宽是没有 问题的,毕竟完整的内存操作。就让 key 集合太久,实在压力也蛮大的,我去的就让 不可能 加了指标,结果意味着着 Memcache 被写爆了,什么都有紧急做了扩容。

什么都有 HBase 存储这块就变成做加法操作而不仅仅是简单的更新了。目前 HBase 打上去了计数的功能 (Incrment),就让我发现跨行,没有 批量更新的的接口。

乐视云内内外部用 Storm 做 CDN,点播,直播流量的计算,共同还有慢速比,卡顿比等统计指标。相应的指标会由指标名称,业务类型,客户,地域,ISP 等多个维度组成。指标计算另一有有1个 比较大的问题是 Key 的集合很大。

假设该视频是 A,不可能 在线上 50 天了。大伙儿会记录这名视频所有的 1 分钟播放数,用 Redis 不可能 有 50*1440 个 key,就让 HBase就让获取 50 条记录就还需用找出来,大伙儿把时间粒度转化为了 hbase 的列,从而减少行 (Key)。

Storm 结果怎样存储到 HBase

首先是 Redis 查起来的太麻烦。客户端为了某个查询,需用汇总成千上万个 Key。。。业务方表示很蛋疼,大伙儿也表示很蛋疼

第三,你还是绕不过持久化存储,于是引入 MySQL,现在是每天一张表。那 Redis 导入到 MySQL 这名生活就麻烦。什么都有工作量多了,查询也麻烦,查另一有有1个 月半年 的数据就吐血了。

这里实在我要强调的是,到 HBase 并完整都是覆盖某个 Rowkey 特定的 Cloumn 值,就让在它原有的基础上,做加法。另一有有1个 做还需用避免时间周期比较长的指标,其累计值太久不可能 有拓扑当掉了而丢失数据(实在还是会丢的,但不可能 损失的计数比较少而已)。

第另一有有1个 圆圈就让对外吐出数据了,由大伙儿的统一查询引擎对外提供支持查询支持了。

写入的就让 ,大伙儿还需用定位到 rowkey,以及对应的 column,这里一般太久发生并发写。当然 HBase 的 increment 不可能 避免了并发问题,就让会造成一定的性能影响。

这里,大伙儿一行还需用追踪某个指标一天的情况报告。不可能 加打上去个维度,无非增加根小记录。而不可能 是 redis,不可能 就多了一倍,也就让 2850 个 key 了。

HBase 存储设计

举个例子,假设大伙儿有客户 10w,计算指标假设 50 个,5 个 ISP,50 个地域,另一有有1个 完整都是亿级以上的 Key 了,大伙儿需用统计分钟级别,小时级别,天级别,月级别。什么都有写入量和存储量完整都是小。

大伙儿现在上图:

Redis/Mysql 存储方案发生的或多或少缺点。

吞吐量上去了。在 50w 左右的测试数据中,原有的法律依据 大概平均不到 3w/s 左右的写入量。 通过新的法律依据 ,大概还需用提高到 5.4w/s,就让 4 分钟左右就能完成 50w 条数据的写入。

举个例子,我现在想绘制某另一有有1个 视频昨天每一分钟的播放量的曲线图。不可能 是 Redis,你很不可能 需用查询 1440 个 Key。不可能 是 HBase,就让根小记录就拿出。

大伙儿知道 HBase 是还需用多列族,多 Column,Schemaless 的。什么都有这里,大伙儿建了另一有有1个 列族,在该列族上,直接建了 1440 个 Column。Column 的数目和时间粒度有关。不可能 是一分钟粒度,会有 1440 个,不可能 是五分钟粒度的会有 288 个,不可能 是小时粒度的,会有 24 个。不同的粒度,大伙儿会建不同的表。