Storm - 核心原理、执行流程、运行架构详解

作者：hangge | 2025-02-07 10:56

一、基本介绍

1，什么是 Storm？

（1）Storm 是由 Twitter 开源的分布式实时数据计算引擎，从 0.9.1 版本开始归于 Apache 社区。Storm 可以称得上是大数据行业的第一代实时数据计算引擎。

（2）Storm 能实现高频数据和大规模数据的实时计算。对比 Hadoop 中 MapReduce 的离线计算，Storm 是一个实时的、分布式的、具备高容错的计算系统。

（3）Storm 的使用场景非常广泛，比如实时分析、在线机器学习、分布式 RPC、实时 ETL 等。Storm 非常高效，官网资料显示 Storm 的一个节点每秒钟能够处理 100 万个 100 byte 的消息（IntelE5645@2.4Ghz 的 CPU、24GB 的内存）。Storm 还具有良好的可扩展性和容错性，以及保证数据可以至少被处理一次等特性。

2，Storm 的不足

不支持 ON YARN 模式：直到现在，Storm 2.x 版本依然不支持 ON YARN 模式，这导致 Storm 过于独立。要使用 Storm，则必须搭建独立的 Storm 集群，这会导致服务器资源成本和运维成本的增加，也会导致运维难度的增加。
只支持实时数据计算：Storm 没有自己的生态圈，只支持实时计算，所以它的发展受限。从 2017 年往后，使用 Storm 的公司变得越来越少了。
没有提供高级 API：Storm 提供的 API 都是基础 API，使用起来比较复杂，常见的过滤、拆分这些功能也都需要程序员自己手工实现。

二、原理分析

1，核心组件

（1）Storm 中包含以下两个核心组件。

Spout：数据源，是数据的生产者。它负责从外部（例如 Kafka）读取数据，并将读取的数据发送给 Bolt 组件。
Bolt：数据处理，所有的数据处理逻辑都被封装到 Bolt 中。它负责处理接收到的数据流并产生新的输出数据流，可以执行的数据库过滤、聚合和查询等操作。

（2）Spout 和 Bolt 可以组装成 Topology，组装成 Topology 后才可以被提交到 Storm 集群中运行。Topology 是用于封装 Storm 实时计算程序的拓扑，类似于将 MapReduce 中的 Map 和 Reduce 阶段组装成一个 Job 的过程。

（3）Topology 中的 Spout 和 Bolt 都可以有一个或者多个。这意味着，在一个 Topology 中可能会同时存在多个 Spout 和多个 Bolt。一个 Topology 中需要用到多个 Spout 组件和多个 Bolt 组件通常有如下情况：

如果一个实时数据计算任务的数据源有多个，那么就需要使用多个 Spout 组件，每个 Spout 组件对接一个数据源。
如果一个实时数据计算任务的计算逻辑比较复杂，那么就需要使用多个 Bolt 组件，每个 Bolt 组件负责处理一部分业务逻辑（因为每个 Bolt 都可以并行执行，这样可以提高复杂计算逻辑的计算性能）。

2，核心设计思想

（1）Storm 计算引擎的核心设计思想是：

将实时产生的一条条数据认为是一个无界的数据流，通过内部的 Spout 组件源源不断地产生数据流并发送出去，后面通过 Bolt 组件对接收到的数据流进行处理。
Bolt 组件可以有多个，每个 Bolt 组件都是一个独立的计算单元。
把所有的 Spout 组件和 Bolt 组件组装成一个 Topology，这样就可以把整个实时数据处理流程串起来了。

（2）Storm 中的数据流被称为 Stream。Stream 是由一个个连续不断的 Tuple 组成的。Tuple 是 Storm 中数据传输的基本单位，代表的是一条数据。

（3）下面通过一个火车的案例详细分析一下 Storm 的核心设计思想：

