storm入门简介、架构原理分析

一、 Storm简介
Storm是由Nathan Marz开发的，一个免费并开源的分布式实时计算系统。
Storm是基于数据流的实时处理系统，提供了大吞吐量的实时计算能力。通过数据入口获取每条到来的数据，在一条数据到达系统的时候，立即会在内存中进行相应的计算；Storm适合要求实时性较高的数据分析场景。
Storm 不处理静态数据,但它处理连续的流数据。

二、 Storm的特点
Storm实现的一些特征决定了它的性能和可靠性的，Storm使用 Netty 传送消息,消除了中间的排队过程,使得消息能够直接在任务自身之间流动，在消息的背后,是一种用于序列化和反序列化 Storm的原语类型的自动化且高效的机制。
Storm注重容错和管理，Storm 实现了有保障的消息处理,所以每个元组(Turple)都会通过拓扑(Topology)结构进行全面处理;如果发现一个元组还未处理,它会自动从Spout处重发，Storm 还实现了任务级的故障检测，在一个任务发生故障时，消息会自动重新分配以快速重新开始处理。Storm 包含比 Hadoop 更智能的处理管理,流程会由zookeeper来进行管理,以确保资源得到充分使用。

Storm有如下优点：
1、 编程简单：开发人员只需要关注应用逻辑，跟Hadoop相似，Storm提供的编程原语也很简单，降低了开发并行实时处理的任务的复杂性。
2、 高性能，低延迟：可以应用于广告搜索引擎这种要求对广告主的操作进行实时响应的场景。
3、 分布式：可以轻松应对数据量大，单机搞不定的场景
4、 可水平扩展： 随着业务发展，数据量和计算量越来越大，系统可水平扩展。在Storm集群中真正运行topology的主要有三个实体：工作进程、线程和任务。Storm集群中的每台机器上都可以运行多个工作进程，每个工作进程又可创建多个线程,每个线程可以执行多个任务,任务是真正进行数据处理的实体，我们开发的spout、bolt就是作为一个或者多个任务的方式执行的。因此，计算任务在多个线程，进程和服务器之间并行进行,支持灵活的水平扩展。
5、 容错性强：如果在消息处理过程中出了一些异常，Storm会重新安排这个出问题的处理单元，Storm保证一个处理单元永远运行(除非你显式杀掉这个处理单元)。即单个节点挂了不影响应用。
6、 可靠性的消息保证：Storm可以保证spout发出的每条消息都能被“完全处理”。
7、 多语言支持，除了用java实现spout和bolt，根据Storm的多语言协议，可以使用任何你熟悉的编程语言来完成这项工作。多语言协议是Storm内部的一种特殊协议,允许spout或者bolt使用标准输入和标准输出来进行消息传递，传递的消息为单行文本或者是json编码的多行。
8、 快速的消息处理，用Netty作为底层消息队列, 保证消息能快速被处理。
9、 本地模式，支持快速编程测试。

三、 storm与传统数据库
传统关系型数据库是先存后计算，而storm则是先算后存，甚至不存 。
传统关系型数据库很难部署实时计算，只能部署定时任务统计分析窗口数据 。 而storm是进行实时数据流处理的。

四、 storm与传统大数据
storm 与其他大数据解决方案的不同之处在于它的处理方式。
Hadoop 在本质上是一个批处理系统｡数据被引入 Hadoop 文件系统 (HDFS) 并分发到各个节点进行处理｡当处理完成时,结果数据返回到 HDFS 供始发者使用。storm 支持创建拓扑结构来转换没有终点的数据流。不同于 Hadoop 作业,这些转换从不停止,它们会持续处理到达的数据。
Hadoop 的核心是使用 Java™ 语言编写的,但支持使用各种语言编写的数据分析应用程序。而 Twitter Storm 是使用 Clojure语言实现的。

五、 storm架构与原理
1、 Storm采用Master/Slave的主从体系结构,分布式计算由Nimbus和Supervisor两类服务进程实现,Nimbus进程运行在集群的主节点,负责任务的指派和分发,Supervisor运行在集群的从节点,负责执行任务的具体部分。

