Twitter 开源了流数据处理引擎 Heron

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

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。