大数据干货系列（七）--Storm总结

Storm总结

 

一、本质

Storm 是一个开源分布式实时计算系统，它可以实时可靠地处理流数据。

 

二、Storm解决了什么问题

1.实时数据分析需求

– 实时报表动态展现

– 数据流量波动状态

– 反馈系统

2.时效性

– 秒级处理完成数据

3.增量式处理

– 数据来一条，处理一条

 

三、Hadoop vs Storm

1.Storm任务没有结束，Hadoop任务执行完结束

2.Storm延时更低，得益于网络直传、内存计算，省去了批处理的收集数据的时间

3.Hadoop使用磁盘作为中间交换的介质，而storm的数据是一直在内存中流转的

4.Storm的吞吐能力不及Hadoop，所以不适合批处理计算模型

 

三、Storm的基本概念

为了理解Storm的一些基本概念，我们可以拿Hadoop1.0来做对比。就像直梯和扶梯都是运送乘客，但他们有各自对应的结构、运行方式等，所以会采用不同的命名加以区分。知道了它们对应内在的层级关系，有助于理解Storm中的新概念。

但这些概念该怎么系统地翻译呢？因为网上也找不到合理的中文翻译，我就尝试着自己解释一波，脑洞有点大，各位可以参考一下，当然也欢迎探讨，以下：

Nimbus(翻译了一下，有神像的光轮的意思)

类似Hadoop1.0里的JobTracker进程，负责管理资源，在集群里面分发代码，分配计算任务给Supervisor，并且监控状态。

Supervisor(有导师的意思，引申出主教、牧师)
    类似Hadoop1.0里的TaskTracker进程，启动和停止属于自己管理的worker进程（每一个工作进程执行一个Topology的一个子集，一个Topology由运行在很多机器上的很多worker工作进程组成）

• Nimbus和Supervisor之间的所有协调工作都是通过Zookeeper集群完成

• Nimbus进程和Supervisor进程都是快速失败（fail-fast），即可以用kill -9来杀死Nimbus和Supervisor进程，然后再重启它们，就好像什么都没有发生过（联想到耶稣的复活）。这个设计使得Storm异常的稳定。

• Nimbus进程和Supervisor进程都是无状态的。所有状态要么在Zookeeper上，要么在磁盘上

Worker(那我们不妨理解为信徒)

运行具体处理Topology（传教的整个活动，下图的灰色部分）的进程，一个Topology可能会在一个或者多个Worker里面执行，每个Worker执行整个且仅此一个Topology的一部分（一个信徒不会信仰、传播两种宗教）。

Task(教徒的行为)

每个Spout/Bolt（统称为Component）会以多个任务(Task)的形式在集群上运行。每个任务对应一个执行线程，可以在调用 TopologyBuilder的setSpout和setBolt函数时设置每个Spout和Bolt的并发数。

Spout(有滔滔不绝的意思)

就像牧师带领进行祷告、布道一样，表示不断有信息（Tuple，图中黄色的方块）从spout传出来。

Bolt(筛选、脱口说出)

就像信徒聆听牧师的布道，同时也会像其他人传播这些福音，Component之间分组的方式称为Stream Grouping，如下：

最后我们再来理解抽象的Stream和Topology:

Stream(流)

是 Storm 中的核心抽象。一个流由无限的元组（Tuple）序列组成，这些元组会被分布式并行地创建和处理。

Topology(拓扑)

一个实时处理程序的逻辑。一个拓扑跟一个MapReduce的任务(job)是类似的。主要区别是 MapReduce 任务最终会结束，而拓扑会一直运行（直到你杀死它)。一个拓扑是一个通过流分组(Stream Grouping)把Spout和Bolt连接到一起的拓扑结构。一个拓扑就是一个复杂的多阶段的流计算。

 

四、Storm的容错设计

1.架构容错

Nimbus和Supervisor进程被设计成快速失败(fail fast)的(当遇到异常的情况，进程就会挂掉)并且是无状态的(状态都保存在Zookeeper或者在磁盘上)。最重要的是，worker进程不会因为Nimbus或者Supervisor挂掉而受影响。这跟Hadoop是不一样的，当JobTracker挂掉，所有的任务都会没了。

1) 当 Nimbus 挂掉会怎样？

如果Nimbus是以推荐的方式处于进程监管(例如通过supervisord)之下，那它会被重启，不会有任何影响。

如果不是以推荐的方式处于监管下，那么已经存在的拓扑可以继续正常运行，但是不能提交新拓扑，正在运行的worker进程仍然可以继续工作。而且当worker挂掉，supervisor会一直重启 worker。失败的任务不会被分配到其他机器(是Nimbus的职责)上了

2) 当一个Supervisor挂掉会怎样？

如果Supervisor是以推荐的方式处于进程监管(例如通过(supervisord)[supervisord.org/])之下，那它会被重启，不会有任何影响

如果不是以推荐的方式处于监管下，分配到这台机器的所有任务(task)会超时，Nimbus 会把这

些任务(task)重新分配给其他机器。

3) 当一个worker挂掉会怎么样？

当一个worker挂掉，supervisor会重启它。如果启动一直失败那么此时worker也就不能和 Nimbus保持心跳了，Nimbus会重新分配worker到其他机器。

4) Nimbus 存在单点问题吗？

如果Nimbus节点挂掉，worker进程仍然可以继续工作。而且当worker挂掉，supervisor会一直重启 worker。但是，没有了Nimbus，当需要的时候(如果worker机器挂掉了)，worker就不能被重新分配到其他机器了。

所以答案是，Nimbus 在“某种程度”上属于单点故障的。在实际中，这种情况没什么大不了的，因为当 Nimbus 进程挂掉，不会有灾难性的事情发生。

 

2.数据容错

    Storm中的每个Topology中都包含有一个Acker组件，用于跟踪每一个spout发出的tuple树，一个tuple树完成时，发送消息给tuple的创造者。如果在用户设置的最大超时时间（timetout可以通过Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS来指定）内这些Tuple没有被完全处理，那么Acker会告诉Spout该消息处理失败，相反则会告知Spout该消息处理成功,它会分别调用Spout中的ack和fail方法。 

以上.

如果觉得本文对你有帮助，可以点个赞表示支持呗！

如果有任何意见和建议，也欢迎再下方留言~

---

 

关注这个公众号，每天给你推送三道大数据面试题~

点击这里查看往期精彩内容：

每日三问（1222）

每日三问（1228）

数据挖掘干货总结（三）--分类算法