Chinaunix首页 | 论坛 | 博客
  • 博客访问: 498058
  • 博文数量: 80
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1916
  • 用 户 组: 普通用户
  • 注册时间: 2013-07-11 22:01
个人简介

从事实时计算多年,熟悉jstorm/spark/flink/kafka/rocketMq, 热衷于开源,希望在这里和前辈们一起学习与分享,得到长足的进步!邮箱:hustfxj@gmail.com 我的githup地址是:https://github.com/hustfxj。欢迎和大家一起交流探讨问题。

文章分类

全部博文(80)

文章存档

2017年(11)

2015年(3)

2014年(33)

2013年(33)

分类: 大数据

2015-06-03 14:23:22

昨日,Twitter发布了新开发的数据实时分析平台Heron,以下为官方文档摘译:

我们每天在Twitter上处理着数十亿的事件。正如你猜测的那样,实时分析这些事件是一个巨大的挑战。目前,我们主要的分析平台是开源的分布式流计算系统Storm。但是随着Twitter数据规模变大和多样化,我们的需求已经发生了改变。因此,我们设计了一个新系统Heron——实时分析平台,它可完全兼容Storm的API。我们在昨天的SIGMOD 2015上正式推出。

基本原理和方法:

实时流系统是在大规模数据分析的基础上实现系统性的分析。另外,它还需要:每分钟处理数十亿事件的能力、有秒级延迟,和行为可预见;在故障时保证数据的准确性,在达到流量峰值时是弹性的,并且易于调试和在共享的基础设施上实现简单部署。

为了满足这些需求,我们讨论出了几种方案,包括:扩展Storm、使用其他的开源系统、开发一个全新的平台。因为我们有几个需求是要求改变Storm的核心架构,所以对它进行扩展需要一个很长的开发周期。其他的开源流处理框架并不能完美满足我们对于规模、吞吐量和延迟的需求。而且,这些系统也不能兼容Storm API——适应一个新的API需要重写几个topologies和修改高级的abstractions,这会导致一个很长的迁移过程。所以,我们决定建立一个新的系统来满足以上提到需求和兼容Storm API。

Heron的特色:

我们开发Heron,主要的目标是增加性能预测、提高开发者的生产力和易于管理。

图1:Heron Architecture

图2:Topology Architecture

对于Heron的整体架构请看图1和图2。用户使用Storm API来构建和提交topologies来实现一个调度。调度运行的每一个topology作为一个job,有几个容器组成,其中一个容器运行主topology,负责管理topology。每个剩余的容器运行一个流管理器,负责数据路由——一个权值管理器,用来搜集和报告各种权值和多个Heron实例(运行user-defined spout/bolt代码)进程。这些容器是基于集群中的节点的资源可用性来实现分配和调度。对于topology元数据,例如物理计划和执行细节,都是保管在Zookeeper中。

Heron功能:

  • Off the shelf scheduler:通过抽象出调度组件,我们可轻易地在一个共享的基础设施上部署,可以是多种的调度框架,比如Mesos、YARN或者一个定制的环境。
  • Handling spikes and congestion:Heron 具有一个背压机制,即在执行时的一个topology中动态地调整数据流,从而不影响数据的准确性。这在流量峰值和管道堵塞时非常有用。

图3:Heron UI showing logical plan, physical plan and status of a topology

  • Easy debugging:每个任务是进程级隔离的,从而很容易理解行为、性能和文件配置。此外,Heron topologies复杂的UI如图3所示,可快速和有效地排除故障问题。
  • Compatibility with Storm:Heron提供了完全兼容Storm的特性,所我们无需再为新系统投资太多的时间和资源。另外,不要更改代码就可在Heron中运行现有的Storm topologies,实现轻松地迁移。
  • Scalability and latency:Heron能够处理大规模的topologies,且满足高吞吐量和低延迟的要求。此外,该系统可以处理大量的topologies。

Heron性能

我们比较了Heron和Storm,样本流是150,000个单词,如下图所示:

图4. Throughput with acks enabled

图5. Latency with acks enabled

如图4所示,Heron和Storm的吞吐量呈现线性增长的趋势。然而,在所有的实验中,Heron吞吐量比Storm高10–14倍。同样在端至端延迟方面,如图5所示,两者都在增加,可Heron延迟比Storm低5–15倍。

除此之外,我们已经运行topologies的规模大概是数百台的机器,其中许多实现了每秒产生数百万次事件的资源处理,完全没有问题。有了Heron,众多topologies的每秒集群数据可达到亚秒级延迟。在这些案例中,Heron实现目标的资源消耗能够比Storm更低。

Heron at Twitter

在Twitter,Heron作为我们主要的流媒体系统,运行数以百万计的开发和生产topologies。由于Heron可高效使用资源,在迁移Twitter所有的topologies后,整体硬件减少了3倍,导致我们的基础设置效率有了显著的提升。

下一步?

我们乐意协作和在Storm社区分享我们的经验,或是其他实时流处理系统的社区,以便进一步促进这些程序的开发。

我们第一步是分享我们在SIGMOD 2015上的Heron研究论文。你会发现更多的细节:我们设计Heron的动机、系统的功能和性能,以及我们如何在Twitter上使用它。

致谢:

Sanjeev KulkarniMaosong FuNikunj BhagatSailesh MittalVikas R. Kedigehalli, Siddarth Taneja (@staneja), Zhilan ZweigerChristopher Kellogg, Mengdie Hu (@MengdieH) and Michael Barry.

「注:上面感谢的是Heron贡献者,Twitter ID也给了出来,如果对这个系统很感兴趣,不妨联系他们。」

还要着重感谢Storm社区,他们提供了很多的经验教训,帮助我们推进分布式实时分析处理系统。

参考:

  1. Twitter Heron: Streaming at Scale, Proceedings of ACM SIGMOD Conference, Melbourne, Australia, June 2015

  2. Storm@Twitter, Proceedings of ACM SIGMOD Conference, Snowbird, Utah, June 2014

阅读(1821) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~