Tuple：相当于火车中的一节车厢。Tuple 中存储数据（相当于车厢中的乘客）。
Stream：相当于一列火车，一列火车的车厢个数是有限的，但是 Stream 中的 Tuple 个数却是无限的，会一直源源不断地产生。
Spout：相当于火车的始发站，对应的是 Stream 的源头。
Bolt：相当于火车临时停靠的中间站点，在每个中间站点都会有一些乘客上车或者下车（相当于对 Tuple 中的数据进行计算）。最后一个 Bolt 是终点站，相当于对 Tuple 中的数据进行的最后计算，计算之后的最终结果就可以被输出到第三方存储介质中了。
Topology：相当于火车的运行规划图。将火车的始发站、中间站点和终点站规划好以后，火车就可以按计划运行了。

3，Storm 与 MapReduce 对比

为了更加清晰地理解 Storm 中实时数据计算的特性，在这里将其和 MapReduce 离线数据计算引擎做一个对比：

数据来源：MapReduce 处理的是 HDFS 上 TB 级别的离线数据，Storm 处理的是实时新增的某一条数据。
处理过程：MapReduce 分为 Map 阶段和 Reduce 阶段。Storm 是用户自定义的处理流程，流程中可以包含多个步骤，这些步骤可以是数据源（Spout）或数据处理（Bolt）。
是否结束：MapReduce 最后肯定是要结束的。Storm 是不会结束的，程序执行到最后就阻塞在那，直到有新数据进入时再从头开始。
处理速度：MapReduce 以处理 HDFS 上 TB 级别数据为目的，处理速度相对较慢。Storm 只需要处理新增的某一条数据即可，处理速度很快。
适用场景：MapReduce 是在处理批量离线数据时使用的，不讲究时效性。Storm 是在处理某一条新增数据时使用的，要讲时效性。

三、架构分析

1，集群架构

（1）要运行开发好的 Topology 任务，则需要单独部署 Storm 集群，因为 Storm 不支持 ON YARN 模式。Storm 集群中有以下两种类型的节点：

Master 节点：主节点，支持一个或者多个，可以实现高可用（HA）。Master 节点上会运行一个 Nimbus 进程，它类似于 Hadoop 集群中的 ResourceManager。Nimbus 进程负责在集群范围内分发代码，以及为 Worker 节点分配任务和故障监测。
Worker 节点：从节点，支持多个。Worker 节点上会运行一个 Supervisor 进程，它类似于 Hadoop 集群中的 NodeManager。Supervisor 负责监听分配给它所在机器的任务，基于 Nimbus 分配给它的任务来决定启动或停止工作者进程（Worker Process）。

（2）Storm 集群的运行需要依赖 Zookeeper 集群，Zookeeper 集群负责多个 Nimbus 进程和多个 Supervisor 进程之间的所有协调工作。

Nimbus 进程和 Supervisor 进程都是快速失败（Fail-Fast）和无状态的，所有状态维持在 Zookeeper 中。这也就意味着，可以使用 kill 命令“杀掉” Nimbus 进程和 Supervisor 进程，重启后这两个进程将恢复状态并继续工作，就像什么也没发生一样。
这种架构设计使得 Storm 极其稳定，因为 Master 节点并没有直接和 Worker 节点进行通信，而是借助 Zookeeper 和 Worker 节点进行通信，这样可以分离 Master 节点和 Worker 节点之间的依赖，将状态信息存放在 Zookeeper 集群内以快速回复任何失败的一方，如下图所示。

（3）Worker Process 和 Storm 集群的关系如下图所示：

2，Worker Process 内部架构

当 Topology 被任务提交到 Storm 集群后，集群中的 Master 节点中的 Nimbus 进程会对 Topology 进行拆分，将拆分出来的子任务分发到多个 Worker 节点中，Worker 节点中的 Supervisor 进程监听到分配给它的任务后会启动一些工作者进程（Worker Process）。
Strom 集群中的每个 Worker 节点可以启动 1 个或者多个 Worker Process，Worker Process 其实就是一个 Java 进程。假设 Storm 集群中的某一个 Worker 节点有 4 个 CPU，那么建议这个 Worker 节点最多启动 4 个 Worker Process，Worker Process 会执行 Topology 中的子任务。
在一个 Worker Process 中会运行一个或者多个 Executor（线程），每个 Executor 中会运行同一个组件（Spout 或者 Bolt）的一个或者多个 Task（任务）。
Task 是最终完成数据处理的实体单元，它其实执行的就是 Spout 组件或者 Bolt 组件中的核心代码