storm

Storm是Twitter所提出的一个分布式计算系统，最初的目的是为了能将Twitter上一些最新的动态实时推送给用户，但随着它的发展，Twitter的工程师逐渐把Storm进行高层抽象，最终形成这么一个实时计算框架。Storm内部逻辑并不复杂，而且使用起来非常简单，这使得它能更容易的被其他开发者应用到他们自己的产品中去，开发人员可以利用Storm完成一些或简单或复杂的实时计算。而Storm作为这么一个分布式计算框架，它最耀眼的一个特点就是它的容错机制，它可以保证所发送出来的数据都不会丢失，达到记录级的容错，并且在速度上非常优秀，能进行实时计算。。

2.3.1 Storm

Storm具有以下优点：

1.简单的编程模型。Storm提供spout和bolt原语，降低了进行海量数

据实时处理的复杂度。

2.服务化。提供计算模型的抽象，作为一个计算框架，支持热部署，

即时提交或下线Topology。

3.支持多种编程语言。默认支持Clojure、java、Ruby和Python等语言，

但也通过实现一个Storm通信协议就可以增加对其他语言的支持，

语言扩展性好。

4.容错性。Fail-fast系统，通过Zookeeper进行任务协作，nimbus和

supervisor集群不保存任务状态，重启机器结点也不影响。

5.水平扩展。数据处理在线程、进程和机器节间都可以并行。

6.高可靠性的消息处理。Storm保证不会丢失数据，每次所发送出去的

消息都会被处理。如果某个消息的处理超过响应时间，则会从源头

重新发送该消息。

7.快速。因为Storm在底层所使用的数据传输方式是ZeroMQ，其被誉

为是最高性能的消息队列，而且它流式模型设计也保证了任何消息

都能实时响应。

Storm当前存在的问题：

1.目前Storm中nimbus机器只有一个，这就导致如果宕机，则新的Topology

无法提交，这样的话只能靠人工进行重启，不能实现自动化。

2.Storm虽然支持多语言开发，但其核心部分内容是由Clojure语言编写，

虽然它的性能很高，并且具有流程计算的优势，但也使得维护成本增加。

2.3.2 Storm架构

Storm集群主要由两类节点组成，master和worker，它们一般都是一对多

的形式。在master机器上会运行了一个名为“Nimbus”的守护进程，其主要作用是上传代码、布置任务到Zookeeper，将组件实例化后序列化到子节点等。一个名为“Supervisor”的守护进程则被运行在每个子节点上，其作用是到Zookeeper 获取任务，开始并停止worker。Nimbus和Supervisor这两个守护线程都是fail- fast 的，这就使得它们非常稳定，因为它们并不保存任务状态，而它们之间的任务交互都是通过Zookeeper的。ZooKeeper是一个分布式协调系统，一般用作任务的协调管理。

Storm集群结构如下图所示：

图2-7 Storm架构图

Fig.2-7 ConstuctorOf Storm

Nimbus和Supervisor的所有协调工作全部通过Zookeeper集群来完成的。此外，Nimbus守护进程及Supervisor守护进程都是快速失败和无状态的，所有状态保持在Zookeeper或本地磁盘上。这意味着你可以杀死Nimbus或Supervisor，然后再重新启动，它们就像什么都没有发生一样。这使得Storm集群是极其稳定。

2.3.3 Storm内部概念

Storm中有几个概念需要我们了解，包括Topology、Stream、Spout、Bolt、Stream Grouping、Worker等。Topology是一个基于Thrift结构的拓扑图的逻辑节点网络。Stream像数据流一样，是一组无限且连续的数据元组。Spout是外部数据源到内部数据的转换口。Bolt用于处理具体的业务逻辑单元。Worker则是执行具体任务的进程，由Supervisor创建。Stream Grouping则是作为流的导向，描述Bolt接收哪个Spout或者Bolt所发出的Tuple作为输入数据，而Stream Grouping又分为多类：随机分配数据组，按字段分配组，广播组，全局组，无组，自定义导向组。

1.Nimbus：在master结点启动的守护线程，负责任务分配和组件对象

实例化，将任务发送到Zookeeper上等。

2.Supervisor：运行在子结点的守护线程，负责到Zookeeper上接受

nimbus分配的任务，并进行组件对象的初始化，启动和停止worker进程。

3.Worker：运行在子结点，处理具体的业务逻辑的进程。

4.Topology：Storm中运行的一个实时应用程序，因为各个组件间的消

息流动形成逻辑上的一个拓扑结构。

5.Spout：在一个Topology中产生源数据流的组件。通常情况下spout

会从外部数据源中读取数据，然后转换为topology内部的源数据，作为外部到内部的转换口。

Bolt：在一个topology中接受数据然后执行处理的组件。Bolt可以执行具体的业务逻辑，包括过滤，函数操作，合并，写数据库等任何操作。

