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说“在短时间内不会,但长期来看可能。”