大数据：Spark 和 Flink 怎么选？微批 vs 真流处理与流批一体架构对比

一、问题的重述：为什么“选型”比“对比”更难

在技术社区里，“Spark 还是 Flink”几乎是一个月经贴。多数对比文章会给出一个看似清晰的结论：低延迟选 Flink，批处理和生态成熟选 Spark。这个结论在 2018 年前后大体成立，但放到 2024—2025 年的语境下，它已经不足以支撑一次严肃的架构决策。原因有三：其一，Spark 的 Structured Streaming 早已不是简单的“微批模拟流”，其连续处理模式（Continuous Processing，实验性）与微批模式并存；其二，Flink 在 1.18 之后持续推进流批一体与自适应调度（Adaptive Scheduler），批处理能力显著增强；其三，湖仓一体（Lakehouse）与存算分离的普及，让“计算引擎”与“存储层”解耦，选型的约束条件发生了变化。

笔者认为，把选型问题还原为“延迟越低越好”是一种典型的工程简化谬误。真实系统里，延迟、状态规模与一致性、总拥有成本三者相互牵制：追求极低延迟往往意味着更频繁的 Checkpoint、更小的批、更高的单位吞吐成本；追求超大状态则要求更稳健的状态后端与更长的恢复时间。因此，本文确立的分析主线是：在“延迟—状态—成本”三角中定位业务可行域，再在可行域内比较引擎的实现代价。这条主线将贯穿后续所有章节，避免陷入“特性罗列”的散漫叙事。

本文评述：经典文献（如 Zaharia 等关于 Spark 的 NSDI 2012 论文、Carbone 等关于 Flink 的 SIGMOD 2015 论文）奠定了两套执行模型的理论基础，但这些工作发表时面对的是完全不同的硬件与业务假设。把它们直接当作今天的选型依据，属于“用十年前的尺子量今天的布”。本文在引用这些经典概念后，均会给出面向当前工程语境的再评估。

1.1 三个必须先回答的业务问题

在打开任何 benchmark 之前，团队应先回答三个问题，它们直接决定三角空间中的可行域位置：

• 端到端延迟的硬约束是多少？是秒级（如分钟级报表）、亚秒级（如风控规则触发），还是毫秒级（如广告竞价）？注意区分“处理延迟”与“端到端延迟”，后者包含数据采集、传输、排队与输出。
• 状态规模与增长曲线如何？是每 key 几百字节的去重状态，还是 TB 级的窗口聚合与 join 状态？状态是否会随时间无限增长？
• 一致性要求是“至少一次”还是“精确一次”？精确一次（Exactly-Once）在不同引擎中的实现代价差异巨大，直接映射到成本维度。

二、执行模型解剖：DAG 微批与原生流图的本质差异

Spark 的核心抽象是弹性分布式数据集（RDD）及其上的有向无环图（DAG）。Structured Streaming 把流式输入视为一张无界表（unbounded table），通过微批（micro-batch）方式不断对新增数据执行增量查询计划。Flink 的核心抽象是带状态的算子组成的流图（stream graph），数据以记录（record）为单位在算子间流动，天然支持逐条处理与事件时间语义。

2.1 微批的“批大小—延迟”曲线

微批模式下，端到端延迟近似等于“批间隔 + 单批处理时间 + 调度开销”。批间隔越小，延迟越低，但调度与任务启动的固定开销占比上升，吞吐下降。这一关系并非线性，而是在某个拐点后急剧恶化。工程上常见的做法是把批间隔设在 100ms—1s 区间，具体取值需通过压测确定拐点。

上表是常见对比，但笔者认为它容易误导：真正决定体验的不是“处理单位”，而是在给定 SLA 下，引擎为维持一致性所付出的额外开销。微批的额外开销集中在调度与任务启动；原生流的额外开销集中在每条记录的序列化、网络传输与状态访问。当单条记录很小、QPS 极高时，后者的固定开销可能反超前者。

2.2 连续处理模式：Spark 的“补课”与边界

Spark 自 2.3 起引入连续处理模式（Continuous Processing），可将端到端延迟降至约 1ms 量级，但其限制明显：仅支持 map-like 操作、不支持聚合与 join、容错语义退化为至少一次。这意味着它适用于“无状态、低延迟、可容忍重复”的管道，而非通用流处理。本文评述：连续处理模式的存在说明 Spark 社区清楚微批的延迟天花板，但其工程取舍也印证了本文主线——降低延迟必然以牺牲状态能力或一致性为代价，没有免费的午餐。

三、时间语义、窗口与乱序处理：正确性的分水岭

流处理里最容易被低估的是“时间”。事件时间（event time）与处理时间（processing time）的混淆，是线上数据错误的头号来源之一。Flink 以水位线（watermark）机制原生支持事件时间与乱序容忍，Spark 的 Structured Streaming 同样提供 watermark，但在微批模型下，水位线的推进以批为粒度，粒度更粗。

3.1 水位线推进粒度的影响

