Spark 4.3，把实时这块短板补上了

做了十年批处理的 Spark，这次把实时这条腿真正接上了。

Apache Spark 4.3 正式发布，并随 Databricks Runtime 19 一同可用。这一版最关键的变化只有一句话：将有状态处理（stateful processing）带入 Real-Time Mode。听起来平淡，但对数据基础设施行业来说，这可能是近五年流批一体叙事里分量最重的一次落子——因为它补的，正是 Spark 在实时场景里最后一块明显的短板。

🚀 补课十年：从微批到 Real-Time Mode

Spark 流处理的祖传基因是微批：每隔 N 秒拉一批数据跑一次，简单、稳定、与批处理共享同一套代码，但延迟下限被锁死在秒级，积压时还得和调度器斗智斗勇。Structured Streaming 在 API 层面统一了流批语义，是漂亮的一步；但它底下的执行引擎，长时间里仍是“把流伪装成一系列小批”的思路。真正把低延迟执行路径做进引擎内核，是后来才逐步推进的事——Real-Time Mode 就是这条路线的最新形态。

Spark 4.3 的变化可以概括为：stateful processing 来到 Real-Time Mode。翻译成人话：过去 Real-Time Mode 能处理的，更多是过滤、投影、简单转换这类无状态操作；现在，需要维护中间状态的流计算——聚合、关联、去重——也可以跑在这条低延迟路径上了。

更关键的是这次接入不是“能跑”级别，而是带齐了生产化配套：

• 状态后端：Real-Time Mode 的有状态算子原生接入 RocksDB 状态后端，热状态驻留内存、冷状态落本地磁盘，单作业 TB 级状态不再需要把整个集群内存撑爆；
• 一致性保证：沿用 checkpoint 机制实现故障恢复，配合可重放的消息源与事务写湖仓表（基于 Delta Lake 的 ACID 提交），端到端 exactly-once 语义可以直接跑通，不再需要用户自己在外面糊一层幂等逻辑；
• 乱序处理：事件时间（event-time）与 watermark 语义在低延迟路径上完整可用，迟到数据的窗口更新与撤回逻辑与微批模式保持一致；
• 延迟量级：按 Databricks 公布的基准，典型有状态聚合场景下端到端延迟从微批的秒级压缩至百毫秒级，且状态规模增大时延迟曲线明显比微批积压模式下更平缓。

产业逻辑很清楚：数据平台厂商最怕的不是某个功能缺失，而是“同一份数据要用两套引擎处理”。Spark 补上实时短板后，Databricks 湖仓里“批走 Spark、流走 Flink”的双引擎架构，对很多中等复杂度的场景就失去了必要性。一套引擎、一套 SQL 方言、一套运维体系——这才是流批一体的完整含义。

🧩 有状态计算：流处理真正的硬骨头

流处理的难度，九成都藏在状态里。

一个无状态的流作业，比如“把错误日志过滤出来写进另一张表”，本质上是无记忆的：来一条处理一条，挂了重启接着跑就行。而真实业务要的从来不是这个。风控要“同一张卡 5 分钟内在两个城市刷卡就报警”，运营要“实时统计过去一小时的下单用户数”，推荐要“用户画像表和实时行为流做 join”——这些全都需要在引擎里长期维护一份不断更新的中间状态：计数器、窗口缓存、join 的右侧表快照。

状态一进来，麻烦成倍增长：状态放内存还是放 RocksDB 这类本地存储？作业失败重启后状态怎么恢复？事件乱序到达，窗口什么时候才能关闭并输出最终结果？Real-Time Mode 此前最被诟病的，恰恰是这个能力缺口——低延迟的执行路径有了，但复杂的有状态作业仍然只能退回微批。Spark 4.3 把状态后端、checkpoint 恢复和 watermark 语义一并接入这条路径，等于宣告：低延迟执行从“演示级”走向了“生产级”。

对使用者来说，判断一个流处理引擎是否成熟，可以看这张表：

金句时刻：流处理的门槛从来不在“快”，而在“快着还能算对”。有状态计算进入 Real-Time Mode，意味着 Spark 开始同时回答这两个问题。

⚔️ 竞争格局：Flink 的护城河还剩多宽

把 Spark 4.3 放进竞争版图，才能看清它真正的杀伤力。

过去十年，实时计算赛道的事实格局是：Apache Flink 占据了有状态流处理的技术制高点——真正的事件时间语义、端到端 exactly-once、成熟的状态后端与超大状态管理，让它成为金融风控、实时大屏这类“强一致低延迟”场景的默认答案。Apache Spark 则凭借批处理的生态统治力和 Structured Streaming 的易用性，守住了“轻量实时”的疆域。两条线各守一端，相安多年。