如图所示：
Nimbus:负责资源分配和任务调度。
Supervisor:负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程。
Worker:运行具体处理组件逻辑的进程。
Task:worker中每一个spout/bolt的线程称为一个task｡同一个spout/bolt的task可能会共享一个物理线程,该线程称为executor。
Storm集群和Hadoop集群表面上看很类似。但是Hadoop上运行的是MapReduce jobs,而在Storm上运行的是拓扑(topology),这两者之间是非常不一样的，一个关键的区别是: 一个MapReduce job最终会结束, 而一个topology永远会运行(除非你手动kill掉)。
storm架构中使用Spout/Bolt编程模型来对消息进行流式处理｡消息流是storm中对数据的基本抽象,一个消息流是对一条输入数据的封装,源源不断输入的消息流以分布式的方式被处理，Spout组件是消息生产者，是storm架构中的数据输入源头，它可以从多种异构数据源读取数据，并发射消息流，Bolt组件负责接收Spout组件发射的信息流，并完成具体的处理逻辑｡在复杂的业务逻辑中可以串联多个Bolt组件，在每个Bolt组件中编写各自不同的功能，从而实现整体的处理逻辑。

• 在Storm的集群里面有两种节点: 控制节点(master node)和工作节点(worker node)。控制节点上面运行一个叫Nimbus后台程序,它的作用类似Hadoop里面的JobTracker，Nimbus负责在集群里面分发代码，分配计算任务给机器，并且监控状态。每一个工作节点上面运行一个叫做Supervisor的进程。Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程worker。每一个工作进程执行一个topology的一个子集；一个运行的topology由运行在很多机器上的很多工作进程worker组成。(一个supervisor里面有多个workder，一个worker是一个JVM。可以配置worker的数量，对应的是conf/storm.yaml中的supervisor.slot的数量）
• Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成。另外，Nimbus进程和Supervisor进程都是快速失败(fail-fast)和无状态的｡所有的状态要么在zookeeper里面, 要么在本地磁盘上。这也就意味着你可以用kill -9来杀死Nimbus和Supervisor进程,然后再重启它们，就好像什么都没有发生过，这个设计使得Storm异常的稳定。
2、 Topology
在Storm中,一个实时应用的计算任务被打包作为Topology发布，这同Hadoop的MapReduce任务相似。但是有一点不同的是:在Hadoop中，MapReduce任务最终会执行完成后结束；而在Storm中，Topology任务一旦提交后永远不会结束，除非你显示去停止任务。计算任务Topology是由不同的Spouts和Bolts，通过数据流（Stream）连接起来的图｡下面是一个Topology的结构示意图：

• Spout：Storm中的消息源,用于为Topology生产消息(数据),一般是从外部数据源(如Message Queue、RDBMS、NoSQL、Realtime Log ）不间断地读取数据并发送给Topology消息(tuple元组)。
• Bolt：Storm中的消息处理者，用于为Topology进行消息的处理，Bolt可以执行过滤，聚合， 查询数据库等操作，而且可以一级一级的进行处理。

3、 分组机制
Stream Grouping定义了一个流在Bolt任务间该如何被切分。这里有Storm提供的6个Stream Grouping类型：
1、 随机分组
随机分发tuple到Bolt的任务，保证每个任务获得相等数量的tuple。

2、 字段分组
根据指定字段分割数据流，并分组。例如，根据“user-id”字段，相同“user-id”的元组总是分发到同一个任务，不同“user-id”的元组可能分发到不同的任务。

3、 全部分组
tuple被复制到bolt的所有任务。这种类型需要谨慎使用。

4、 全局分组
全部流都分配到bolt的同一个任务。明确地说，是分配给ID最小的那个task。

5、 无分组
你不需要关心流是如何分组。目前，无分组等效于随机分组。但最终，Storm将把无分组的Bolts放到Bolts或Spouts订阅它们的同一线程去执行（如果可能）。

6、 直接分组
这是一个特别的分组类型。元组生产者决定tuple由哪个元组处理者任务接收。

7、 通过实现CustomStreamGrouping定义自己的分组模式
4、

六、 storm和Hadoop的架构对比
他们的总体架构相似。

在Hadoop架构中,主从节点分别运行JobTracker和TaskTracker进程,在storm架构中,主从节点分别运行Nimbus和Supervisor进程。在Hadoop架构中,应用程序的名称是Job,Hadoop将一个Job解析为若干Map和Reduce任务,每个Map或Reduce任务都由一个Child进程来运行,该Child进程是由TaskTracker在子节点上产生的子进程。
在Storm架构中,应用程序的名称是Topology,Storm将一个Topology划分为若干个部分,每部分由一个Worker进程来运行,该Worker进程是Supervisor在子节点上产生的子进程,在每个Worker进程中存在着若干Spout和Bolt线程,分别负责Spout和Bolt组件的数据处理过程。
从应用程序的比较中可以看明显地看到Hadoop和Storm架构的主要不同之处｡在Hadoop架构中,应用程序Job代表着这样的作业:输入是确定的,作业可以在有限时间内完成,当作业完成时Job的生命周期走到终点,输出确定的计算结果；而在Storm架构中,Topology代表的并不是确定的作业,而是持续的计算过程，在确定的业务逻辑处理框架下,输入数据源源不断地进入系统，经过流式处理后以较低的延迟产生输出。如果不主动结束这个Topology或者关闭Storm集群,那么数据处理的过程就会持续地进行下去。
通过以上的分析，我们可以看到，storm架构是如何解决Hadoop架构瓶颈的：
Storm的Topology只需初始化一次。在将Topology提交到Storm集群的时候,集群会针对该Topology做一次初始化的工作，此后,在Topology运行过程中,对于输入数据而言,是没有计算框架初始化耗时的,有效避免了计算框架初始化的时间损耗。
Storm使用Netty作为底层的消息队列来传递消息,保证消息能够得到快速的处理，同时Storm采用内存计算模式,无需借助文件存储,直接通过网络直传中间计算结果,避免了组件之间传输数据的大量时间损耗。

七、 Storm的操作模式
本地模式：
在本地模式下，Storm拓扑结构运行在本地计算机的单一JVM进程上。这个模式用于开发、测试以及调试，因为这是观察所有组件如何协同工作的最简单方法。在这种模式下，我们可以调整参数，观察我们的拓扑结构如何在不同的Storm配置环境下运行。要在本地模式下运行，我们要下载Storm开发依赖，以便用来开发并测试我们的拓扑结构。我们创建了第一个Storm工程以后，很快就会明白如何使用本地模式了。
NOTE: 在本地模式下，跟在集群环境运行很像。不过很有必要确认一下所有组件都是线程安全的，因为当把它们部署到远程模式时它们可能会运行在不同的JVM进程甚至不同的物理机上，这个时候它们之间没有直接的通讯或共享内存。
远程模式：
在远程模式下，我们向Storm集群提交拓扑，它通常由许多运行在不同机器上的流程组成。远程模式不会出现调试信息， 因此它也称作生产模式。不过在单一开发机上建立一个Storm集群是一个好主意，可以在部署到生产环境之前，用来确认拓扑在集群环境下没有任何问题。

八、 Storm的使用场景
Storm的流式处理计算模式保证了任务能够只进行一次初始化,就能够持续计算,同时使用了ZeroMQ（Netty）作为底层消息队列,有效地提高了整体架构的数据处理效率,避免了Hadoop的瓶颈。以下是一些适合Storm工作的场景。
1、 流聚合
基于一些tuple字段，将两个或以上的数据流聚合成一个数据流。
2、 批处理
提高效率、性能
3、 BasicBolt

1. 读一个输入tuple2. 根据这个输入tuple发射一个或者多个tuple3. 在execute的方法的最后ack那个输入tuple

遵循这类模式的bolt一般是函数或者是过滤器, 这种模式太常见，storm为这类模式单独封装了一个接口: IbasicBolt

4、 内存内缓存+fileds grouping
在bolt的内存里面缓存一些东西非常常见。缓存在和fields grouping结合起来之后就更有用了。

5、 计算top N
6、 使用TimeCacheMap来高效地保存一个最近被更新的对象的缓存
有时候你想在内存里面保存一些最近活跃的对象，以及那些不再活跃的对象。 TimeCacheMap 是一个非常高效的数据结构，提供了一些callback函数使得我们在对象不再活跃的时候我们可以做一些事情
九、 分布式RPC:CoordinatedBolt和KeyedFairBolt
用storm做分布式RPC应用的时候有两种比较常见的模式:它们被封装在CoordinatedBolt和KeyedFairBolt里面. CoordinatedBolt包装你的bolt,并且确定什么时候你的bolt已经接收到所有的tuple,它主要使用Direct Stream来做这个.
KeyedFairBolt同样包装你的bolt并且保证你的topology同时处理多个DRPC调用，而不是串行地一次只执行一个。