Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

浅谈《【原创】深度分析Twitter Heron》

有幸拜读了《【原创】深度分析Twitter Heron》 ( http://www.longda.us/?p=529 )一文,十分感动国内社区对Heron的关注。但此文中有诸多重要问题值得商榷,我谨在此行文指出,还望能够帮助大家更好的理解Heron。转载烦请注明出处:https://gist.github.com/maosongfu/c3aeb1bb5eb7b39fcdc5

我是符茂松,目前在Twitter工作,是Heron的作者之一。这个领域水深,我也是初窥门径,希望能够与大家多多交流。

微博:符茂松

Twitter: Louis_Fumaosong

背景介绍

  • Heron虽然沿用了Storm的部分概念并支持其API,但在设计和实现上却是完全不同的
  • 在一年前,Twitter就已经开始了从Storm迁徙到Heron;半年前,Storm在Twitter内部已经完全被舍弃。换言之,Heron已经很好地在Twitter用于线上运行超过半年。

参考资料.(里面的Maosong Fu就是我): paper:

blog post:

以下是对《【原创】深度分析Twitter Heron》一文的浅淡:

原文引用

部分为原文的段落,随后的是我的见解。


性能报告和测试过程: 了解整个系统架构和工作流程后, 后面的性能测试报告, 没有看了, 也差不多有个概念了。

在Paper中Empirical Evaluation这一节,详细地描述了性能测试的场景、条件和结果,以保证试验测试结果的可重现性和可比较性。博文可以对应场景在Storm/JStorm上得出结果再进行分析对比总结。

与此类似,博文后续段落大部分的分析和思考,完全忽视了paper中已经陈述得很清楚的事实,其假设和分析只是其作者自己的臆断,也没有任何数据支撑。这样的分析未免有失偏颇。

不过storm-on-yarn模式下, 可能通过一个nimbus管理一个小的逻辑集群,也可以解决这个问题, 并且当topology 比较小的时候, 可以通过大家公用一个nimbus,节省一些资源。

简单来说,理论上,小集群heron省资源,大集群storm省资源;但实际上storm因为实现上的scalability问题,它不能很好地支撑大集群,而heron可以支撑大集群。

以实际情况展示:

在Heron里面,每个topology一个tmaster,我们在线上运行实践中收集的数据表明,tmaster的占用资源稳定在: < 0.01 cpu + < 10MB RAM。其消耗的资源远小于一个普通topology占用资源的1/1000。 以前storm的是大家公用一个nimbus,因此无法定量衡量每一个topology会消耗nimbus的多少资源。但是考虑到nimbus的稳定性和scalability,所以一般需要特定分出一台机器来作为nimbus host。 考虑到一个Twitter host有24 cpu + 72GB RAM,可以运行数千个TMaster。

所以在设计角度而言, storm更加适合大规模的集群(同时跑数千个topology的集群)。而heron更加偏向于应用的角度,小应用会少一些资源浪费。

但在实际实现中,因为storm的nimbus是整个集群一起公用的,不容易实现高稳定性和scalability,如现在storm,是无法支撑同时跑几千个topology的集群的。而Heron目前已经很好地在线上支持大规模集群。

这个container是Aurora的一个资源单元

Container是heron的一个资源单位,跟aurora本身没关系。Heron可以运行在mesos, yarn和aurora这些资源管理系统之上。Container的具体介绍请参阅paper。

如果将Aurora类似JStorm的worker, 你就会发现角色和架构是多么的类似。

功能相似。整个heron和storm/jstorm的架构完全不同,并且因为架构不同使得Heron能进行很多performance和debugablity, scability, stability的优化。具体架构请看paper。

container和jstorm的worker都可以设置cgroup,达到一定的资源隔离

Container内部是不同task是不同的process,互相之间可以达到资源隔离;Storm/JStorm是worker之间资源隔离,同一个worker(Process)内的多个task没法隔离。

“性能”一节 ppt和文档里面说性能有15倍以上的提升, 这个在某些设置下是可以达到这种效果

请阅读paper,里面有明确明说设置和对应的topology,为了方便读者进行实验对比。Paper中使用了word count 和 rtau 两个topologies作为测试,word count的代码在此:https://github.com/maosongfu/crumbs/blob/master/WordCountTopology.java .Rtau是Twitter内部的topology,不能公开。下文也只讨论word count.

(1)前提条件是, grouping方式不是选择localOrShuffle或者localFirst,就是把container设置的尽可能的大, 最好是独占一台机器。

请阅读paper,word count topology. 也可以参见源代码,是fields Grouping.

(2)就是把container设置的尽可能的大, 最好是独占一台机器。

请阅读paper,每个container约为:1.5cpu。并且其中一个benchmark把topology分散到500个container,意味着分散到500台机器上面。(同时这也更加便于对机器的复用等优势,但在此不赘述。)

jstorm worker内部task之间数据传输的效率会远远高于Heron, 因为Heron的HI 之间即使是走进程间通信方式, 也逃脱不了序列化和反序化的动作, 这个动作肯定会耗时, 更不用说IPC 之间的通信效率和进程内的通信效率。

博文对性能的分析避重就轻,有失偏颇。

博文通篇对性能的对比都局限于“Process内建传递数据快”,却没有对具体场合进行具体分析思考;更加没有试验或者数据进行论证分析。

根据对Twitter内所有运行在Heron上的production topologies的观察,instance最少也有99.2%的绝对时间/99.5%的CPU时间用于执行用户编写的逻辑中。博文的性能关注点局限于“这0.8%的绝对时间/0.5%的CPU时间”的其中一部分的时间的分析,对性能的影响并不显著。

在考虑设计流处理系统时,设计性能应该从重要影响因素出发,例如:

1,能否scale以避免性能退化。因为这可能会造成topology规模变大时,所需的资源从数倍到数十倍甚至更多的消耗。如paper所言,storm在设计和架构上有不少欠缺,使得其scalability存在问题;事实中paper所展现的,heron相对于storm的性能巨幅提升,就是因为在scalability上的进行了优化,但不在此赘述,详细请看paper。

至于JStorm,根据在github的文档,是用JAVA完全重写并在此基础上提供了新功能;虽然它的设计和架构与Storm一致,但不好臆断它是否会有相似的scalability问题,博文可以根据paper中的benchmark experiment中的word count topology的详细设置进行测试,并将结果和heron,storm对比分析。

2,是否容易为topology debug/tune出最佳的稳定参数。博文中似乎没有意识到:同样的流处理框架,比如说storm或者heron,同样的topology逻辑代码,当给出不同的设置的时候,消耗的资源可以相差数倍。Debuggability和性能在流处理系统是高度相关的。

比如说,我们在线上运行所得,针对不同的task,设置不同的memory new gen: old gen size,并使用不同的GC算法,可以减少2~3X的内存消耗,并相应减少GC带来的CPU消耗。

(当然,不仅局限于以上两点;同时以上两点涉及的也不止是性能方面。不在此文赘述。)

此外,建议博文可以从throughput和latency两方面进行分析,而不是随意地以性能一词带过。毕竟,两者需要的设计和影响的因素不尽相同,但不在此文赘述。

资源利用率 如果JStorm-on-yarn这种系统下, 因为每个逻辑集群会超量申请一些资源, 因此资源可能会多有少量浪费。无法做到像Heron一样精准。 如果改造nimbus成为topology level 类似TM(腾讯在jstorm基础上实现了这个功能), 这个问题就可以很好的解决。在普通standalone的JStorm模式下, jstorm不会浪费资源, 但因为Standalone,导致这些机器不能被其他编程框架使用, 因此也可以说浪费一定的资源。 但这种情况就是 资源隔离性– 资源利用率的一种平衡, 现在这种根据线上运行情况,浪费程度可以接受。

有点自相矛盾了。什么叫做“standalone的JStorm模式下, jstorm不会浪费资源, 但因为Standalone,导致这些机器不能被其他编程框架使用, 因此也可以说浪费一定的资源。”到底浪费没浪费?浪费有多少?绝对数值?比例?有没有相关试验的数据进行支撑?这样取舍权衡下最后在线上运行中“可以接受”,什么叫做可以接受? 请阅读Paper,里面有Heron相关的数据和线上运行效果,可对照分析。

最大的问题在于, Heron中一个task就是一个process, 论文中没有描叙这个process的公共线程, 可以肯定的是, 这个process比如还有大量的公共线程, 比如ZK-client/network-thread/container-heartbeat-thread, 一个task一个process,这种设计,相对于一个worker跑更多的task而言,肯定浪费了更多的CPU 和内存。

请阅读paper,一个process只有两个线程。Heron和storm是不同的设计和实现,没有大量公共线程。

至于吐槽在Storm和JStorm,超量申请资源问题, 比如一个topology只要100 个cpu core能完成, 申请了600个core

如果一个topology只要100个cpu core就能保证完成,为什么要申请600个?难道是因为写配置文件的时候不小心写错了?这个例子举得令人费解。

现实中之所以超量申请是为了使topology能够应付最坏情况,如突发的或者预计的数据流量变动。减少人工干预带来的运营开销。之所以在这里提起是为了下一个分析。

请阅读paper中,storm超量申请资源问题产生的原因。

这个问题,在jstorm中是绝对不存在的, jstorm的cgroup设置是share + limit方式, 也就是上限是600 core,但topology如果用不到600个core, 别的topology可以抢占到cpu core。

所以如果Jstorm真的如博文描述这么设置,是有明显的运行隐患的。

流处理需要保证实时性;要保证实时性,就要保证需要的资源能够实时到位。而Share模式是无法保证资源的实时到位的。

Jstorm是share+limit的方式,一个topology A申请的资源一部分被别的topology B抢占了,当topology A需要这部分被抢占的资源,怎么办?需要re-schedule么?re-schedule是自动还是需要人工呢?如果是自动的话,怎么判断自动re-schedule的标准呢?如果是人工的话,会带来额外的运营开销(超量申请往往就是为了避免人工运维)。

我相信这一点JStorm还是应该能比较好解决的,毕竟这是流处理系统的基本问题。希望博文可以说清楚JStorm的具体设置和相关应对措施;方便我理解学习。

而Heron的具体做法请见paper。

Heron更适合超大规模的机器, 超过1000台机器以上的集群。 在稳定性上有更优异的表现, 在性能上,表现一般甚至稍弱一些,在资源使用上,可以和其他编程框架共享资源,但topology级别会更浪费一些资源。 另外应用更偏向于大应用,小应用的话,会多一点点资源浪费, 对于大应用,debug-ability的重要性逐渐提升。 另外对于task的设计, task会走向更重更复杂, 而JStorm的task是向更小更轻量去走。

完全不明白此结论如何推理出来。为什么topology级别会更浪费资源?据我理解,博文的意思应该是,有单独的tmaster+一个process一个task,但是前文已经明确表明,这个论证站不住脚。如果是其他原因,希望博文可以明确写出来方便理解。同时希望博文可以进行相关试验测试。在数据试验结果的支撑下,重新深入分析。

最后总结

该文对paper的翻译部分,大体上还是符合了原意,并进行了合理的概括,非常值得肯定。但是在分析、思考以及总结部分,忽略了paper给出的事实,进行了错误的假设并得出了一些无意义的结论。此外,分析的角度避重就轻,有失偏颇。

如果博主能重新细读paper事实,并进行相关试验测试,且在数据试验结果的支撑下,重新合理地深入分析,我们将十分感谢。欢迎探讨。

@belm

This comment has been minimized.

Copy link

commented Jun 9, 2015

感谢分享!

@darionyaphet

This comment has been minimized.

Copy link

commented Jun 9, 2015

弱问: Heron 准备开源供我们学习么?

@manuzhang

This comment has been minimized.

Copy link

commented Jun 9, 2015

请问性能对比中用的是哪个版本的 storm (感觉比较老,因为消息传输还用的是 zmq)?结果中,50 task storm 的 latency 要达到 1s ?

@longting

This comment has been minimized.

Copy link

commented Jul 20, 2015

请问下,Heron是否会开源?

@hepin1989

This comment has been minimized.

Copy link

commented Sep 16, 2015

那个文章是听奇葩的,请问你们是用的scala不?为何不用akka呢?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.