跟我一起云计算（1）——storm
概述
最近要做一个实时分析的项目，所以需要深入一下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，首先了解一下它的架构：
- ExclamationTopology: Java编写的基本示例
- WordCountTopology: 和python一起使用的例子
- 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结合起来，也许处理实时的大数据真的很难！
