揭开 Heron 性能面纱
Heron 自去年2015年6月公布出来,给整个业界注入了一缕新的活力, 随即我们团队, 仔细阅读了Heron 的论文, 发表 了一篇关于《深入浅出Heron》 (国内被墙的话,可以查看 http://www.blogchong.com/post/117.html)。 其中Topology Master、backpressure到Two-threaded approach instance,Stream Manager等概念还是非常有创新。
整体Heron 的架构设计就是Storm-on-Mesos 的架构。
这篇博文分为2部分
- 测试结果和测试过程
- Heron 性能分析
测试结果和测试过程
今年5月25号, Heron开源了他们的源码, 整个业界对Heron 的性能都非常感兴趣,我们花了3周的时间,完成heron的整个测试。
性能测试结果
使用FastWordCount
FastWordCount 测试用例 分为3个stage spout-> split > count, 使用流计算中最常用的shuffler和fieldgrouping 方式。
使用WordCount
WordCount 是twitter 号称是storm 10倍性能的官方测试用例, 分为2个stage, spout -> count, 使用shuffle模式,并按照twitter给出的并发配置进行测试。
测试环境
- 10 台a8, 32 核/128g
- os: redhat rhel 7.2
- jdk: jdk8
- hdfs: 2.6.3
- mesos: 0.25.0
- aurora: 0.12.0
- jstorm: 2.2.0
- heron: 0.14.0 并打上heron最新性能优化patch
- flink: 1.0.3
- storm: 1.0.2
- worker/container 内存设置4g
测试过程
- 第一次跑,heron性能极差, 10个container只有2w qps, 咨询twitter, 告知,大量触发反压,可以打个patch 调整反压策略
- 第二次跑(打上patch后),10个container可以到10多万, 但其实和storm相比,也是差很多, 咨询twitter 人员, 告知一个container内部task太多,容易发生反压
- 第三次跑(修改container内部task数), 10个container 跑到20w qps, 但我们依旧不满意,咨询twitter, 他们告知 他们也就只能跑20w qps, 并且告诉 一个很大问题, container内部的stream-manager的瓶颈是50w qps, 也就是一个container所有内部通信和外部通信的总和上限就是50w。
分析
后面的分析,主要是分析Heron 最大的噱头 “10 倍storm性能” & “减少3倍storm资源”, Heron 有很多漂亮的设计, 这里不赘述, 读者可以自行阅读我们之前的文章。
性能分析
- heron 一直号称是storm 10倍性能, 但heron 对比的对象是storm 0.8.2, 这是3年前的storm,是上一代的storm, 而最新版storm 1.0.2 早已经是storm 0.8.2 的十倍性能。
- heron在性能上存在2个致命缺陷
- 失去了整个业界性能优化很大的一个方向, 流计算图优化。其核心思想就是让task尽量绑在一个进程中, 这样task之间的数据,可以直接走进程内通信,无需反序列化和序列化。
- 为了提高稳定性, heron将每个task 独立成为一个进程, 则会产生一个新的问题,就是task之间的通信都不会有进程内通信, 所有task通信都是走网络, 都要经过序列化和反序列化, 引入了大量额外的计算.
- 如果想要图优化, 则heron必须引入一层新的概念, 将多个task 链接到一个进程中, 但这个设计和heron的架构设计理念会冲突
- 每个container 的stream manager 会成为瓶颈, 一个container 内部的所有task 的数据(无论数据对外还是对内)通信都必须经过stream manager, 一个进程他的网络tps是有上限的, 而stream-manager的上限就是50w qps, 则表示一个container的内部通道和外部通道总和就是50w qps. 大家都必须抢这个资源。
- 原来的一次网络通信, 现在会变成3次网络通信, task -》 当前container的streammanager -》 目标container的stream manager -》 目标task
资源分析
Heron 突出的 “省资源3倍”, 这个论点和3年前的storm相比,确实是可以这么说,这个说法的背后技术:
- 反压;过去storm 应用,为了应对每天的高峰, 必须要多申请资源, 否则当流量高峰来临时, worker会爆掉。
- 大集群部署,利用大集群的削峰填谷能力和资源隔离能力。
- 对每个task的资源做限定, 限定cpu 用多少, 内存用多少,按需使用,无需超量申请。
但今天的storm已经今非昔比,而jstorm更是不一样了。 jstorm反压早就做到了第三版, 当下游数据发生堆积时, 上游spout早就做限流降级, 应用无需申请超量的资源。
今天jstorm-on-yarn/jstorm-on-docker, jstorm-on-yarn 已经上线,就是在大集群上部署多个逻辑集群, 让大集群削峰填谷和资源隔离都非常成熟。
jstorm 0.9.0/storm0.9.5 开始就有了task粒度资源调度器,就是task按自己需要,申请多少cpu和多少内存就分配多少内存。但jstorm从0.9.5 开始,调度的资源从task粒度恢复到worker粒度, 原因是:
- 集群跑一段时间后,容易出现碎片, 即有的机器上有cpu slot但没有内存 slot, 有的机器上有内存slot但没有cpu slot
- 业务方很少遵守task 粒度去申请资源,反而偏爱worker粒度,简单粗暴方式。
- 业务方有时超量申请资源, 只需要10个cpu slot,但却申请20个cpu
最终jstorm的方案是, 资源的粒度是到worker级别,但每台机器上配置动态监测, 实时根据负载情况调整自己的资源池策略, 很有效解决上述问题。
另外Heron 资源上其实会引入1个小问题, 单个heron container会比单个jstorm/storm worker更消耗资源。
假设3个task运行在一个worker或container中,每个task 需要2g内存, 如果是jstorm或storm, 可能5g 内存就够了, 每个task之间可以临时share一下, 而heron container 则需要7g 甚至8g, 每个task 都需要2g,而且不能相互share, 另外一个container中还有streammanager/metricsmanager, 他们都需要内存。
原本worker级别的公共线程,在heron中现在需要在每个task进程中都配置上, 比如netty进程池,心跳线程, metrics 线程等等, 这些都在消耗cpu。
企业级互联网架构Aliware,让您的业务能力云化:https://www.aliyun.com/aliware
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
数据库拆分的几种方式
数据库做拆分的几种方式:1.按功能划分(垂直切分) 将不同功能相关的表放到不同的数据库中,这样做的好处是非常直观。但当某一部分的功能其数据量或性能要求超出了可控的范围,就需要继续对其进行深入的再切分。 2.按表中某一字段值的范围划分(水平切分) 当伴随着某一个表的数据量越来越大,以至于不能承受的时候,就需要对它进行进一步的切分。一种选择是根据key 的范围来做切分,譬如ID 为 1-10000的放到A上,ID 为10000~20000的放到B。这样的扩展就是可预见的。另一种是根据某一字段值来划分,譬如根据用户名的首字母,如果是A-D,就属于A,E-H就属于B。这样做也存在不均衡性,当某个范围超出了单点所能承受的范围就需要继续切分。还有按日期切分等等。 优点:单表大小可控,天然水平扩展 缺点:无法解决集中写入瓶颈的问题 3.基于hash的切分 一般采用mod来切分,一开始确定切分数据库的个数,通过hash取模来决定使用哪台。这种方法能够平均地来分配数据,但是伴随着数据量的增大,需要进行扩展的时候,这种方式无法做到在线扩容。每增加节点的时候,就需要对hash 算法重新运算。 所以采用这种方...
- 下一篇
软件架构师应该知道的97件事
转载朋友翻译的文章:软件架构师应该知道的97件事 1. 客户需求重于个人简历 ( Nitin Borwankar ) 客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。 2.简化根本复杂性 ,消除偶发复杂性( Neal Ford ) 分析问题好比拨云见月、水落石出。 3. 关键问题可能不是出在技术上 ( Mark Ramm ) 团队同心,其利断金。 4. 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 ( Mark Richards ) 沟通应当言简意赅、详略得当,别拖泥 带水。 5.架构决定性能( Randy Stafford ) 种瓜得瓜,种豆得豆,架构设计也是一 样道理。 6.分析客户需求背后的意义( Einar Landre ) 抽丝剥茧,洞见症结。不要被表面需求 迷惑。 7. 起立发言 ( Udi Dahan ) 起立发言效果更好。 8.故障终究会发生( Michael Nygard ) 应该提前设计预防措施,限制故障。 9.我们常常忽略了自己在谈判( Michael Nygard ) 工程师应该适时转换角色,学习谈...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 2048小游戏-低调大师作品
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长