Twitter 已经用 Heron 替换了 Storm

Twitter 已经用 Heron 替换了 Storm。此举将吞吐量最高提升了 14 倍，单词计数拓扑时间延迟最低降到了原来的 1/10，所需的硬件减少了 2/3。

Twitter 使用 Storm 实时分析海量数据已经有好几年了，并在 2011 年将其开源。该项目稍后开始在 Apache 基金会孵化，并在去年秋天成为顶级项目。Storm 以季度为发布周期，现在已经达到了 0.9.5 版本，并且正在向着人们期望的 1.0 稳定版前进。但一直以来，Twitter 都在致力于开发替代方案 Heron，因为 Storm 无法满足他们的实时处理需求。

Twitter 的新实时处理需求包括：“每分钟数十亿的事件；大规模处理具有次秒级延迟和可预见的行为；在故障情况下，具有很高的数据准确性；具有很好的弹性，可以应对临时流量峰值和管道阻塞；易于调试；易于在共享基础设施中部署。” Karthik Ramasamy 是 Twitter Storm/Heron 团队的负责人。据他介绍，为满足这些需求，他们已经考虑了多个选项：增强 Storm、使用一种不同的开源解决方案或者创建一个新的解决方案。增强 Storm 需要花费很长时间，也没有其它的系统能够满足他们在扩展性、吞吐量和延迟方面的需求。而且，其它系统也不兼容 Storm 的 API，需要重写所有拓扑。所以，最终的决定是创建 Heron，但保持其外部接口与 Storm 的接口兼容。

拓扑部署在一个 Aurora 调度器上，而后者将它们作为一个由多个容器（cgroups）组成的任务来执行：一个 Topology Master、一个 Stream Manager、一个 Metrics Manager（用于性能监控）和多个 Heron 实例 (spouts 和 bolts)。拓扑的元数据保存在 ZooKeeper 中。处理流程通过一种反压机制实现调整，从而控制流经拓扑的数据量。除 Aurora 外，Heron 还可以使用其它服务调度器，如 YARN 或 Mesos。实例运行用户编写的 Java 代码，每个实例一个 JVM。Heron 通过协议缓冲处理彼此间的通信，一台机器上可以有多个容器。（要了解更多关于 Heron 内部架构的细节信息，请阅读论文《 Twitter Heron：大规模流处理》。）

Twitter 已经用 Heron 完全替换了 Storm。前者现在每天处理“数 10TB 的数据，生成数 10 亿输出元组”，在一个标准的单词计数测试中，“吞吐量提升了 6 到 14 倍，元组延迟降低到了原来的五到十分之一”，硬件减少了 2/3。

当被问到 Twitter 是否会开源 Heron 时，Ramasamy 说“在短时间内不会，但长期来看可能。”