从Heron看实时计算系统差异对比

本文介绍了Heron,作为storm的继承者,如何改进了实时计算的性能和架构。Heron采用进程而非线程作为资源最小单位,提供资源约束以确保安全性,同时保持与storm的代码兼容性。它引入背压机制,提升了吞吐量和延迟,并重新设计了多种组件,如Topology Master、Container和Stream Manager。尽管在语义上稍逊于Spark,Heron正努力实现exactly once语义,其丰富的监控界面使其更适用于生产环境。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

      真的有很久没有更新博客了,上一次更新还是2014年。那时候就在写云计算君临天下。感叹变化太快,自己14-15年从storm到全栈工程师,到产品经理,现在又重回大数据,不胜唏嘘。

      这两年里,许多新的开源系统发布,平均1、2年技术栈都要变一下。当然,其中最火爆的莫过于spark了。spark集批量计算,实时计算,SQL计算,图计算,机器学习与一身。以scala语言的易编程特点几乎一统大数据"计算“领域的江湖。

      不过streaming始终还是以min batch来作为最小单位进行计算,实时性上更适合分钟级的分析统计类应用。对于ms或者秒级实时的场景依然不太合适。当然目前实时计算领域还有一个flink设计上很牛逼,天然支持了状态计算,只可惜社区不够活跃,难以被大多数公司所采用。

      以上只是一个大致的概览,回到本文的主角——Heron,storm的继承者。沿用了storm的数据模型——经典spout-bolt模型。而又从架构上弥补了storm存在的缺点。

      1、资源最小单位——topology采用了进程的方式开并发,而不是以往的线程方式。利于资源隔离,debug,profilling以及troubleshooting等更加友好。但其实也有所失就是开进程开销总是要比线程要大。

      2、资源约束——topologies会严格使用自己所allocate的资源,而不会占用其他组件资源造成竞争,运行起来更加安全。当然安全的缺点就是可能会造成资源的浪费。这和虚拟机超卖是一个道理,有利有弊

      3、兼容性——完全兼容storm的代码,甚至做到不改一行代码直接编译后就能在Heron上运行

      4、背压机制——分布式系统中组件的执行速度各不相同,背压机制可以让各个组件自适应,而不至于造成堆积(具体实现还待了解)

      5、性能——吞吐量和延迟上大幅提升。看论文是采用了一些避免瓶颈的做法,例如轻依赖zk,c++写部分代码

      6、语义——最多一次,最少一次的语义。这一点相对spark来讲是劣势,和storm持平。exactly once目前看来是难点,Heron也正在实现中

      7、各种组件重新设计——Topology Master、Container、Stream Manager、Heron Instance、Metrics Manager、Heron Tracker

(1)Topology Master

      管理Topology的全生命周期,每个topology会开启一个TM,多个Container,TM会在zk中注册,TM会构建物理执行计划分配给其他组件

(2)Container

      容器,一个topology会启动多个容器。容器包含有Heron Instances,Steam Manager,Metrics Manager。容器就可以做资源格力

(3)Stream Manager

      Container中用来和其他Container网络交互的出口点


当然还有其他的一些组件:

Heron CLI、Heron Tracker、Heron UI。

这里不得不提的是Heron UI,可以显示当前的执行拓扑、执行速度、资源消耗,还可以知己看日志,总体来说是靠向生产系统的监控体系。


先mark,以后再补充!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值