专访符茂松：Twitter新开源的Heron是否可以完全取代Storm？

未分类

继Storm之后，Twitter于今年5月份又开源了他们新开发的实时流式计算框架Heron。Twitter在2014年就用Heron完全替代Storm，Heron有很多架构方面的改进，而且向后兼容Storm生态系统。InfoQ在第一时间联系了Heron的技术主管符茂松，了解一些技术内幕，看看Twitter的“鸟类文化”如何孵化了两代流计算平台。

InfoQ：能简单介绍下自己的工作经历和目前的主要工作吗？
符茂松：我是Twitter实时计算平台技术主管，负责Heron, Presto等服务。Heron的原作者之一。专注于分布式系统，在SIGMOD等会议期刊发表多篇论文。本科毕业于华中科技大学；研究生毕业于Carnegie Mellon University。

InfoQ：现在开源Heron的原因有哪些？
符茂松：一是避免重复造轮子的代价。Twitter的实时计算分析技术积累深厚；目前业界最流行的实时计算框架Storm就是我们开源的。我们针对Twitter在使用Storm遇到的痛点重新设计了新一代实时计算框架Heron。很多重度依赖Storm的公司也有类似痛点并且希望可以使用Heron。
二是吸引更多优秀的人共同建设Heron。可以帮我们更好地理解需求并进行设计：事实上，近期在Github上也出现了很多我们忽略的需求。可以吸引到开源贡献者来做一些他们感兴趣，项目想要，但是我们本身没时间做的功能：目前除Twitter外，主要贡献者还有Microsoft、Cisco、Adobe、Elodina、Stanford University、Indiana University…

InfoQ：如何判断软件开源时机成熟？
符茂松：1，项目本身应该是成熟的，稳定的，经过大规模生产检验的。Heron在2014年底已经完成取代Storm成为Twitter新一代的实时计算框架；在日常生产中，输入流量的大小达到了~10M events/s的单个job运行起来毫无问题。
2，项目本身应该有足够的文档。一方面，让第一次接触的人可以尝试运行(get started and play with it)；另一方面，需要提供项目的设计文档（已经各个自系统的文档），方便人们去理解去参与贡献项目。
3，项目本身应该在一个状态。比如说，有足够的tests，足够的注释，良好一致的编码规范，清晰一致的文件分布组织结构等等。
4，有良好的社区运作机制。比如说，有对应的github issues，google group方便交流；有相应的清晰的项目运作流程和规则等等。

InfoQ：Heron开发采用的什么语言，原因是什么？
符茂松：Heron主要使用Java和C++。
大部分的代码使用Java来实现的，因为：
1，Java代码的可移植性和平台独立性。编译后可单独运行。
2，对于开发一个大型复杂系统，Java是一个相当简单易学的编程语言。Java项目也很容易管理。
3，与其他语言相比，Java有巨大的开源库可用。
4，比起C或C++，Java里灾难性崩溃更少。而且更易调试。
5，Java中的垃圾回收技术更容易复用或满足项目需求。
而Heron中的一些对性能和资源要求高的组件是用C++完成的。

InfoQ：对于Twitter的两代实时处理框架，Heron最大的转变是什么？现在在流处理上是所有场景都可以用Heron替换Storm？
符茂松：在Twitter内部，我们的实时处理一直重度依赖Storm。但是，随着数据规模增大，实时性能要求升高，以及案例的多样性以及数目的增多，Storm的不足也就越来越明显。我们需要一个在共享集群设施中运行更稳定，更易调试，具有更好的性能并且易于管理的系统。考虑很多选择之后，我们得出的结论是需要构建一个全新的实时流处理系统。所以简单的说，heron和Storm最大的区别是性能可估（Performance predictability），高效开发以及易于管理。
Heron对于native Storm API是完全兼容的，但是对于一些建立在native Storm API之上的功能，基于用户需求和使用情况进行了裁剪。如果大家对这些功能有需求，我们也欢迎大家移植contribute进来。

InfoQ：您对想研读Heron代码的人有什么样的指导或建议？
符茂松：我的建议是访问我们的官方网站“heronstreaming.io”, 从“get started”开始阅读。

InfoQ：在设计流处理系统时，有哪些必须考虑的重要因素？
符茂松：理解需求，承认取舍(tradeoff)，然后作出相应的设计。
对于流处理系统，以下需求（因素）的考量是最重要的：
首要的当然是响应速度，作为一个实时计算框架延时一定要小。
其次是稳定性，可扩展性和性能可估性（Performance predictable）。实时数据流量一直是向上增长的；实时处理框架应该可以在数据增多的情况下工作稳定可靠，可扩展。
再就是易于调试。计算框架的出现，如hadoop或heron，最重要的原因就是用来处理大规模的数据。

InfoQ：对于Heron或Twitter的流处理，以后有什么规划？对于实时流处理的技术趋势，您有什么样的看法？
符茂松：1，更稳定，更scalable，功能更强的底层流处理框架。比如，我们在考虑加入以下功能的原生支持：如stateful processing, precise recovery after failure (or so-called exactly once), runtime scaling。(更多地请参照roadmap)。
2，使Heron具有高可拔插特性，并且我们为了这个目标已经做了很好的接口设计。我们希望Heron能满足所有需求，可以在任意环境下运行Heron，如：aurora，yarn，mesos，AWS EC2等等；也可以用任意语言来书写Heron job，如：Java，Python，C++等等；
3，在Heron之上此之上提供更加高级的接口，如SQL on top of Heron。这样的层次结构可以更好地协作，更好地设计，以及更好地优化。

