Twitter宣布开源Heron。Heron是Apache Storm的后继者，也是一种流数据处理引擎。为方便开发人员对Heron的采用，Heron向后兼容Apache Storm。Heron所给出的可扩展性、调试能力、在共享集群架构中的工作能力以及更优的性能，使得其在Twitter内部已取代Apache Storm成为Twitter流数据处理引擎。在文档中给出了Heron的完全特性列表。

针对这次发布，InfoQ择机访谈了Twitter技术经理和Heron项目的合作创始人Karthik Ramasamy。

InfoQ： 让我们从Apache Storm开始。是哪些Apache Storm的技术限制，导致你们去启动一个新的项目而非去对原始项目做改进？

Karthik Ramasamy： 对于当前Twitter的规模而言，在可扩展性、可调试性、可管理性、对其它数据服务有效地共享集群资源等方面，使用Apache Storm变得愈发具有挑战性。

在Storm中，来自于同一拓扑结构（Topology）中多个组件的任务被塞入到同一个操作系统进程中，这使得调试变得十分的困难。此外，Storm需要专用的集群资源，这使得运行Storm 拓扑结构需要特别的硬件资源分配。这种工作方式导致了对珍贵的集群资源的低效使用，也限制了应用按需扩展的能力。

使用Storm时，筹备新的生产拓扑结构时需要对机器做手动隔离，同样反之当应用不再需要该拓扑结构时，被分配服务于该拓扑结构的机器必须要停止服务。这种方式下的机器分配管理是十分繁琐的。

最终，在无需被迫去重写大量已基于Storm开发的应用的情况下，我们想要去达成上面所列出的所有目标。

在对多个方面检查之后，我们得出这样的一个结论，即为满足上面所列出的所有目标，我们需要设计一个新的流数据处理系统。该新系统被称为Heron项目。Heron是API兼容于Storm的，这使得现有的Storm用户易于迁移到Heron上，并且新用户也易于在Heron上做应用开发。现在Twitter内部的所有生产拓扑结构已经运行在Heron上。这除了为我们提供了相对于Storm而言显著的性能提升和更低的资源消耗，Heron在可调试性、可扩展性和可关联性上具有巨大的优越性。

InfoQ： 仅在Apache中就有很多的流数据处理架构。Heron与这些项目相比有哪些不同之处？

Ramasamy： 我们的设计理念概述于我们发表于SIGMOD 2015会议上的论文“Twitter Heron: Stream Processing at Scale”（2015年5月）中。Twitter在Storm 拓扑结构开发中投入了大量精力，此外一些其它的企业也正在一定规模上运行或立志要去运行流数据处理应用。实际上Storm并非是仅为我们自身的需求而需要扩展，也是为了其它的一些解决方案的需求，这些解决方案看上去并非十分成熟，并需要对现有拓扑结构进行完全且高代价的重组。

当前的局面验证了我们对世界趋向于实时化这个最初的预测。以极低延迟分析实时数据的需求正在持续增长。在许多快速扩展的实时用例中都应用了Heron，其中包括了异常和欺诈检测、物联网和万物互联应用、嵌入式系统、虚拟现实和增强现实、广告投放、金融、安全和社会媒体。

当前局面中的主要变数在于大规模应用中可靠性的验证。Storm是前期的解决方案之一，在按需升级到Heron后，故障发生报告降低了10倍，运行也更加的高效。这些问题可能在当前系统中大规模地存在，但这也是存在变数的，因为Twitter具有其它的企业所仍未体验到的独特需求。我们很高兴看到该生态系统的增长，我们将继续承担开源空间中的引领者角色。

InfoQ： 在你的博客中提及Heron是流数据处理架构中的一个根本性变革。你为什么会这么说？

Ramasamy： 从基于线程的Storm到基于进程的Heron是在流数据处理架构中的根本改进。这种改进使得用户易于对他们拓扑结构的工作情况进行推理，并能对拓扑结构中的各个组件进行独立地性能分析和调试。虽然实现该改进需要对Storm进行完全重写，但是该改进使得Heron 拓扑结构的开发更加简单并增强了可调试能力。我们认为这种在架构开发上的投资已经得到了回报，体现为故障情况报告得到了10倍的降低，这证明了Heron“恰好适用”于Twitter规模上。