下图描述了Nimbus，Supervisor，Worker的关系：

图2-8 Storm调度模型

Fig.2-8 Storm Scheduling Model

Storm集群较类似于Hadoop集群，他们有一个关键的不同点是MapReduce Job最终会结束，但一个Topology流程消息永远不会终止（除非你手动杀死）。在Storm中，最核心的抽象体是“流”，一个流是一组无界的元组序列，Storm提供原语来将普通的流用一种分布式且可靠的方式转换成一个新的流，而Storm所提供的最基本的用来进行流转换的原语就是“spouts”和“bolts”。多步流转换是打包成一个“拓扑”提交Storm集群去执行。一个拓扑就是一个流转换图，其中每个节点是一个spout或者bolt。图中的边指出了哪个bolt预定了哪个流。当一个spout 或bolt发送一个tuple到流中时，它会发送这个tuple到每个预定了该流的bolt

上去处理。Storm保证了topology中的每个消息流都被处理，即使机器down掉，正在处理的消息丢失。所以说它有很强的容错能力。

Stream grouping分类：

1.Shuffle Grouping：随机分配数据组，stream中的每个tuple都被随机

分发，使得每个bolt接收到的tuple数量基本相同，这样可以降低集群中每台机器的负载。

2.Fields Grouping：按字段值分配组，Bolt在定义接受的字段值后，可

以接收到具有相同字段值的Tuple，只要字段值不一样，就会被分配到不同的Bolts上做处理。

3.All Grouping：广播分组，基本没有组的概念，对于任何tuple，所有

的Bolts都会收到。

4.Global Grouping：全局组，bolt的中的一个task会接收这个tuple。

5.Non Grouping：无组，并不是没有分组，而是说tuple会被哪些Bolt

收到并不在意。它效果等同于Shuffle grouping，唯一一点不同的是由同一个线程去执行该Bolt和其订阅者。

Direct Grouping：自定义流导向组，该组可以由Tuple的发送者指定该Tuple 被哪个Bolt的哪个task处理。要使用这个分组之前，必须先声明是Direct Stream，只有这样才可以调用这种分组方法，而且该分组在发送Tuple时，emitDirect这个方法是必须，也只能由它来发射。这个Tuple的id可以由消息处理Bolt通过TopologyContext来获得并进行处理。

图2-9描述了Storm中所运行的Topology结构：

图2-9 Storm拓扑结构图

Fig.2-9 Storm Topology

2.3.4 Storm与Hadoop的比较及架构细节

首先，Hadoop掀起整个互联网对于海量数据处理的热潮，我们知道目前非实时计算几乎都基于Hadoop中的MapReduce计算框架，但MapReduce主要针对数据的批处理，一般都是对于累计的数据进行离线处理。而对于特定场景中的某些现实问题，MapReduce并不能很好地解决。

Facebook在Sigmod 11上曾发表过将Hadoop用作进行实时数据处理的论文，通过对Hadoop进行一些实时性改造，但这种解决方案主要有三个缺陷：

1.将数据切割成一定大小的数据分块而且尽量要小并保持高并发，再

将这些数据库送入Map端进行处理，其缺点是如果数据块过大，则单块处理时间会比较长，而且系统开销也会比较大，如果是小的数据块会降低延迟，但每个数据块之间的依赖关系会变得更加复杂，增加数据块之间管理上的开销。一般要根据具体应用和需求来决定数据分块具体的大小，所以这需要结合应用实例。

2.MapReduce在这里需要被改造成管道模型，为了能够进行流式数据

的处理，而不是像批处理一样直接在Reduce端输出，而且Hadoop中的数据交换一般都在磁盘上，考虑到效率的问题，需要在内存中去半持久化中间的计算结果等。这些变动都增加MapReduce框架的复杂性，对系统的整体性能和后期系统维护都不好。

3.开发人员不得不用这样的框架来开发自己的应用程序，这大大降低

具体应用系统的可扩展性。

由上面的论述可得，流式数据处理模式的架构和批处理的完全不同，鱼和熊掌不可兼得，所以对于想搭建一个适合两种不同架构的通用计算平台，其最终结果可能对两种计算都不太理想，而且会变得十分复杂，易用性较差，容易被摒弃。

而Storm，简单来说，它是一个分布式实时计算系统，但它对计算过程做到高度抽象，同样是一个计算框架。相比Hadoop在批处理中，就跟它在实时计算中一样。我们都知道，Hadoop的MapReduce为提供了map，reduce原语，使我们的分布式批处理程序变得非常地简单。同样，Storm也为实时计算提供了一些简洁的原语。我们来看一下Storm的三个应用场景：

1.流数据处理。Storm可以用来处理需要实时写入数据库的流式数据。

不同于通过队列和分布式集群来进行流数据处理的方式，Storm容错性强，可伸缩，且具有极高可靠性和稳定性。

