有幸拜读了《【原创】深度分析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:
- 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事实，并进行相关试验测试，且在数据试验结果的支撑下，重新合理地深入分析，我们将十分感谢。欢迎探讨。
感谢分享！