Storm是一个免费开源、分布式、高容错的实时计算系统，Twitter开发贡献给社区的。Storm令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。
Storm经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。
特点
1、Storm这是一个分布式的、容错的实时计算系统
2、Storm集群主要由一个主节点（master node）和一组工作节点(worker nodes)组成，通过 Zookeeper集群进行协调。
3、主节点通常运行一个后台程序 —— Nimbus，它接收用户提交的任务，并将任务分配到工作节点，同时进行故障监测。工作节点同样会运行一个后台程序 —— Supervisor，用于接收工作指派并基于要求运行工作进程——Worker。
Storm架构
- Topology：storm中运行的一个实时应用程序.
- Nimbus：负责资源分配和任务调度.
- Supervisor：负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程.
- Worker：运行具体处理组件逻辑的进程.
- Spout：在一个topology中产生源数据流的组件.
- Bolt：在一个topology中接受数据然后执行处理的组件.
- Task：worker中每一个spout/bolt的线程称为一个task.
- Tuple：一次消息传递的基本单元.
- Stream grouping：消息的分组方法
架构理解
Storm的设计思想
在Storm中也有对于流stream的抽象，流是一个不间断的无界的连续tuple，注意Storm在建模事件流时，把流中的事件抽象为tuple即元组，后面会解释storm中如何使用tuple。 Storm认为每个stream都有一个stream源，也就是原始元组的源头，所以它将这个源头抽象为spout，spout可能是连接twitter api并不断发出tweets，也可能是从某个队列中不断读取队列元素并装配为tuple发射。 有了源头即spout也就是有了stream，那么该如何处理stream内的tuple呢，同样的思想twitter将流的中间状态转换抽象为Bolt，bolt可以消费任意数量的输入流，只要将流方向导向该bolt，同时它也可以发送新的流给其他bolt使用，这样一来，只要打开特定的spout（管口）再将spout中流出的tuple导向特定的bolt，又bolt对导入的流做处理后再导向其他bolt或者目的地。 我们可以认为spout就是一个一个的水龙头，并且每个水龙头里流出的水是不同的，我们想拿到哪种水就拧开哪个水龙头，然后使用管道将水龙头的水导向到一个水处理器（bolt），水处理器处理后再使用管道导向另一个处理器或者存入容器中。 为了增大水处理效率，我们很自然就想到在同个水源处接上多个水龙头并使用多个水处理器，这样就可以提高效率。没错Storm就是这样设计的，看到下图我们就明白了。
对应上文的介绍，我们可以很容易的理解这幅图，这是一张有向无环图，Storm将这个图抽象为Topology即拓扑（的确，拓扑结构是有向无环的），拓扑是storm中最高层次的一个抽象概念，它可以被提交到storm集群执行，一个拓扑就是一个流转换图，图中每个节点是一个spout或者bolt，图中的边表示bolt订阅了哪些流，当spout或者bolt发送元组到流时，它就发送元组到每个订阅了该流的bolt（这就意味着不需要我们手工拉管道，只要预先订阅，spout就会将流发到适当bolt上）。
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。