分布式处理与网络计算storm简介Storm 是 Twitt(2)

Spout中最核心的方法是nextTuple，该方法会被Storm线程不断调用、主动从数据源拉取数据，再通过emit方法将数据生成元组（Tuple）发送给之后的Bolt计算

Bolt – 数据流处理组件

拓扑中数据处理均有Bolt完成。对于简单的任务或者数据流转换，单个Bolt可以简单实现；更加复杂场景往往需要多个Bolt分多个步骤完成

一个Bolt可以发送多个数据流（Stream）

可先通过OutputFieldsDeclarer中的declare方法声明定义的不同数据流，发送数据时通过SpoutOutputCollector中的emit方法指定数据流Id（streamId）参数将数据发送出去

Bolt中最核心的方法是execute方法，该方法负责接收到一个元组（Tuple）数据、真正实现核心的业务逻辑

Stream Grouping – 数据流分组（即数据分发策略）

Storm 架构设计

Nimbus、 Supervisor 与 ZooKeeper 关系图

1、主节点 Nimbus

主节点通常运行一个后台程序——Nimbus，用于响应分布在集群中的节点，分配任务和监测故障，这类于 Hadoop 中的 JobTracker。

Nimbus 进程是快速失败（ fail-fast）和无状态的，所有的状态要么在 ZooKeeper 中，要么在本地磁盘上。可以使用 kill -9 来杀死 Nimbus 进程，然后重启即可继续工作。

2、工作节点 Supervisor

工作节点同样会运行一个后台程序——Supervisor，用于收听工作指派并基于要求运行工作进程。每个工作节点都是Topology中一个子集的实现。而Nimbus 和 Supervisor 之间的协调则通过 ZooKeeper 系统。

同 样，Supervisor进程也是快速失败（fail-fast）和无状态的， 所有的状态要么在ZooKeeper中，要么在本地磁盘上，用kill -9来杀死Supervisor进程，然后重启就可以继续工作。

3、协调服务组件 ZooKeeper

ZooKeeper 是完成 Nimbus 和 Supervisor 之间协调的服务。 Storm使用ZooKeeper 协调集群，由于ZooKeeper 并不用于消息传递，所以Storm给ZooKeeper 带来的压力相当低。在大多数情况下，单个节点的 ZooKeeper 集群足够胜任，不过为了确保故障恢复或者部署Storm集群，可能需要更的 ZooKeeper 集群。 Nimbus、 Supervisor 与 ZooKeeper 的关系如图 1 所示。

4、其他核心组件

Storm 的组件不止上面的，还有一些组件也是 Storm 的核心，缺一不可。下面简单介绍Worker 和 Task。

1）具体处理事务进程 Worker：运行具体处理组件逻辑的进程。

2）具体处理线程 Task ：Worker 中的每一个 Spout/Bolt 线程称为一个 Task。在 Storm 0.8之后， Task 不再与物理线程对应，同一个 Spout/Bolt 的 Task 可能会共享一个物理线程，该线程称为 Executor。

Storm与Hadoop、SprakStreaming简单对比

Storm：进程、线程常驻内存运行，数据不进入磁盘，数据通过网络传递。

MapReduce：为TB、PB级别数据设计的批处理计算框架。

Storm：纯流式处理

专门为流式处理设计

数据传输模式更为简单，很多地方也更为高效

并不是不能做批处理，它也可以来做微批处理，来提高吞吐

Spark Streaming：微批处理

将RDD做的很小来用小的批处理来接近流式处理

基于内存和DAG可以把处理任务做的很快

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-62637-2.html