内容简介:Heron原作者浅谈《【原创】深度分析Twitter Heron》
有幸拜读了《【原创】深度分析Twitter Heron》 ( http://www.longda.us/?p=529 )一文,十分感动国内社区对Heron的关注。但此文中有诸多重要问题值得商榷,我谨在此行文指出,还望能够帮助大家更好的理解Heron。
我是符茂松,目前在Twitter工作,是Heron的作者之一。这个领域水深,我也是初窥门径,希望能够与大家多多交流。
微博:符茂松
Twitter: Louis_Fumaosong
背景介绍:
-
Heron虽然沿用了Storm的部分概念并支持其API,但在设计和实现上却是完全不同的
-
在一年前,Twitter就已经开始了从Storm迁徙到Heron;半年前,Storm在Twitter内部已经完全被舍弃。换言之,Heron已经很好地在Twitter用于线上运行超过半年。
参考资料.(里面的Maosong Fu就是我): paper:
-
http://dl.acm.org/citation.cfm?id=2742788
blog post:
-
https://blog.twitter.com/2015/flying-faster-with-twitter-heron
-
http://geek.csdn.net/news/detail/33750
以下是对《【原创】深度分析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事实,并进行相关试验测试,且在数据试验结果的支撑下,重新合理地深入分析,我们将十分感谢。欢迎探讨。
【原文】:https://gist.github.com/maosongfu/c3aeb1bb5eb7b39fcdc5
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Heron原作者浅谈《【原创】深度分析Twitter Heron》
- S2-057漏洞原作者自述:如何利用自动化工具发现5个RCE
- 唯一《可解释机器学习》中文书来了:复旦研究生翻译,原作者转发点赞
- YOLOv3比原作高10个点,飞桨更新至73个视觉算法、203个预训练模型
- 深度分析ConcurrentHashMap原理分析
- 【深度好文】深度分析如何获取方法参数名
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。