2. 计算引擎成本模型：Flink与Spark在流批场景下的资源消耗对比
聊到流批一体，大家最关心的问题往往是：到底用 Flink 还是 Spark？ 我见过不少团队，选型时只看功能特性，上线后才发现资源账单高得吓人。说白了，计算引擎的成本模型才是决定你长期运维开销的关键。
这一章，我就从 CPU、内存、网络三个维度，把 Flink 和 Spark 在流批场景下的资源消耗掰开揉碎讲清楚。嗯，这里先放一张总览图，帮你快速建立全局认知。
2.1 CPU 开销：持续计算 vs 微批调度
CPU 是计算引擎最直接的资源消耗。Flink 和 Spark 在 CPU 使用模式上，有本质区别。
Flink：流水线式持续计算
Flink 的算子之间采用流水线连接。数据从 Source 到 Sink，像水流一样不停流动。每个算子收到一条记录就立即处理，然后传给下游。CPU 几乎一直在工作，没有空闲等待。
关键点：Flink 的 CPU 利用率曲线非常平滑，接近一条直线。在流处理场景下，CPU 利用率通常能维持在 70%-85%。
我个人习惯在 Flink 任务上线前，先跑一个 24 小时的压测。我记得有一次，一个实时 ETL 任务，数据量从 10 万 QPS 涨到 50 万 QPS，CPU 利用率从 40% 涨到 75%，曲线非常线性。这说明 Flink 的 CPU 扩展性很好。
Spark：微批调度与阶段间隙
Spark Streaming 本质上是微批处理。每个批次的数据收集完成后，才会触发计算。批次之间，CPU 会出现短暂的空闲窗口。
你想想看，如果批次间隔是 5 秒，那每 5 秒就有一个调度间隙。虽然这个间隙很短，但在大规模集群上，成千上万个核心的空闲时间累积起来，就是一笔不小的浪费。
| 维度 | Flink | Spark |
|---|---|---|
| 计算模式 | 持续流式 | 微批（Micro-Batch） |
| CPU 利用率 | 高且平稳（70%-85%） | 锯齿状（峰值高，谷值低） |
| 调度开销 | 极低（一次 DAG 构建） | 较高（每批次重新调度） |
| 批处理场景 | 与流处理一致 | 全量计算，CPU 利用率高 |
避坑指南：我曾经遇到一个 Spark Streaming 任务，批次间隔设成了 1 秒。结果调度开销占到了总 CPU 时间的 30% 以上。后来我把批次间隔调到 5 秒，CPU 利用率反而更稳定了。微批不是越小越好，要找到平衡点。
2.2 内存开销：状态管理与统一内存
内存是成本的大头。我见过不少团队，为了省 CPU 钱，结果内存爆了，任务频繁 OOM，运维成本更高。
Flink：状态后端与托管内存
Flink 的内存模型分为三块：堆内内存、堆外内存和托管内存。托管内存主要用于状态后端（如 RocksDB）和网络缓冲。
在流处理中，状态是 Flink 的核心。每个算子都可能维护自己的状态。状态大小直接决定了内存消耗。
- Heap StateBackend：状态存储在 JVM 堆内，适合小状态（GB 级别）。GC 压力大，容易 Full GC。
- RocksDB StateBackend：状态存储在堆外（RocksDB 本地磁盘），适合大状态（TB 级别）。读写有序列化开销。
我建议，如果状态超过 10GB，果断用 RocksDB。虽然磁盘 I/O 会增加一些延迟，但内存稳定性好很多。我曾经有个任务，用 Heap 后端，状态涨到 20GB 后，每 10 分钟一次 Full GC，每次停顿 5 秒。换成 RocksDB 后，GC 几乎消失，任务稳定运行了半年。
Spark：统一内存管理
Spark 的内存分为执行内存和存储内存，两者可以动态抢占。执行内存用于 shuffle、join、aggregation 等操作；存储内存用于缓存 RDD 或 DataFrame。
在流处理场景下，Spark 的状态管理依赖 mapWithState 或 updateStateByKey，状态数据存储在内存中。如果状态过大，会挤占执行内存，导致任务变慢甚至失败。
注意：Spark 的微批模式，每个批次结束后，状态数据需要 checkpoint 到外部存储（如 HDFS）。如果 checkpoint 频率过高，磁盘 I/O 和网络开销会显著增加。
| 内存维度 | Flink | Spark |
|---|---|---|
| 状态存储 | Heap / RocksDB（堆外） | 内存 + 外部存储（HDFS） |
| 大状态支持 | 优秀（RocksDB 可扩展至 TB） | 一般（受限于内存大小） |
| GC 压力 | 低（RocksDB 堆外存储） | 高（大状态时频繁 GC） |
| 内存利用率 | 高（托管内存精细控制） | 中（统一内存动态抢占） |
2.3 网络开销：流式 shuffle vs 批量 shuffle
网络开销往往是被忽视的成本黑洞。数据在节点之间传输，不仅消耗带宽，还会增加延迟。
Flink：流式 shuffle，数据随到随传
Flink 的算子之间通过流式 shuffle 连接。上游算子处理完一条记录，立即通过网络发送给下游算子。数据不需要等待批次边界，延迟极低。
但这里有个代价：网络连接数。Flink 的每个并行子任务之间都会建立 TCP 连接。如果并行度是 100，那每个 TaskManager 可能需要维护上千个连接。连接数多了，网络栈的开销也会增加。
优化建议：在 Flink 中，可以通过 taskmanager.network.memory.min 和 max 控制网络缓冲大小。我一般设置为 64MB 到 128MB，既能保证低延迟，又不会浪费内存。
Spark：批量 shuffle，高吞吐但高延迟
Spark 的 shuffle 是批量的。每个 Stage 结束后，所有数据先写入磁盘，然后通过网络拉取到下一个 Stage。这种方式吞吐量高，但延迟也高。
在流处理中，Spark 的微批模式，每个批次都会触发一次 shuffle。如果批次间隔短，shuffle 频率高，网络开销会急剧上升。
我记得有一次，一个 Spark Streaming 任务，批次间隔 2 秒，shuffle 数据量每天 10TB。网络带宽成了瓶颈，任务经常背压。后来我们优化了数据分区策略，减少了 shuffle 数据量，才把问题解决。
| 网络维度 | Flink | Spark |
|---|---|---|
| shuffle 模式 | 流式（流水线） | 批量（Stage 边界） |
| 延迟 | 毫秒级 | 秒级（取决于批次间隔） |
| 网络连接数 | 高（并行子任务全连接） | 低（按需建立） |
| 带宽利用率 | 平稳 | 突发（批次传输时峰值高） |
2.4 综合成本对比：什么时候选谁？
说了这么多，到底怎么选？我个人的经验是：没有银弹。选型要看你的业务场景和成本敏感度。
核心结论：
- 实时性要求高（秒级延迟）、状态大、事件驱动：选 Flink。虽然内存和网络开销可能略高，但 CPU 利用率更稳定，整体 TCO 更低。
- 批处理为主、偶尔跑流、对延迟不敏感：选 Spark。统一引擎，运维简单，CPU 在批处理场景下利用率很高。
- 混合负载（流批一体）：如果团队 Flink 能力强，建议统一用 Flink；如果 Spark 生态更成熟，可以用 Spark Structured Streaming 做准实时。
最后，我想说一句：成本模型不是静态的。随着数据量增长和业务变化，引擎的资源消耗特征也会变。我建议每季度做一次资源审计，看看 CPU、内存、网络的利用率曲线，及时调整配置。嗯，这才是成本优化的长期之道。