InfoQ：Heron的研发过程经历了哪些阶段？有哪些坑可以提醒其他朋友避开的？
符茂松：主要分成以下几个阶段。需要注意的是，以下阶段并不是有泾渭分明的间隔和计划的。他们是逻辑性的，实际上会混杂在一起，甚至交错。区分成不同的阶段更多是的事后反思得出来的结果。
1，分析需求和思考设计目标。
Heron的出现是需求自然演化成产品的过程，而不是拍脑袋决定的。如之前所说的，我们重度依赖Storm，但在使用过程中遇到了许多头疼的问题。从另外一个角度看，这些问题其实也是需求。我们意识到Storm已经不能够很好地满足这些需求了。我们整理出需求。需要注意的是，需求的出现并不是某一天某一刻我们一起开个会就产生的；而是基于运营维护的体验和教训，用户的反馈，自身的开发设计经验，逐渐产生的。
2， 调查研究
当Storm不能满足的需求越来越多的时候，我们开始思考解决方案。大体上，有三个方向：
a，继续改进Storm
b，考察其他开源的实时计算框架，判断是否能够满足我们的需求
c，基于我们的需求，重新开发新一代实时计算框架
一般来说，这三个方向的难度是递增的；所以也会优先考虑前面的方向。我们持续改进Storm，比如说使得单个Storm cluster最大支持的机器数量有数倍的增长；同时我们也考察所有的开源实时计算框架。（2013年）
我们发现：
经过接近一年的优化改进Storm后，我们已经需要触及非常底层的设计。更深层次的优化改进，涉及的工作量剧增。
开源实时计算框架并不能够很好地支持我们的需求。考量主要是基于scalability, 稳定性以及迁移成本。
这个时候我们开始认真思考重新开发新一代实时计算框架，并举行了多次会议进行讨论研究。Twitter的实时计算分析技术积累深厚；目前业界最流行的实时计算框架Storm就是我们开源的。基于丰富的经验教训和确定的需求，我们确信开发新一代框架是当时可以满足需求的最低成本的选择。
3，设计、开发
与大部分项目开发过程类似，不赘述。从项目设计到第一个生产任务上线运行，大概使用了半年时间。（2014年4月～8月）
4，迁移
Twitter重度依赖Storm，但是最大程度降低迁移成本也是我们首要需求以及设计目标。我们选择了兼容Storm native API，用户不需要更改任何一行代码；只需要更改编译文件，便可以把Storm迁移到Heron上。整个迁移时间预计6个月，实际耗时大概4~5个月。作为对比，我们当时对使用其他开源实时计算框架的预计迁移耗时是16个月。

经验教训：
1，要理解需求，承认取舍(tradeoff)，然后作出相应的设计目标。越早期的设计目标修改的成本就越大。很多时候，我们会想当然地进行设计，而不考虑是否真的满足了用户的需求。这样一方面不能解决实际问题；另外一方面会造成了资源的浪费。
2，不要盲目重新造轮子。重造轮子的成本很大，应该是最后的选择。作为对比，我们组另外一个服务，interactive query。在我们考察了市面上大部分的提供该服务的开源项目后，我们选择了Presto进行部署运维，并没有自己重造轮子，因为我们确信他能够很好地满足我们的需求，是成本最低的选择；同时我们现在也积极参与到Presto的社区建设，把我们的经验和代码回馈给Presto社区。

InfoQ：在Twitter工作是个什么样的体验？您能形容下你能感受到的硅谷文化吗？
符茂松：湾区公司的文化都是类似的，毕竟同一块土壤，同一群人，自然孕育出相似的结果。而Twitter的特点是“鸟类文化”：敏捷，沟通，信任。
Twitter员工也许是湾区最了解鸟类的人了。Twitter这个词本身就起源于鸟的叫声，而Twitter的Logo也是一只蓝色的小鸟。甚至，在Twitter内部文化都与鸟息息相关，比如 Twitter 欢迎新员工的标语就是”Welcome to the flock” （欢迎来到鸟群)；每间会议室都以鸟的名称命名；许多项目也以鸟的名称来命名，比如说，Heron.
敏捷：小鸟需要更高的振翅频率才能飞天。敏捷是在Twitter工作的态度和做事的方法：快速产出和持续迭代。相对于直接给出完美的方案，我们更推崇先做一个可用的版本发给用户，看一下用户的反馈，基于用户的反馈再做下一次阶段的设计和迭代。
沟通：鸟聚成群。Twitter的文化扁平，特别强调协作。人和人之间互相尊重，在项目开发过程中，鼓励在一起坐下来聊。对于重要的多组协作项目，还会临时开辟War Room（作战室），提供固定空间来让大家集中起来面对面讨论。团队协作讨论的时候，提倡平等的沟通氛围。日常交流也很平等，不会有任何等级差别的感觉。我刚入职作为新人的时候，就曾经给公司CEO写邮件提问问题，CEO也会耐心地回复。公司日常会有非常多的课程以及培训，有大量的机会可以跟顶尖的人物交流分享。环境也是相当得开放，说句不好听得，像网吧一样。咋一看感觉会很粗糙，比如墙好像坑坑洼洼没有刷平，但是认真一看，会发现细节很是考究，比如说用的玻璃，桌椅，甚至白板空间结构物件摆放，都是经过精心设计的。开放式的环境也便于开放式的交流，有时候发现一个问题，可以轻松地招呼大家过来一起讨论。
信任：只鸟的力量有限，鸟儿互相依赖信任对方。信任，开放，是我进入Twitter第一天的最大的感受：可以看到大量实时的统计分析数据，比如说不同产品的在不同地区的实时活跃用户，不同产品灰度测试结果；代码库是所有工程师都有权限完全查看的，如果你对某个项目特别有兴趣，完全可以直接把代码下载到本地阅读学习。同样，Twitter也欢迎员工平时带朋友和家庭成员来公司玩。