本文详细介绍了Storm的诞生背景、与传统大数据处理的区别、基本架构、Topology概念、消息传输机制，以及与Hadoop的对比。通过案例展示了Storm在实时计算中的优势，并探讨了其当前应用及未来发展。对于寻求低延迟实时分析解决方案的读者，Storm是一个值得考虑的选择。
折腾storm有一段时间了，上篇博客写了怎么部署自己的storm系统，有必要解释一下的架构和原理。
结合我看到的一些资料，做个简单的总结，尤其是对于storm能做什么，适合做什么，应该是能给刚接触storm的同学们一些启发。
1 诞生
在2011年Storm开源之前，由于Hadoop的火红，整个业界都在喋喋不休地谈论大数据。Hadoop的高吞吐，海量数据处理的能力使得人们可以方便地处理海量数据。但是，Hadoop的缺点也和它的优点同样鲜明——延迟大，响应缓慢，运维复杂。
有需求也就有创造，在Hadoop基本奠定了大数据霸主地位的时候，很多的开源项目都是以弥补Hadoop的实时性为目标而被创造出来。而在这个节骨眼上Storm横空出世了。
Storm带着流式计算的标签华丽丽滴出场了，看看它的一些卖点：
§ 分布式系统：可横向拓展,现在的项目不带个分布式特性都不好意思开源。
§ 运维简单：Storm的部署的确简单。虽然没有Mongodb的解压即用那么简单，但是它也就是多安装两个依赖库而已。
§ 高度容错：模块都是无状态的，随时宕机重启。
§ 无数据丢失：Storm创新性提出的ack消息追踪框架和复杂的事务性处理,能够满足很多级别的数据处理需求。不过，越高的数据处理需求，性能下降越严重。
2 Storm 与传统的大数据
Storm 与其他大数据解决方案的不同之处在于它的处理方式。Hadoop 在本质上是一个批处理系统。数据被引入 Hadoop 文件系统 (HDFS) 并分发到各个节点进行处理。当处理完成时，结果数据返回到 HDFS 供始发者使用。Storm 支持创建拓扑结构来转换没有终点的数据流。不同于 Hadoop 作业，这些转换从不停止，它们会持续处理到达的数据3 Storm的基本架构
Storm主要分为两种组件Nimbus和Supervisor。这两种组件都是快速失败的，没有状态。任务状态和心跳信息等都保存在Zookeeper上的，提交的代码资源都在本地机器的硬盘上。
§ Nimbus负责在集群里面发送代码，分配工作给机器，并且监控状态。全局只有一个。
§ Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程Worker。每一个要运行Storm的机器上都要部署一个，并且，按照机器的配置设定上面分配的槽位数。
§ Zookeeper是Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根据Zookeerper上的心跳和任务运行状况，进行调度和任务分配的。
§ Storm提交运行的程序称为Topology。
§ Tuple：Topology处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。一次消息传递的基本单元。本来应该是一个key-value的map，但是由于各个组件间传递的tuple的字段名称已经事先定义好，所以tuple中只要按序填入各个value就行了，所以就是一个value list.
§ Topology由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。
4 Topology
Topology由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。 Tuple：Topology处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。一次消息传递的基本单元。本来应该是一个key-value的map，但是由于各个组件间传递的tuple的字段名称已经事先定义好，所以tuple中只要按序填入各个value就行了，所以就是一个value list.
spout和bolt以很多task的形式在topology里面同步执行。如果从task的粒度来看一个运行的topology，它应该是这样的:
当Bolt A的一个task要发送一个tuple给BoltB， 它应该发送给Bolt B的哪个task呢？stream grouping专门回答这种问题的。有好几种不同的streamgrouping:
1. 最简单的grouping是shuffle grouping,它随机发给任何一个task。
2. 一种更有趣的grouping是fields grouping,这种grouping机制保证相同field值的tuple会去同一个task。
3. AllGrouping：广播发送，将每一个Tuple发送到所有的Task。
4. GlobalGrouping：所有的Tuple会被发送到某个Bolt中的id最小的那个Task。
5. NoneGrouping：不关心Tuple发送给哪个Task来处理，等价于ShuffleGrouping。
6. DirectGrouping：直接将Tuple发送到指定的Task来处理。
5 Storm的消息传输机制
Storm的底层采用 zeromq（Omq, zeromq）——一个先进的嵌入式网络通讯库，为Storm提供了很多令人激动的功能。以下列出了 zeromq的特点：
· 支持高并发的网络通讯库
· 比TCP更快，适用于大型生产集群和超级计算
· 采用进程内通信、进程间通信、TCP和多播传递消息
· 异步I/O，适用于扩展的多核消息传递应用中
· 通过扇出、发布订阅、管道、请求-应答实现多对多连接
6 hadoop vs storm
全量数据处理使用的大多是鼎鼎大名的hadoop或者hive，作为一个批处理系统，hadoop以其吞吐量大、自动容错等优点，在海量数据处理上得到了广泛的使用。但是，hadoop不擅长实时计算，因为它天然就是为批处理而生的，这也是业界一致的共识。否则最近这两年也不会有s4,storm,puma这些实时计算系统如雨后春笋般冒出来了。
storm的网络直传、内存计算，其时延必然比hadoop的通过hdfs传输低得多；当计算模型比较适合流式时，storm的流式处理，省去了批处理的收集数据的时间；因为storm是服务型的作业，也省去了作业调度的时延。所以从时延上来看，storm要快于hadoop。
下面是storm和hadoop组件的对应关系。
| Hadoop | Storm | |
| 系统角色 | JobTracker | Nimbus |
| TaskTracker | Supervisor | |
| Child | Worker | |
| 应用名称 | Job | Topology |
| 组件接口 | Mapper/Reducer | Spout/Bolt |
7 当前
Storm已经发展到0.9.1版本了，看一下3年多来，它取得的成就：
§ 有100个大大小小的公司在使用Storm，相信更多的不留名的公司也在使用。这些公司中不乏淘宝，百度，携程，Twitter，Groupon，雅虎等重量级公司。来看一些实际的应用：
- 一淘-实时分析系统pora：实时分析用户的属性，并反馈给搜索引擎。最初，用户属性分析是通过每天在云梯上定时运行的MR job来完成的。为了满足实时性的要求，希望能够实时分析用户的行为日志，将最新的用户属性反馈给搜索引擎，能够为用户展现最贴近其当前需求的结果。
- 携程-网站性能监控：实时分析系统监控携程网的网站性能。利用HTML5提供的performance标准获得可用的指标，并记录日志。Storm集群实时分析日志和入库。使用DRPC聚合成报表，通过历史数据对比等判断规则，触发预警事件。
§ 从开源时候的0.5.0版本，到现在的0.9.0+。先后添加了以下重大的新特性：
§ 使用kryo作为Tuple序列化的框架（0.6.0）
§ 添加了Transactionaltopologies（事务性拓扑）的支持（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的拥有一个活跃的社区和一群热心的贡献者。过去3年，Storm的发展是非常成功的。
如果，业务场景中需要低延迟的响应，希望在秒级或者毫秒级完成分析、并得到响应，而且希望能够随着数据量的增大而拓展。那就可以考虑下，使用Storm了。
8 未来
在流式处理领域里，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共享资源。
主要参考的网站资源：
https://github.com/nathanmarz/storm/wiki/Tutorial（storm官方tutorial）
《Getting Started with Storm》By JonathanLeibiusky, Gabriel Eisbruch, Dario Simonassi Publisher: O'ReillyMedia
http://my.oschina.net/leejun2005/blog/147607（一篇对照一个例子讲storm原理和应用的不错文章）
http://www.cnblogs.com/XjChenny/p/3214039.html（非常完整的storm安装教程，但没有提到安装过程可能遇到的问题）
http://javanlu.github.io/blog/2013/10/11/storm-deploy-tutorial/#storm-starterwordcount（一个github上的博客，《Getting Started with Storm》一书部分的个人翻译。）
8 其他开源的大数据解决方案
自 Google 在 2004 年推出 MapReduce 范式以来，已诞生了多个使用原始 MapReduce 范式（或拥有该范式的质量）的解决方案。Google 对 MapReduce 的最初应用是建立万维网的索引。尽管此应用程序仍然很流行，但这个简单模型解决的问题也正在增多。
表 1 提供了一个可用开源大数据解决方案的列表，包括传统的批处理和流式处理应用程序。在将 Storm 引入开源之前将近一年的时间里，Yahoo! 的 S4 分布式流计算平台已向 Apache 开源。S4 于 2010 年 10 月发布，它提供了一个高性能计算 (HPC) 平台，向应用程序开发人员隐藏了并行处理的复杂性。S4 实现了一个可扩展的、分散化的集群架构，并纳入了部分容错功能。
表 1. 开源大数据解决方案
| 解决方案 | 开发商 | 类型 | 描述 |
|---|---|---|---|
| Storm | 流式处理 | Twitter 的新流式大数据分析解决方案 | |
| S4 | Yahoo! | 流式处理 | 来自 Yahoo! 的分布式流计算平台 |
| Hadoop | Apache | 批处理 | MapReduce 范式的第一个开源实现 |
| Spark | UC Berkeley AMPLab | 批处理 | 支持内存中数据集和恢复能力的最新分析平台 |
| Disco | Nokia | 批处理 | Nokia 的分布式 MapReduce 框架 |
| HPCC | LexisNexis | 批处理 | HPC 大数据集群 |
扫一扫
932
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
