Flink、Storm、Spark 区别
Flink、Storm、Spark 的核心区别在于流处理模型和计算语义，Flink 是原生流处理，Storm 是纯实时流处理，Spark 则以批处理为基础、流处理为模拟（微批），三者分别对应不同的实时性与吞吐量需求。
一、核心定位与流处理模型
三者的本质差异源于对 “流数据” 的处理方式，直接决定了实时性、吞吐量和适用场景。
| 框架 | 核心定位 | 流处理模型 | 关键特点 |
|---|---|---|---|
| Flink | 原生流处理，兼顾批处理 | 纯流处理（Event-Driven） | 数据以 “事件” 为单位逐个处理，天然支持流处理；批数据可看作 “有界流”，统一处理模型。 |
| Storm | 低延迟实时流处理 | 纯流处理（Event-Driven） | 最早的开源流处理框架，专注低延迟，数据逐个处理，但不原生支持状态管理和 Exactly-Once 语义。 |
| Spark | 批处理为核心，流处理为辅 | 微批处理（Micro-Batch） | 将流数据切分为 “小批量数据”（如 1 秒一批），用批处理引擎计算，本质是 “批处理模拟流处理”。 |
二、关键技术特性对比
技术特性直接影响框架的可靠性、性能和使用复杂度，核心差异集中在语义保障、状态管理和延迟 / 吞吐量上。
| 对比维度 | Flink | Storm | Spark Streaming |
|---|---|---|---|
| 计算语义 | 支持 Exactly-Once（精确一次）、At-Least-Once（至少一次） | 仅支持 At-Least-Once（Trident 扩展可实现 Exactly-Once，但复杂度高） | 支持 Exactly-Once、At-Least-Once |
| 状态管理 | 原生支持（内置键控状态、算子状态），支持状态持久化和增量 checkpoint | 无原生状态管理，需手动实现（如用 Redis 存储状态） | 支持状态管理，依赖 checkpoint 机制，但状态存储需外部系统（如 HDFS） |
| 延迟与吞吐量 | 延迟低（毫秒级），吞吐量高（支持背压） | 延迟极低（微秒级），吞吐量较低（无背压，易过载） | 延迟较高（秒级，取决于批大小），吞吐量高（批处理优化好） |
| 数据窗口 | 支持丰富窗口（时间窗口、计数窗口、会话窗口等），窗口计算灵活 | 窗口需手动实现，无内置支持 | 支持时间窗口和计数窗口，但依赖微批划分，窗口灵活性较低 |
| 容错机制 | 基于 Chandy-Lamport 算法的异步 checkpoint，容错开销小 | 基于 ACK 机制，每个 Tuple 需跟踪，容错开销大 | 基于 RDD 血缘和 checkpoint，容错开销中等 |
三、适用场景差异
选择框架的核心是匹配业务对 “实时性” 和 “吞吐量” 的优先级，三者的适用场景边界清晰：
Flink：适合 “低延迟 + 高吞吐量” 并存的场景
- 典型场景：实时数据大屏、实时风控、实时推荐、日志实时分析。
- 理由：既能满足毫秒级延迟，又能支撑高数据量，且状态管理和语义保障完善，开发效率高。
Storm：适合 “极致低延迟” 优先、数据量较小的场景
- 典型场景：实时监控告警（如服务器 CPU / 内存实时报警）、高频交易行情接收（微秒级响应）。
- 理由：延迟是三者中最低的，但吞吐量有限，且需手动处理状态和语义，开发成本高，目前逐步被 Flink 替代。
Spark Streaming：适合 “吞吐量优先”、可接受秒级延迟的场景
- 典型场景：离线批处理任务的实时化改造（如日活统计改为小时活）、非实时敏感的日志聚合。
- 理由：依托 Spark 批处理生态，与 Spark SQL、MLlib 集成方便，但延迟无法突破秒级，适合对实时性要求不高的场景。