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中已经陈述得很清楚的事实，其假设和分析只是其作者自己的臆断，也没有任何数据支撑。这样的分析未免有失偏颇。

简单来说，理论上，小集群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是heron的一个资源单位，跟aurora本身没关系。Heron可以运行在mesos, yarn和aurora这些资源管理系统之上。Container的具体介绍请参阅paper。

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

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

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.

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

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

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

博文通篇对性能的对比都局限于“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两方面进行分析，而不是随意地以性能一词带过。毕竟，两者需要的设计和影响的因素不尽相同，但不在此文赘述。

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

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

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

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

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

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

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

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

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

而Heron的具体做法请见paper。

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

最后总结

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

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

【原文】：https://gist.github.com/maosongfu/c3aeb1bb5eb7b39fcdc5