概述

最近要做一个实时分析的项目，所以需要深入一下storm。

为什么storm

综合下来，有以下几点：

1. 生逢其时

MapReduce 计算模型打开了分布式计算的另一扇大门，极大的降低了实现分布式计算的门槛。有了MapReduce架构的支持，开发者只需要把注意力集中在如何使用 MapReduce的语义来解决具体的业务逻辑，而不用头疼诸如容错，可扩展性，可靠性等一系列硬骨头。一时间，人们拿着MapReduce这把榔头去敲 各种各样的钉子，自然而然的也试图用MapReduce计算模型来解决流处理想要解决的问题。各种失败的尝试之后，人们意识到，改良MapReduce并 不能使之适应于流处理的场景，必须发展出全新的架构来完成这一任务(MapReduce不适合做流处理的原因Yahoo！在其S4的介绍论文里面有比较详 细的阐述，而UCBerkeley的SparkStreaming项目现在正在尝试挑战这一结论，感兴趣的同志请自行查看)。另一方面，人们对传统的 CEP解决方案心存疑虑，认为其非分布式的架构可扩展性不够，无法scaleout来满足海量的数据处理要求。这时候，Yahoo！的S4以及 Twitter的Storm恰到好处的挠到了人们的痒处。

2. 可扩展性

更加明确的说，是scaleout的能力。所谓Scale out （http://en.wikipedia.org/wiki/Scalability#Scale_horizontally_.28scale_out.29）， 简单来说就是当一个集群的处理能力不够用的时候，只要往里面再追加一些新的节点，计算有能力迁移到这些新的节点来满足需要。可能的情况下，选择 Scaleout 而非Scale up，这个观念已经深入人心。一般来说，实现Scaleout的关键是Shared nothing architecture，即计算所需要的各种状态都是自满足的，不存在对特定节点强依赖，这样，计算就可以很容易的在节点间迁移，整个系统计算能力不够 用的时候，加入新的节点就可以了。Storm的计算模型本身是Scaleout友好的，Topology 对应的Spout和Bolt并不需要和特定节点绑定，可以很容易的分布在多个节点上。此外，Storm还提供了一个非常强大的命令 （rebalance），可以动态调整特定Topology中各组成元素（Spout/Bolt）的数量以及其和实际计算节点的对应关系。

3. 系统可靠性

Storm 这个分布式流计算框架是建立在Zookeeper的基础上的，大量系统运行状态的元信息都序列化在Zookeeper中。这样，当某一个节点出错时，对应 的关键状态信息并不会丢失，换言之Zookeeper的高可用保证了Storm的高可用。文档（https://github.com /nathanmarz/storm/wiki/Fault-tolerance）讨论了Storm各个子系统的错误冗余行为，可以进一步参考。

4. 计算的可靠性

分 布式计算涉及到多节点/进程之间的通信和依赖，正确的维护所有参与者的状态和依赖关系，是一件非常有挑战性的任务。Storm实现了一整套机制，确保消息 会被完整处理（https://github.com/nathanmarz/storm/wiki/Guaranteeing-message- processing）。 此外，通过TransactionalTopology（https://github.com/nathanmarz/storm/wiki /Transactional-topologies） ，Storm可以保证每个tuple“被且仅被处理一次”。

5. Opensource

这个就不用多说了，开源使得Storm社区及其活跃，到本文写作的时候，Storm已经发展到了0.81，Storm的使用者已经有了一个长长的名单（https://github.com/nathanmarz/storm/wiki/Powered-By），其中不乏比如淘宝，支付宝，Twitter，Groupon这种互联网巨头。

6. Clojure基础上的实现

Storm的核心代码是Clojure和Java。Clojure是一门JVM基础上的函数式编程语言（http://clojure.org/）， 是支持STM（SoftwareTransactional Memory）的少数几门语言之一。Clojure推出以来，得到了广泛关注，人们普遍认为，其函数式编程所具有的各种特性能在分布式环境中大有用武之 地， 而Storm则给出了一个很好的实例。从另一个角度来说，Storm也能大大的推动Clojure的普及。

总言之，时势造英雄，Storm在正确的时间出现在了正确的地点，而且刚刚好做了正确的事情，想不红都没有道理。

高层架构

从高来看storm的架构：

指南

在这个指南中，你将学到如何创建strom架构和部署它的集群。Java将是示例中用到的主要语言，在其它的一些示例中将使用python来描述strom支持多语言的能力。

先安装strom，可以参考：

http://my.oschina.net/leejun2005/blog/147607?from=20130804

上面的文章里面已经描述的很清楚了。

可以先从示例storm-starter开始学习strom。

地址是：

https://github.com/nathanmarz/storm-starter

先决条件

你需要安装git和java然后设置这个用户的环境变量。另外还有两个示例需要安装python和ruby。

然后创建新目录下载storm-starter

$ git clone git://github.com/nathanmarz/storm-starter.git && cd storm-starter

storm-starter概述

storm-starter包含很多使用storm的示例。如果你第一次使用storm，首先了解一下它的架构：

1. ExclamationTopology: Java编写的基本示例
2. WordCountTopology: 和python一起使用的例子
3. ReachTopology: 复杂的DRPC的例子

当你熟悉了上面的示例之后，可以在in src/jvm/storm/starter/ 下例如RollingTopWords 去熟悉一些更高级的实现。

如果你要学习更多的示例，可以到Storm project page.

使用storm-starter

使用storm-starter有多种方式，可以使用Leiningen或者maven。这里使用maven。

首先编译：

mvn -f m2-pom.xml compile exec:java -Dexec.classpathScope=compile -Dexec.mainClass=storm.starter.WordCountTopology

然后打包：

mvn -f m2-pom.xml package

运行测试：

mvn -f m2-pom.xml test

然后就是把打包的jar包发送到storm里运行了。

正在讨论的架构

下面就是我们正在处理的项目中使用的架构，还在讨论阶段，也希望对这个有见解的童鞋发表一下自己的观点：

古有“即生瑜，何生亮”，不过我觉得如果没有瑜和亮，可能谁都无法打败曹操，和现在的架构一下，如果不是把流框架storm和任务处理框架hadoop结合起来，也许处理实时的大数据真的很难！