转自:http://blog.jobbole.com/48595/html
诞 生
在2011年Storm开源以前,因为Hadoop的火红,整个业界都在喋喋不休地谈论大数据。Hadoop的高吞吐,海量数据处理的能力使得人们能够方便地处理海量数据。可是,Hadoop的缺点也和它的优势一样鲜明——延迟大,响应缓慢,运维复杂。编程
有需求也就有创造,在Hadoop基本奠基了大数据霸主地位的时候,不少的开源项目都是以弥补Hadoop的实时性为目标而被创造出来。而在这个节骨眼上Storm横空出世了。api
Storm带着流式计算的标签华丽丽滴出场了,看看它的一些卖点:数组
- 分布式系统:可横向拓展,如今的项目不带个分布式特性都很差意思开源。
- 运维简单:Storm的部署的确简单。虽然没有Mongodb的解压即用那么简单,可是它也就是多安装两个依赖库而已。
- 高度容错:模块都是无状态的,随时宕机重启。
- 无数据丢失:Storm创新性提出的ack消息追踪框架和复杂的事务性处理,可以知足不少级别的数据处理需求。不过,越高的数据处理需求,性能降低越严重。
- 多语言:实际上,Storm的多语言更像是临时添加上去似的。由于,你的提交部分仍是要使用Java实现。
下面,咱们简单地认识一下Storm这个产品。服务器
认 识
Storm是一个免费开源、分布式、高容错的实时计算系统。Storm令持续不断的流计算变得容易,弥补了Hadoop批处理所不能知足的实时要求。Storm常常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。Storm的部署管理很是简单,并且,在同类的流式计算工具,Storm的性能也是很是出众的。app
Storm主要分为两种组件Nimbus和Supervisor。这两种组件都是快速失败的,没有状态。任务状态和心跳信息等都保存在Zookeeper上的,提交的代码资源都在本地机器的硬盘上。框架
- Nimbus负责在集群里面发送代码,分配工做给机器,而且监控状态。全局只有一个。
- Supervisor会监听分配给它那台机器的工做,根据须要启动/关闭工做进程Worker。每个要运行Storm的机器上都要部署一个,而且,按照机器的配置设定上面分配的槽位数。
- Zookeeper是Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根据Zookeerper上的心跳和任务运行情况,进行调度和任务分配的。
- Storm提交运行的程序称为Topology。
- Topology处理的最小的消息单位是一个Tuple,也就是一个任意对象的数组。
- Topology由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt能够随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。
下图是一个Topology设计的逻辑图的例子。运维

下图是Topology的提交流程图。机器学习

下图是Storm的数据交互图。能够看出两个模块Nimbus和Supervisor之间没有直接交互。状态都是保存在Zookeeper上。Worker之间经过ZeroMQ传送数据。分布式