InfoQ： Twitter是Heron项目的最大贡献者吗？还有哪些公司也对Heron有贡献？

Ramaswamy： 由于近期我们刚开源了该平台，所以Twitter当前绝对是Heron的主导贡献者，但是我们惊喜于其它的一些大规模企业对采用并为Heron做出贡献所表现出的兴趣。Heron被证实可工作于Twitter这样的规模上，这在我们看来对于流数据处理架构而言是独一无二的，其它的企业正借用我们的设计及实现去进一步地改写该系统。尤其是，正如我们在最初发布中所披露的，Microsoft在使用Apache REEF将Heron工作于YARN上具有关键的贡献，并为进一步改进计算效率给出了一种复杂的打包算法。我们已经具有50位贡献者，他们提交了超过900次的提交请求（Pull Request），我们期待这些贡献会继续地增长。

我们也很高兴地看到，大型中国的企业对Heron进行了标定，并将其用于一些我们所知的Twitter之外的最大规模集群上。我们正在紧密合作，期望更多的企业名字能得到公布。

我们一直致力于开源社区的提交。先于Heron，我们曾贡献了Apache Storm，它开源于2011年。还有集群资源管理器Apache Mesos、MapReduce流数据处理架构Summingbird以及更近期提交的高性能日志复制服务DistributedLog。我们是带着将其开源的目标来对Heron进行开发的。自最初的SIGMOD论文发表以来，不断的有人询问我们Heron的开源计划，尤其是很多咨询来自于其它的一些企业，这些或是在很大的规模上运行并具有实时处理的需求，或是与我们面对同样的生产问题并想使用可获取的经验。我们很高兴看到所有这些对Heron的兴趣，并很高兴看到Heron被采用。

InfoQ： 对Apache Storm的向后兼容性被看作是开发人员采用Heron的关键因素。该特性是否在所有将来版本中也是有保证的？你能从开发人员的角度提出一些告诫，并从实现者的角度给出一些挑战吗？

Ramasamy： Twitter用例可被无缝支持是至关重要的，该用例主要是向后兼容我们对Storm的使用。但是在Apache Storm中还包括了我们从不需要且永不会去支持的新用例，这些用例主要是分布式远程过程调用（Distributed Remote Procedure Calls，DRPC）。现在Heron已经开源，我们发现一些有积极性的贡献者有兴趣去做对更多功能的支持，因而我们希望Apache Storm的未来版本将会继续得到支持。在我们看来，尽快支持所需的所有语义并尽可能地保持Heron和Storm的兼容，这对于这两者的生态系统都是有益的。

InfoQ：你能详细说明一下Heron的路线图吗？

Ramasamy： 在很大程度上，路线图侧重于快速而高效地支持除Apache aurora之外的主调度器。通过REFF和SLURM，Heron已得到了Apache YARN的支持。此外对Apache Mesos的支持虽然是实验性，但是这种支持是稳定的。我们期待对DC/OS、Marathon和 Kubernetes的支持，并已正在开发实现中。我们以安装简单化和操作可靠性为目标。此外，我们正在扩展Heron的运维能力，目标包括热部署、大型活动期间拓扑结构的手动扩展、拓扑结构的自动扩展等功能。我们还正在围绕一些阻断算法开展着工作，研究当分布式系统中存在拖后腿的节点和网络分区时如何继续对流数据进行处理。

虽然Heron将继续侧重于Twitter的核心用例，但一些正在生产环境中测试的特性也即将被添加进来。如果你有兴趣贡献特定的特性，或是想要去改进现有的系统，请伸出你的手并加入Heron社区和Heronstreaming开发者协作群组（Slack Channel）。我们期待着Heron社区的进一步发展。

在入门指南中，详细说明了Heron二进制程序的下载和拓扑结构示例的创建。

查看英文原文：Twitter Open Sources Stream Processing Engine Heron