2.持续计算。Storm可以完成持续查询并实时的返回结果。例如在

Twitter中将热门话题传到浏览器，浏览器上就可以实时显示当前所发生的热门话题。

3.分布式RPC。由于Storm的业务处理组件是处在分布式集群中的，

而且处理延迟极低，通过ZeroMQ进行数据传输，所以Storm被作为一个通用的分布式框架来使用。

我们可以通过下表清晰地看到Hadoop和Storm的对比来了解Storm中的基本概念。

图2-10 Storm与Hadoop对比

Fig.2-10 Compare between Storm and Hadoop

2.3.5 ZeroMQ

ZeroMQ是Storm底层节点间用于数据通信的方式，一般来说，ZeroMQ是一个十分简单，且灵活，并具有高性能的网络通讯库，本质上它是消息队列的一种，类似于Apache的RabbitMQ，微软的MSMQ等，相比较这些已经成熟的消息队列机制，ZeroMQ表现非常强大的性能，也是近几年来最受推崇的一种网络传输的方式。

首先，ZeroMQ它最大的一个特点就是简洁，从它的名字中也能看出来。它的简洁来源于它对原始的底层Socket API之上做了很多的封装，省去了开发人员不少麻烦，比如我们在做网络传输处理时，必须要我们自己处理每个数据块之间的边界，对所要传输的数据进行分割，而这又要根据具体的业务逻辑进行相应的处理，因为传统的TCP的Socket传输都是要基于字节流的；而在ZeroMQ中，它以消息为单位进行数据传输，这就意味着它可以保证每次收发到的，都是一个数据块，这能精简了不少代码量。还有就是在进行传统的TCP通讯时，我们通常要自己对一些网络异常进行必要的处理，如连接中断、重连等，这就导致在写代码时所需要考虑的事情变多，即使经验丰富的程序员，也难免会有疏漏。但在ZeroMQ中，它对这些异常处理都会由内部自动解决，不需要我们操心。再比如，当我们想提高通讯的性能时，若使用传统的解决方案，通常要对通讯过程进行异步处理，并利用多线程操作缓冲区，提高并发量之类的事情，而这些事情，在ZeroMQ中都已经进行了封装，在默认情况下，ZeroMQ所有的数据交互都是异

步的，当然你也可以设置阻塞模式。另外就是ZeroMQ所提供的API接口很少，如果接触过socket API的话，上手ZeroMQ非常容易，整体结构非常简洁，简简单单几行代码即完成网络通讯。

其次，ZeroMQ具有很高的灵活性。ZeroMQ和socket一个很大的区别是：传统的socket是端到端的模式，而ZeroMQ可以是多对多的联系，它可以支持多种通讯场景，跨多种传输协议，如线程间通讯，进程间通讯，跨主机通讯。因为ZeroMQ的API设计都是参数式，所有对于不同场景间的转换，我们只需要作微小的改动即可，比如有这样的语句socket.connect (“ ipc: //192.168.1.2: 8080 ”) ，其中的“ ipc: //192.168.1.2: 8080 ”即表示通讯另一端的地址及端口，在ZeroMQ中，约定地址串的格式为transport: //endpoint，这里的transport表示通讯场景的类型，共有4种方式，inproc（线程间通讯），ipc（进程间通讯），tcp（跨主机TCP通讯），pgm（跨主机UDP通讯）。ZeroMQ本身又提供3种模式的数据传输，分别是请求应答模式（Request-Reply），发布订阅模式（Publisher-Subscriber），并行管道模式（Parallel Pipeline）：请求应答模式类似于传统socket的server和client，由client发起请求到server端，server端对该请求进行应答；发布订阅模式中发布端只发送数据到网络中，而订阅端只接受数据，根据自己的需要，去订阅某一个发布端的数据，这里需要说明的一点是如果先启动发布端，订阅端未启动，则所发送出去的数据会丢失，但订阅端一旦启动，可以保证数据的完整性，当不需要订阅时，可以自主断开订阅关系；在并行管道模式中，这个管道是单向的，从push端向pull端推送数据。我们可以通过对这几种模式的组合，实现任何分布式系统数据传输的需求。并且因为ZeroMQ中通讯的基本单元是消息，它只关心数据的大小即Bytes，而不是消息格式，所以我们使用任何喜欢的数据格式，如xml、json等等。

最后是ZeroMQ跨语言的特性。首先我们知道一般会用上网络通讯的系统，多数都是分布式系统，而如果这些系统比较复杂的话，想要用一种语言解决所有问题是比较难的，所以用不同语言的解决方案是经常的事，那么ZeroMQ的跨语言特性就非常重要了。可以这么说，ZeroMQ基本上支持绝大多数语言，常用的编程语言，都能找到其对应的封装库，如Java、C、C++、Python、Javascript、

C#、PHP等等。