大数据升级之路 | Storm理论详解
随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。
Strom技术架构
从宏观上看，Storm 采用典型的 Master–Worker 架构，并通过 ZooKeeper 实现去中心化的高可用设计。整个集群由 Nimbus、Supervisor 和 ZooKeeper 共同协作完成拓扑调度、任务执行与状态协调。
Nimbus 是 Storm 集群的主控节点，主要负责接收用户提交的 Topology、将计算任务分配到各个工作节点，并监控拓扑的运行状态。
Supervisor 运行在各个工作节点上，负责实际执行计算任务。它会根据 Nimbus 下发的调度信息，启动或关闭 Worker 进程，并持续向 ZooKeeper 上报自身状态。Supervisor 本质上是资源与进程管理者，真正的数据处理逻辑并不在 Supervisor 中执行。
ZooKeeper 在 Storm 架构中扮演着关键的协调角色。Storm 并未将集群状态维护在 Nimbus 内存中，而是将拓扑分配、心跳信息、任务状态等关键元数据统一存储在 ZooKeeper 中。这一设计使 Nimbus 和 Supervisor 都可以保持无状态，从而显著提升系统的容错能力和可恢复性。
Storm计算模型
Storm技术架构关注的是计算任务如何被管理，而非计算逻辑本身如何被表达。在此基础上，Storm 进一步通过一套流式计算抽象，将业务处理逻辑组织为持续运行的数据流，这也构成了 Storm 的核心编程模型。
Spout（数据源抽象）：负责数据采集与消息发射
- Bolt（计算与处理单元）：进行数据的过滤、转换等操作，进行状态处理与业务逻辑的实现
- Topology：由Spout和Bolt构成
就像图里面一样想象成水流，data代表的水流从水龙头Spout，流向（Tuple）各个特定的Bolt进行处理，最后流出结果。
可以参考用Storm实现的一个流计算案例（电商销售额实时监控系统）加深理解
大数据升级之路 | 流计算案例（电商销售额实时监控系统）https://blog.csdn.net/plkdthfs12138/article/details/154083021?spm=1001.2014.3001.5501