Apache Spark 与 Apache Flink：该如何选择？
内容提要
Databricks 推出 Spark 实时模式（Structured Streaming 的新触发器），无需重写代码即可实现毫秒级延迟，需使用 update 输出模式及 Kafka 或 foreach 接收器。基准测试显示，无状态负载性能与 Flink 持平，有状态聚合和流-静态连接的 p99 延迟更低，最高快 92%。文章认为多数团队应选用 Spark 统一批处理、流、SQL 与机器学习，避免维护第二套引擎；Flink 仅适合超大有状态、复杂事件处理等专用场景。
延伸解读
基准测试的解读边界
文章引用的基准测试由 Databricks 主导，Spark 运行在 Databricks 平台，Flink 则运行在 AWS 托管服务上，且对比的是 Spark 最差一次与 Flink 最好一次的结果。因此“最高快 92%”应视为特定负载模式下的证据，而非通用结论。读者在选型前应基于自身管道进行实测，尤其要关注有状态聚合和流-静态连接等场景。
实时模式的使用约束
Spark 实时模式并非无条件的低延迟方案。它要求使用 update 输出模式，并且数据源和接收器需为 Kafka 或行级 foreach 接收器。有状态算子将在 Apache Spark 4.3 开源版本中提供，目前仅在 Databricks 上普遍可用。这意味着开源用户需等待版本更新，且现有代码若使用其他输出模式或连接器，可能无法直接切换到实时模式。
双引擎的隐性成本
文章强调，选择 Flink 通常意味着在 Spark 之外再维护一套引擎，带来第二套代码库、技能栈和治理规则。团队若用 Spark 做批处理、Flink 做流处理，常需重写相同业务逻辑并调试两者间的偏差。对于同时涉及分析、机器学习特征或湖仓表的流，统一在 Spark 上可避免这种重复与漂移，这是比延迟数字更长期的运维考量。
Flink 的适用场景
文章并未否定 Flink，而是将其定位为专用流处理引擎。当工作负载涉及超大的键控状态、复杂事件处理，或团队已独立运行 Flink 平台处理独立流时，Flink 仍可能是更合适的选择。读者应判断自身是否属于这些少数场景，而非仅因历史延迟差距就引入第二套引擎。
Q&A
Spark 实时模式是什么？它和普通 Structured Streaming 有什么区别？
Spark 实时模式是 Structured Streaming 的一种新触发器，它让流处理以毫秒级端到端延迟连续处理记录，而不是默认的微批处理。你只需为每个查询设置触发器，无需重写代码即可在延迟层级间切换。
Spark 实时模式相比 Flink 在延迟上表现如何？有基准测试吗？
Databricks 的基准测试显示，Spark 实时模式在无状态负载上与 Flink 持平，在有状态聚合和流-静态连接上 p99 延迟更低，最高快 92%。但该测试由 Databricks 运行，Spark 跑在 Databricks 上，Flink 跑在 AWS 托管服务上，比较的是 Spark 最差运行与 Flink 最佳运行，建议自行测试管道。
什么情况下应该选择 Flink 而不是 Spark？
Flink 更适合一小部分专用流处理场景，例如需要超大的键控状态、复杂事件处理（CEP），或者团队已经为独立流任务运行了 Flink 平台。如果流数据还要用于分析、机器学习特征或湖仓表，Spark 可以避免维护第二套引擎。
使用 Spark 实时模式需要满足哪些条件？
实时模式需要 update 输出模式，并从 Kafka 读取或写入 Kafka，或使用行级 foreach 接收器。有状态操作符在开源 Apache Spark 4.3 中提供，在 Databricks 上已正式可用，可运行在经典计算或 Lakeflow Spark 声明式管道中。
维护 Spark 和 Flink 两套引擎有什么代价？
每增加第二套引擎，就多一套代码库、技能组合和治理规则。团队常把同一业务逻辑重写两次，并调试两者之间的偏差。Spark 统一批处理、流、SQL 和机器学习，可以避免这种重复。
有没有公司实际使用 Spark 实时模式的生产案例？
有。MakeMyTrip 考虑过 Flink，但选择 Spark 实时模式以避免第二套引擎，将 P50 延迟降至 44 毫秒，P99 从超过一分钟降至约 500 毫秒。Coinbase 和 DraftKings 也在生产环境运行实时模式。