假设业务允许 5 分钟乱序，水位线阈值设为 5 分钟。在 Flink 中，水位线随记录流动持续更新，窗口可在满足条件时尽快触发；在 Spark 微批中，水位线在每个批次结束时计算，窗口触发最多滞后一个批间隔。对于批间隔 1s 的场景，这一差异可忽略；对于批间隔 10s 的场景，则可能影响时效性敏感的下游。笔者认为，选型时应把“水位线推进粒度”作为一个显式评估项，而不是笼统地看“是否支持事件时间”。

3.2 迟到数据的处理策略

• 丢弃：实现最简单，但会低估指标，适合对完整性要求不高的监控场景。
• 侧输出（side output）：Flink 提供侧输出流收集迟到数据，便于离线补偿；Spark 可通过 foreachBatch 自行落盘。
• 允许更新（retraction）：Flink Table API 支持回撤流，适合需要修正结果的场景，但下游需支持 upsert。

工程建议：在 POC 阶段用真实乱序分布的数据回放，统计迟到比例，再决定策略。切勿用均匀分布模拟数据替代真实分布——真实世界的乱序往往呈长尾，这一点在移动端埋点与 IoT 场景尤为明显。

四、状态管理与容错：Checkpoint 背后的工程账本

状态是流处理的心脏，也是成本的主要来源。Flink 基于 Chandy-Lamport 分布式快照算法的异步屏障快照（Asynchronous Barrier Snapshotting，ABS）实现 Checkpoint，能在不停止数据流的情况下做一致性快照。Spark Structured Streaming 则依赖预写日志（WAL）与幂等/事务 sink 实现精确一次语义。

4.1 状态后端的选择逻辑

本文评述：状态后端的选择本质上是在“恢复时间目标（RTO）”与“运行时开销”之间做交换。RocksDB 让状态突破内存限制，但 Checkpoint 上传与恢复的耗时随状态规模线性增长。工程上应把“状态规模年增长率”纳入容量规划，否则一年后可能因恢复超时而被迫重构。

4.2 Checkpoint 间隔的调优经验

Checkpoint 间隔过短会增加运行时开销，过长则拉长故障恢复后的重放窗口。经验法则是：Checkpoint 间隔应显著大于单次 Checkpoint 完成时间（通常建议后者不超过间隔的 50%），同时故障恢复时间（含重放）应满足业务 RTO。对于状态较大且写入对象存储的场景，可启用增量 Checkpoint（RocksDB 增量快照）以降低上传量。

五、流批一体：两条技术路线的收敛与分歧

“流批一体”是近几年最热的关键词之一，但两家实现路径不同。Spark 的思路是“批为流之基”：以 Dataset/DataFrame API 统一批与流，Structured Streaming 把流当作无界表，增量执行同一套查询计划。Flink 的思路是“流为批之基”：批是流的有界特例，DataStream API 与 Table API/SQL 双栈并行，批模式复用流图执行。

5.1 统一 API 的“表面统一”与“语义统一”

统一 API 不等于统一语义。真正的流批一体要求：同一段 SQL 在批与流模式下产生一致结果、共享同一套元数据与 catalog、共享同一套状态与容错机制。Spark 在 API 层面统一度较高，但流模式下的部分算子（如某些聚合）仍有语义限制；Flink 在语义层面更彻底，但批模式的成熟度与生态工具链仍在追赶。笔者认为，评估流批一体不能只看“能否用同一段代码跑两种模式”，而要看边界场景下的行为一致性，例如空批次、迟到数据、状态清理时机。

5.2 湖仓一体下的引擎定位

随着 Iceberg、Hudi、Paimon 等表格式的成熟，计算引擎与存储进一步解耦。Flink 擅长“入湖”（实时写入与增量提交），Spark 擅长“读湖”（大规模批分析）。在典型的湖仓架构中，两者常常共存而非二选一：Flink 负责实时链路与增量 ETL，Spark 负责离线重算与交互式分析。本文评述：“选型”在湖仓语境下正从“二选一”演化为“分工协作”，这是本文主线在架构层面的延伸——三角权衡中的“成本”维度，因存算分离而被重新定义。

六、性能与成本：延迟-状态-成本三角的量化方法

要让选型“经得起科学检验”，必须把三角关系量化。下面给出一套可复用的量化框架，数据来源标注清晰，模拟部分单独说明。

6.1 三个核心指标的定义

• P99 端到端延迟：从事件产生时间戳到结果可查询的时间差，取 99 分位。注意排除采集端时钟漂移。
• 状态恢复时间（RTO）：从故障发生到作业恢复处理的时间，含 Checkpoint 下载、状态加载与重放。
• 单位吞吐成本：每百万条记录的处理成本（含计算、存储、网络），按云厂商按量计费折算。

6.2 一个模拟的量化对比（模拟数据，仅示意方法）

下表为笔者基于公开 benchmark 方法构造的模拟数据，用于演示三角权衡的读法，不代表任何厂商实测结果。真实选型必须以自有数据与负载压测为准。