Spark 4.3 改变这个默契的前提：当 Spark 的实时模式能承接有状态作业、且一致性语义对齐 Flink 的核心卖点时，用户面对的不再是非此即彼的选择题，而是“同一个平台内，先试试 Spark 能不能扛住”。对于已经深度绑定 Databricks 湖仓的团队，迁移到 Flink 意味着新集群、新运维栈、新的人才招聘——这个切换成本，就是 Spark 的护城河红利。

需要注意，这张图是趋势判断而非精确刻度。但方向是明确的：Flink 在“技术门槛”轴上依然领先——超大状态的精细管理、复杂事件处理（CEP）仍是它的主场，Spark 4.3 在这两人两个点上尚未给出对位产品；而 Spark 正沿着“商业价值”轴快速上攻，因为它背靠的是整个湖仓生态的商业闭环。

这不是 Flink 的末日。恰恰相反，竞争压力会推动 Flink 在自身最强项上继续加深。但对新项目的技术选型而言，“无脑上 Flink”的时代，正在结束。

引擎层面的变化，最终会传导到平台架构上。至少三个连锁反应值得数据团队负责人现在就开始盘算。

第一，技能栈收敛。过去一个数据平台团队要同时养 Spark 和 Flink 两拨人，招聘、培训、代码审查标准全部双份。流批引擎统一后，团队可以用一套 SQL、一套调优方法论覆盖从百毫秒级到 T+1 的全部计算场景。人力是数据平台最大的隐性成本，这个收敛的账很可观。

第二，湖仓的“实时化”从两张皮变成一张皮。此前不少团队的实时链路是：Flink 算完写进一套专门的结果存储，离线链路再从源头重算一遍对账，两套逻辑、两份数据、天天扯皮。当流和批共享同一引擎、同一套 checkpoint 与事务提交机制、同一张湖仓表，“一份数据、一份逻辑、多种延迟”才真正从 PPT 变成架构图。

第三，Databricks 的平台飞轮转得更快。Real-Time Mode 随 Runtime 19 交付，意味着托管平台的用户零成本拿到新能力。引擎能力 → 平台绑定 → 更多数据沉淀 → 更多场景留在平台内，这个循环对 Snowflake 等竞争者的实时分析叙事，是一次正面回击。

⚠️ 冷静剂：实时不是万能药

最后必须泼一盆冷水。新版本发布不等于你的业务应该立刻实时化。

行业里反复上演的剧本是：老板看到“实时”两个字就立项，团队花半年把 T+1 报表改造成秒级大屏，结果发现业务方看大屏的频率是每天一次。实时化的成本是真实的——状态存储、资源常驻、故障恢复演练、数据质量实时校验，每一项都比批处理贵。实时链路的单位数据计算成本通常是批处理的数倍，而大部分业务决策的真实时效要求，停留在“小时级”就绰绰有余。

给正在评估 Spark 4.3 Real-Time Mode 的团队一张问题-方案对照卡：

技术判断应该是：Spark 4.3 不是让所有批处理变成流处理，而是让“需要流的部分”不必再引入第二套引擎。先把时效分级做清楚，再决定哪些链路值得升级——这是工程判断，也是对预算的尊重。

🎯 结语：撞线之后，看什么

回到开头那句话：Spark 4.3 把有状态计算带入 Real-Time Mode，看似只是一个版本特性，实则是流批一体十年长跑中的关键撞线点。具体拆开看，这一版的分量在三处：RocksDB 状态后端让 TB 级状态在低延迟路径上可运维，checkpoint 加事务提交把端到端 exactly-once 变成默认能力而非工程附加题，百毫秒级的延迟基准则把“实时”的定义从秒级拉低了一个量级。

对三类读者，结论各不相同：

• Databricks 存量用户：Runtime 19 升级即得，建议从聚合类低复杂度作业开始灰度，用湖仓同一份数据做批流对账，验证无误再扩大范围；
• Flink 重度用户：不必恐慌性迁移，但值得重估那些“当初只因 Spark 状态能力不足才选 Flink”的作业——这一前提在 4.3 之后部分失效了；
• 新项目选型者：把“超大状态管理与 CEP 是否为硬需求”作为分水岭——是，Flink 仍是对位答案；否，一套 Spark 引擎覆盖全延迟频谱的方案，首次具备了完整的技术可行性。

可以预见，接下来一年流处理赛道的技术对话会明显升温：Flink 需要回答“生态与易用性”的短板，Spark 需要回答“超大状态与复杂事件处理”的深度。而最终受益的，是那些不再需要为延迟付出双倍架构成本的普通数据团队。下一场值得盯的正面交锋，就在超大状态管理与 CEP 这两个点上。