转自：http://qing.weibo.com/2294942122/88ca09aa33002dsh.html
EMC中国研究院 向东
提起Big Data，人们往往会提起大数据的4个V: Volume,Velocity , Variety 以及Value。这四个V从各个侧面说明了大数据并不是新瓶装旧酒: 面对数据产生来源，产生方式，处理方式等等一系列质变，原来适用的数据挖掘/BI工具已经不再满足实际需要，人们迫切需要新的计算模式，基础架构以及开箱即用的工具集来使自己的业务运行的更好。这也是当前大数据如此火热的原因。
流处理（Stream Processing） 或者复杂事件处理（CEP，complex event processing） 也不是一个新概念，对此相关的研究和相应的产品已经有很多了，其中最有名的应该算开源CEP引擎Esper（http://esper.codehaus.org/）。 相对于原有的产品，现在的流处理新贵，比如来自Yahoo！的S4和来自Twitter的Storm，到底有哪些独到的长处，让人们趋之若鹜？
本文试图在Storm的基础上对此解读。
）这门极具潜力的函数式编程语言开发的，这也使得Storm格外引人注目。
@EMC中国研究院 版权所有
Grouping，Shuffle Grouping可以保证event在Boltinstance间随机分布，每个instance都收到相同数量的event。
Berkeley的SparkStreaming项目现在正在尝试挑战这一结论，感兴趣的同志请自行查看)。另一方面，人们对传统的CEP解决方案心存疑虑，认为其非分布式的架构可扩展性不够，无法scale out来满足海量的数据处理要求。这时候，Yahoo！的S4以及Twitter的Storm恰到好处的挠到了人们的痒处。
简单来说就是当一个集群的处理能力不够用的时候，只要往里面再追加一些新的节点，计算有能力迁移到这些新的节点来满足需要。可能的情况下，选择Scale out 而非Scale up，这个观念已经深入人心。一般来说，实现Scale out的关键是Shared nothing architecture，即计算所需要的各种状态都是自满足的，不存在对特定节点强依赖，这样，计算就可以很容易的在节点间迁移，整个系统计算能力不够用的时候，加入新的节点就可以了。Storm的计算模型本身是Scale out友好的，Topology
对应的Spout和Bolt 并不需要和特定节点绑定，可以很容易的分布在多个节点上。此外，Storm还提供了一个非常强大的命令（rebalance），可以动态调整特定Topology中各组成元素（Spout/Bolt）的数量以及其和实际计算节点的对应关系。
，Storm可以保证每个tuple“被且仅被处理一次”。@EMC中国研究院 版权所有
而Storm则给出了一个很好的实例。从另一个角度来说，Storm也能大大的推动Clojure的普及。
store的事实解决方案，Storm在设计时所做的这个折中相当不错。文档（http://xumingming.sinaapp.com/466/twitter-storm-code-analysis-zookeeper-dirs/）讨论了Storm到底保存了那些状态信息到Zookeeper中，可以详细参考。
task很类似，实际的数据处理发生在这里。 不同的是，map/reduce task 终究会结束，但worker则会一直执行下去。同样，Storm引入了WorkerSlot的概念，也就是说，slave节点上的worker的数量是有限的。
文档 （https://github.com/nathanmarz/storm/wiki/Understanding-the-parallelism-of-a-Storm-topology）详细解释了Topology是如何映射到Worker。简言之，这个过程涉及到了3个相关实体：
1. Worker。 一个完整的Topology是由分布在多个节点上的Worker进程来执行的，每个Worker都执行（且仅执行）Topology的一个子集。
2. Executor。在每个Worker内部，会有多个Executor，每个executor对应一个线程。
3. Task。执行具体数据处理的相关实体，也就是用户实现的Spout/Blot实例。Storm中，一个executor可能会对应一个或者多个task。这就是说，系统中executor的数量是小于等于task的数量的。
上述代码定义的Topology共有2个worker，BlueSpout/Green Bolt/Yellow Bolt各自的executor以及task的数量分别是 2/2/6以及2/4/6 （注：1. 如果没有显式的定义task的数量，Storm会默认其数量和component对应的executor数量相同 2. 实际在Storm中执行的Topology和用户定义的有稍许差别，系统会自动增加acker Bolt来保证消息能被处理）。此Topology被Storm执行时，可能的映射如下：
图五： Topology 映射
对于特定的Topology来说，其Task的数量在其整个生命周期是固定的，但是Worker/Executor的数量可以通过命令行和Web UI工具使用rebalance命令来调整。
总结
上文仅仅讨论了Storm系统层面简介优雅的设计保证其做到高可扩展性，高可用的。实际上，Storm的文档代码是一个宝库，值得研究的研究的地方很多，比如，确保消息会被完整处理的实现机制以及Transactional Topology的实现机制；再在比如ZMQ这个高性能的网络通信库是如何被集成的。任何对分布式计算以及大数据感兴趣的同志都应该深入的研究Storm，展望将来，Storm必将被更加广泛的接受的采纳。