虽然,有些地方作得仍是不太好,例如,底层使用的ZeroMQ不能控制内存使用(下个release版本,引入了新的消息机制使用netty代替ZeroMQ),多语言支持更可能是噱头,Nimbus还不支持HA。可是,就像当年的Hadoop那样,不少公司选择它是由于它是惟一的选择。而这些先期使用者,反过来促进了Storm的发展。
发 展
Storm已经发展到0.8.2版本了,看一下两年多来,它取得的成就:
- 有50个大大小小的公司在使用Storm,相信更多的不留名的公司也在使用。这些公司中不乏淘宝,百度,Twitter,Groupon,雅虎等重量级公司。
- 从开源时候的0.5.0版本,到如今的0.8.0+,和即将到来的0.9.0+。前后添加了如下重大的新特性:
- 使用kryo做为Tuple序列化的框架(0.6.0)
- 添加了Transactional topologies(事务性拓扑)的支持(0.7.0)
- 添加了Trident的支持(0.8.0)
- 引入netty做为底层消息机制(0.9.0)
Transactional topologies和Trident都是针对实际应用中遇到的重复计数问题和应用性问题的解决方案。能够看出,实际的商用给予了Storm不少良好的反馈。
- 在GitHub上超过4000个项目负责人。Storm集成了许多库,支持包括Kestrel、Kafka、JMS、Cassandra、Memcached以及更多系统。随着支持的库愈来愈多,Storm更容易与现有的系统协做。Storm的拥有一个活跃的社区和一群热心的贡献者。过去两年,Storm的发展是成功的。
当 前
Storm被普遍应用于实时分析,在线机器学习,持续计算、分布式远程调用等领域。来看一些实际的应用:
- 一淘-实时分析系统pora:实时分析用户的属性,并反馈给搜索引擎。最初,用户属性分析是经过天天在云梯上定时运行的MR job来完成的。为了知足实时性的要求,但愿可以实时分析用户的行为日志,将最新的用户属性反馈给搜索引擎,可以为用户展示最贴近其当前需求的结果。
- 携程-网站性能监控:实时分析系统监控携程网的网站性能。利用HTML5提供的performance标准得到可用的指标,并记录日志。Storm集群实时分析日志和入库。使用DRPC聚合成报表,经过历史数据对比等判断规则,触发预警事件。
若是,业务场景中须要低延迟的响应,但愿在秒级或者毫秒级完成分析、并获得响应,并且但愿可以随着数据量的增大而拓展。那就能够考虑下,使用Storm了。
- 试想下,若是,一个游戏新版本上线,有一个实时分析系统,收集游戏中的数据,运营或者开发者能够在上线后几秒钟获得持续不断更新的游戏监控报告和分析结果,而后立刻针对游戏的参数和平衡性进行调整。这样就可以大大缩短游戏迭代周期,增强游戏的生命力(实际上,zynga就是这么干的!虽然使用的不是Storm……Zynga研发之道探秘:用数听说话)。
- 除了低延迟,Storm的Topology灵活的编程方式和分布式协调也会给咱们带来方便。用户属性分析的项目,须要处理大量的数据。使用传统的MapReduce处理是个不错的选择。可是,处理过程当中有个步骤须要根据分析结果,采集网页上的数据进行下一步的处理。这对于MapReduce来讲就不太适用了。可是,Storm的Topology就能完美解决这个问题。基于这个问题,咱们能够画出这样一个Storm的Topology的处理图。

咱们只须要实现每一个分析的过程,而Storm帮咱们把消息的传送和接受都完成了。更加激动人心的是,你只须要增长某个Bolt的并行度就可以解决掉某个结点上的性能瓶颈。
未 来
在流式处理领域里,Storm的直接对手是S4。不过,S4冷淡的社区、半成品的代码,在实际商用方面输给Storm不止一条街。
若是把范围扩大到实时处理,Storm就一点都不寂寞了。
- Puma:Facebook使用puma和Hbase相结合来处理实时数据,使批处理 计算平台具有必定实时能力。 不过这不算是一个开源的产品。只是内部使用。
- HStreaming:尝试为Hadoop环境添加一个实时的组件HStreaming能让一个Hadoop平台在几天内转为一个实时系统。分商业版和免费版。也许HStreaming能够借Hadoop的东风,撼动Storm。
- Spark Streaming:做为UC Berkeley云计算software stack的一部分,Spark Streaming是创建在Spark上的应用框架,利用Spark的底层框架做为其执行基础,并在其上构建了DStream的行为抽象。利用DStream所提供的api,用户能够在数据流上实时进行count,join,aggregate等操做。
固然,Storm也有Yarn-Storm项目,能让Storm运行在Hadoop2.0的Yarn框架上,可让Hadoop的MapReduce和Storm共享资源。
总 结
知乎上有一个挺好的问答: 问:实时处理系统(相似s4, storm)对比直接用MQ来作好处在哪里? 答:好处是它帮你作了: 1) 集群控制。2) 任务分配。3) 任务分发 4) 监控 等等。
须要知道Storm不是一个完整的解决方案。使用Storm你须要加入消息队列作数据入口,考虑如何在流中保存状态,考虑怎样将大问题用分布式去解决。解决这些问题的成本可能比增长一个服务器的成本还高。可是,一旦下定决定使用了Storm并解决了那些恼人的细节,你就能享受到Storm给你带来的简单,可拓展等优点了。
技术的发展突飞猛进,数据处理领域愈来愈多优秀的开源产品。Storm的过去是成功的,未来会如何发展,咱们拭目以待吧。
后记
本文的重点是描述Storm的应用场景和将来的发展前景,让你们对Storm有一个初步的印象。若是,要落地使用的朋友,在网上能够找到不少优秀的Storm的技术文章。例如:Storm的核心贡献者徐明明的博客和淘宝关于storm的文章。