读法：当延迟硬约束在秒级以上时，Spark 微批在成本维度往往占优；当约束进入百毫秒以内，Flink 的延迟优势开始抵消其成本劣势；当状态达到 TB 级，两者都需要 RocksDB 类后端，成本差异收窄，此时应更多考虑运维成熟度与团队技能栈。

七、算子级调优与反压诊断实战

选型确定后，真正决定线上表现的是调优。以下给出可操作的步骤，适用于两个引擎的共性部分，差异点单独标注。

7.1 反压（Backpressure）诊断五步法

1. 定位瓶颈算子：Flink 可通过 Web UI 的 Backpressure 面板或火焰图定位；Spark 可观察批次处理时间与输入速率是否背离。
2. 判断瓶颈类型：是 CPU 密集（序列化、正则、复杂 UDF）、IO 密集（外部存储写入）还是状态访问密集（大状态随机读）。
3. 检查并行度与分区：数据倾斜常表现为个别 subtask 处理时间远高于均值，需检查 key 分布。
4. 评估 sink 吞吐：下游数据库写入慢是常见反压源，应引入批量写入、连接池与限流。
5. 回归验证：每次只改一个变量，记录 P99 延迟与吞吐变化，避免多变量混淆。

7.2 数据倾斜的工程解法

倾斜是流批共有的顽疾。常见解法包括：加盐打散（对热 key 加随机前缀）、两阶段聚合（局部聚合再全局聚合）、广播小表避免 shuffle join。本文评述：加盐会改变 key 语义，需在下游做二次合并，工程上应优先从数据模型层面消除热点（例如把“按用户 ID 聚合”改为“按用户 ID 分桶聚合”），而非一味在计算层打补丁。

7.3 序列化与 UDF 开销

跨语言 UDF（如 Python UDF）会引入进程间通信与序列化开销，在高 QPS 场景下可能成为瓶颈。建议将热点逻辑下沉为原生算子或用向量化执行（如 Arrow 格式）降低开销。两个引擎均在推进向量化，但成熟度与适用算子范围不同，需按实际算子验证。

八、前沿场景：湖仓一体、存算分离与实时 AI

8.1 实时特征工程与在线推理

推荐与风控系统要求“特征实时计算 + 模型在线推理”。Flink 因低延迟与状态能力，常被用于实时特征管道；Spark 则因与离线特征工程共享代码，适合“批流特征一致性”要求高的场景。笔者认为，特征一致性（training-serving skew）是比引擎延迟更隐蔽的风险，选型时应优先保证离线与在线特征逻辑同源，再谈延迟优化。

8.2 存算分离对选型的影响

对象存储的普及让计算节点可弹性伸缩，但也带来小文件与元数据压力。流式入湖需关注提交间隔与文件合并策略；批处理需关注 listing 开销。这些工程细节往往比“引擎谁更快”更影响总体体验。

8.3 拓展学习资源

• Apache Flink 官方文档与训练课程：https://nightlies.apache.org/flink/flink-docs-stable/
• Apache Spark 官方文档：Structured Streaming 编程指南
• Flink Forward 与 Spark Summit 公开演讲视频（YouTube 官方频道）可作为架构演进的一手材料。
• Iceberg / Paimon 官方文档中的“流式写入”章节，适合理解湖仓一体的工程细节。

九、选型矩阵、POC 步骤与迁移路径

9.1 选型矩阵

9.2 POC 六步法

1. 定义 SLA：明确 P99 延迟、可用性、RTO 与数据完整性指标。
2. 采样真实数据：包含乱序分布、热点 key、空值与大字段，避免用均匀模拟数据。
3. 搭建最小集群：按生产规格的 1/4 搭建，记录资源用量。
4. 跑基准与故障注入：除吞吐延迟外，必须注入节点故障，测量恢复时间。
5. 成本折算：按云计费口径折算单位吞吐成本，纳入状态存储与网络费用。
6. 决策评审：用三角可行域图呈现结果，而非单一分数排名。

9.3 迁移路径建议

若从 Spark 迁往 Flink，建议先迁“无状态或小状态”的实时链路，验证运维与监控体系，再迁大状态作业；若从 Flink 迁往 Spark，优先迁“对延迟不敏感、需与离线共享代码”的作业。迁移过程中保持双跑与结果比对，是控制风险的最低成本手段。

十、结论与展望

回到本文主线：Spark 与 Flink 的选型，本质是在“延迟—状态—成本”三角中定位可行域。微批与真流并非优劣之分，而是不同可行域下的最优解。随着流批一体与湖仓一体的推进，两者的边界正在从“替代”走向“协作”。笔者认为，未来三年内，“引擎组合 + 统一元数据 + 存算分离”将成为主流架构形态，单引擎通吃的叙事会逐渐淡化。对工程团队而言，比选型更重要的是建立可量化的评估体系与可回滚的迁移能力——这才是穿越技术周期的真正护城河。

主要参考文献