Spark实时模式深度解析：微批次与Continuous Processing实战

老实说，当我第一次在技术交流群里看到“Apache Spark Real-Time Mode”这个说法时，心里是有点别扭的。Spark在很多人心中早就被贴上了“微批次、准实时、延迟比不上Flink”的标签，哪怕Structured Streaming已经发布多年，不少团队做实时架构选型时，依然会习惯性地说“实时还是用Flink吧”。但最近这两年，情况开始有了变化：社区不断推进Continuous Processing，官方文档里“实时模式”这个词被反复提及，再加上Spark生态在海量数据处理上的绝对统治力，我开始认真思考一个问题——Spark到底能不能真的打破微批次壁垒，去挑战Flink那个“实时王座”？这篇文章我会把这段时间的研究、实测和踩坑记录完整写出来，内容包括Structured Streaming的执行机制、Continuous Processing的真实边界、两类引擎的对比，以及一套能直接参考的生产选型思路。无论你是正在做技术选型，还是团队已经重度依赖Spark、想尽量不引入新框架，这篇文章应该都能帮上忙。

1. 先看看“实时模式”到底指的是什么

1.1 一个容易被误会的命名

很多入门读者会以为Spark里有一个名为Real-Time Mode的开关，打开之后整个引擎就从批处理切换成“真实时”。实际情况不是这样。Spark没有某个单独的配置项叫real.time.mode，所谓的实时能力，是由一套机制组合出来的：Structured Streaming的连续处理模式、低至秒级甚至更小的微批触发间隔、事件时间处理与Watermark机制、配合Kafka或Delta这类外部系统的端到端链路。

这里要区分三个概念：

• 传统批处理：数据先落盘，到了固定时间点一次性跑完整个作业，结果延迟通常是小时级。
• 微批次流处理：流数据被切分成一个个小批次，每个批次执行一次Spark作业，结果延迟通常在秒级。
• 流式逐条处理：数据一到就处理，没有“攒批”这个环节，结果是毫秒到亚秒级延迟。

Spark的DStream时代属于微批次，但批次间隔只能在秒级附近徘徊，所以给人留下了“准实时”的印象。Structured Streaming出现后，底层依然是微批次引擎，但抽象模型变了，官方也明确支持通过Trigger.ProcessingTime(0)来让系统以“尽可能快”的方式持续调度微批，这个情况下延迟可以降到很低。而我们标题里说的“实时模式”，更多指的是从微批次向连续处理演进这条技术路线。

1.2 三种延迟档位与Spark的位置

我习惯把实时链路的需求分成三档：

从这个表格能看出来，Spark的实时模式并不是要通吃所有场景。它的定位更多是“把流处理做到秒级，并且和批处理、机器学习、SQL生态无缝打通”。如果你需要用Spark解决实时问题，首先要做的不是写代码，而是明确自己的延迟SLA到底够不够“秒级”。如果业务要求的是99%事件在500毫秒内出结果，那Spark实时模式可能就不合适；但如果你的指标是“5秒内能看到结果”，那Spark完全有资格进入候选名单。

我在不少团队里见过一种误区：问需求的时候只说“要实时”，等到量好延迟指标才发现，他们的“实时”其实是“比跑批快就行”，甚至分钟级都能接受。这种情况下引入Flink其实是给自己增加运维负担。Spark生态内解决不了的问题才需要引入新引擎，这是我们做选型时应该守住的原则。

2. Structured Streaming的微批次引擎：延迟不是越低越好

2.1 无界表的抽象

Structured Streaming最打动我的一点是它把流数据抽象成了“无界表”。传统批处理里，数据是一张有界的表，Spark SQL在它上面跑一次查询就有结果；而流处理里，数据是一张不断追加新行的表，查询会持续运行，每来一批新数据就更新一次结果。

这个抽象带来的直接好处是：写流处理代码和写批处理代码的方式高度统一。你不需要学一套全新的API，只需要理解readStream和writeStream这两个入口就够了。

import org.apache.spark.sql._ import org.apache.spark.sql.streaming._ val spark = SparkSession.builder .appName("StreamingExample") .master("local[2]") .getOrCreate() spark.sparkContext.setLogLevel("WARN") val lines = spark.readStream .format("socket") .option("host", "localhost") .option("port", 9999) .load() val words = lines.selectExpr("split(value, ' ')[0] as word") val counts = words.groupBy("word").count() val query = counts.writeStream .outputMode("complete") .format("console") .trigger(Trigger.ProcessingTime("1 second")) .start() query.awaitTermination()

这段代码是Structured Streaming最常见的入门形态：从socket读数据，按单词分组计数，每1秒触发一次微批，把当前全量结果输出到console。注意outputMode("complete")在无状态聚合下需要维护全量状态，如果数据量巨大，内存压力会很明显。很多初学者在这里直接照抄，结果跑一会儿就OOM了，后面我会专门讲状态管理怎么调。

2.2 微批次执行过程与精确一次保证

微批次引擎的执行过程可以拆成四步：

1. 数据源通过Source接口拉取数据，把新到达的数据切分成一个“批次”。
2. 将批次数据交给Spark SQL执行引擎处理，整个过程和普通批处理作业没有本质区别。
3. 处理完成的结果交给Sink写出。
4. 通过WAL（Write-Ahead Log）记录每个批次的offset范围，以及状态数据的变更。

第四步是精确一次语义的关键。Spark不会把一个批次的输出结果直接视为“已成功”，而是先把offset进度和状态变更写入日志，确认持久化之后才提交输出。如果作业中途挂了，重启时会从日志里找到最后一个完成批次的位置，重新读取该批次之后的offset，并恢复对应的状态数据。

我在初学阶段对“精确一次”有过一个误解：以为精确一次是引擎自动保证“一条数据不重不漏”。真实情况是，精确一次需要源、引擎、Sink三方配合。Spark能保证计算过程不重算、状态不丢失，但如果你写Sink时用了“插入”而不是“基于幂等键覆盖”，那么作业恢复时依然可能产生重复下游数据。所以生产环境中，我强烈建议：

• Kafka源配上合理的startingOffsets和group id。
• Sink选择Delta Lake或幂等写入语义。
• 不要依赖console这种无持久化的sink做生产验证。

提示：精确一次语义不是终点，而是起点。你还要思考整个数据链路里的“重复”和“丢失”，才能真正获得可靠的端到端一致性。

2.3 微批次的实际延迟与适用边界

微批次的延迟，理论上等于“调度延迟 + 批次内任务执行时间 + 结果提交时间”。Spark 2.3之后，官方优化了微批次调度路径，让ProcessingTime(0)模式下的最小可行批次间隔可以缩短到100毫秒左右。这个数字对很多实时场景已经够用了，比如秒级大屏、实时指标、异常检测。

但微批次依然存在两个硬伤：

第一，每个批次本质上就是一次Spark作业。批次间隔越短，作业调度和任务序列化的开销占比越大。强行把间隔压到几十毫秒，吞吐会断崖式下降。

第二，一批数据必须等整批处理完才提交。假设你设置了1秒的批次，即使只来了两条数据，你也要等一个批次周期结束后才能看到结果。这个“批次边界等待”就是微批次延迟的下限。

所以我对微批次的结论是：它是一个工程上非常稳妥的“准实时”方案，适合绝大多数场景；而如果你的业务确实需要真正的逐条低延迟，那就得看Spark的连续处理模式了。

3. Continuous Processing：打破微批次壁垒的那一步

3.1 工作原理：从“攒批”到“边读边算”

Continuous Processing是Spark 2.3版本引入的一种实验性处理模式，也是“打破微批次壁垒”这个说法的核心来源。它的工作方式不再是把数据攒到一个批次再执行Spark作业，而是让每个任务持续不断地从源读取记录，一旦读到就立即处理，并通过epoch机制定期向Checkpoint写入进度。

这个改变带来的最大变化是：数据不再需要等待“批次边界”了。每一条记录进入系统后，会被当前正在运行的连续任务立刻处理，结果通过连续Sink输出。从用户视角看，这就是“边读边算”，和Flink的逐条处理在延迟表现上不再有本质差距。

在Structured Streaming代码里，切换到这个模式只需要改trigger：

val query = counts.writeStream .outputMode("append") .format("console") .trigger(Trigger.Continuous("1 second")) .start()

Trigger.Continuous("1 second")里的1秒不是微批间隔，而是epoch间隔，即状态/进度Checkpoint的周期。数据计算本身是连续的，这个参数只影响故障恢复的粒度。

3.2 支持范围与代码示例

连续处理模式目前的支持范围非常有限，这是它最需要被反复强调的事实。官方文档明确说明，Continuous Processing只支持：

• select、map、filter这类无状态操作。
• limit操作（但仅限当前epoch内）。
• 支持Kafka源和Kafka sink，也支持以foreach方式自定义sink。

如果你在连续模式里使用聚合、流式join、Watermark、去重等操作，作业会直接报错。比如我试过把前面的单词计数代码换成连续模式，结果马上抛异常：

org.apache.spark.sql.AnalysisException: Continuous processing does not support aggregations.

这其实很关键。因为绝大多数实时业务的核心就是聚合统计，连续处理却恰恰不支持聚合。也就是说，连续模式现阶段更适合做“无状态的实时中间处理”，比如数据格式转换、字段过滤、简单路由，而不是“实时统计大屏”。从这个角度看，所谓打破微批次壁垒，目前只是“有限打破”，并不是彻底替代微批次引擎。

为了让你直观理解这个边界，我给一个能跑的连续处理示例：从Kafka读JSON数据，过滤出关键字段，再写回另一个Kafka topic。

from pyspark.sql import SparkSession from pyspark.sql.types import StructType, StructField, StringType, LongType from pyspark.sql.functions import col spark = SparkSession.builder \ .appName("ContinuousKafka") \ .getOrCreate() schema = StructType([ StructField("event_id", StringType()), StructField("user_id", StringType()), StructField("amount", LongType()), StructField("ts", LongType()) ]) df = spark.readStream \ .format("kafka") \ .option("kafka.bootstrap.servers", "localhost:9092") \ .option("subscribe", "input-topic") \ .option("startingOffsets", "latest") \ .load() \ .selectExpr("CAST(value AS STRING) as json") \ .select(from_json(col("json"), schema).alias("data")) \ .select("data.event_id", "data.user_id", "data.amount", "data.ts") \ .filter(col("amount") > 100) df.writeStream \ .trigger(continuous="1 second") \ .format("kafka") \ .option("kafka.bootstrap.servers", "localhost:9092") \ .option("topic", "output-topic") \ .option("checkpointLocation", "/tmp/ckpt-continuous") \ .start() \ .awaitTermination()

这段代码在支持范围内可以稳定跑，数据延迟能做到百毫秒级。但哪怕只是加一个groupBy，整个作业就会失败。所以我的建议是：用连续模式前，一定要先统计一下你的作业里有没有无状态算子之外的操作，如果有，请回到微批次。

3.3 为什么至今仍是实验特性

从Spark 2.3至今，连续处理模式已经存在好几个大版本了，但官方始终把它标为实验特性。原因不复杂：

第一，状态支持缺失。没有状态就不能做聚合、不能做流式join、不能做去重，而现实世界里“实时计算”的含金量恰恰集中在这几种能力上。

第二，语义保证还不够细。连续模式下虽然也使用Checkpoint来保存进度，但由于没有批次边界，作业失败的恢复逻辑比微批次复杂得多。官方对故障恢复的细节说明远不如微批次那么完备。

第三，算子覆盖面不够。很多Streaming DataFrame API在连续模式下直接报“不支持”，用户被迫在代码里为不同模式写两套逻辑，这本身就是一种负担。

所以如果你在问“Continuous Processing能不能用于生产”，我的答案是：如果你的作业极其简单、对恢复精度要求不高、并且能接受实验特性带来的不确定性，可以小规模试；否则，目前的主力还是微批次。真正的Streaming 3.0式重构，还要等社区继续推进。

4. Spark实时模式与Flink的正面比较

4.1 处理模型的根本差异

说到实时计算，绕不开Flink。Spark和Flink最本质的差别在于处理模型：Spark默认把流当成一系列小批来处理，Flink从架构上就是逐条事件驱动的。逐条处理意味着数据一到就被算子处理，没有等到“批次触发点”的等待；而微批次天然有一个“攒一批再算”的节奏。

用个生活化的比喻：Spark流处理类似公交车，按时刻表发车，哪怕只有一个人上车也要等发车时间；Flink流处理类似出租车，客人上车就能走。高峰期公交车吞吐量更大，但低峰期体验不如出租车；而你要的是一个永远不会因为“车上人太少”而延迟到达的系统，那么出租车模式在延迟上更有优势。

但注意，吞吐和延迟并不是一个非此即彼的关系。微批次在做“窗口聚合”时，由于一个批次内带着大量数据一起算，CPU利用率和I/O效率往往比逐条处理更高。这也是为什么很多高吞吐的数据入湖场景里，Spark依然表现很好。

4.2 状态、事件时间与恢复语义

实时计算真正难的部分不是处理数据，而是管理状态。所谓状态，就是跨数据累积下来的中间结果，比如分钟级聚合的累加值、窗口内的事件列表、去重时见过的Key集合。

Flink的状态管理是它的招牌能力：原生支持多种状态后端、增量Checkpoint、细粒度的状态TTL、算子级别的状态迁移。Spark Structured Streaming的状态管理则相对年轻，虽然依靠HDFS上的状态存储和WAL也能做到一致性和恢复，但灵活性和状态规模都还有差距。

事件时间处理方面，两者都支持Event Time和Watermark，但Flink对乱序事件的处理、迟到事件的更新语义设计得更早，用户的心智模型也成熟；Spark的Watermark机制在Structured Streaming里够用，但细节上更容易踩坑，比如窗口结果输出的时间可能比你预期的要晚。

这一段的结论很直接：如果你需要大量有状态计算、复杂的事件时间窗口、毫秒级的精确恢复语义，Flink目前依然是更稳的选择。但如果你要的是“数据快点进数仓/数据湖，顺便做点简单的实时聚合”，Spark的微批次完全能胜任。

4.3 选型建议：什么场景用谁

我做一个尽量客观的对照表，你可以拿它当决策参考：

这张表是我个人的经验倾向，不代表Flink在所有方面都优于Spark。做技术选型时，我建议你用这五个问题来过滤：

1. 延迟SLA是毫秒还是秒？毫秒选Flink，秒级先考虑现有Spark。
2. 团队对哪个技术栈更熟悉？选型不是选最先进的，是选最可能被稳定维护下去的。
3. 有没有强状态需求？如复杂窗口、多流join、大量keyed state。
4. 是否要复用批处理和机器学习的代码？
5. 有没有人力维护多套集群？

在一个中型团队里，我见过Spark+Flink混用的情况：离线、实时入湖用Spark；核心实时风控链路用Flink。这未必是最省事的架构，但往往是最贴合业务需求的架构。技术选型最怕的是因为一句“实时就必须用Flink”就盲目上线，结果成本和收益完全不成比例。

5. 实测：用一个模拟流数据项目看真实延迟与踩坑

5.1 实验环境与数据生成

理论说了很多，还是得靠实测说话。我做了一个完全虚构的模拟项目X，目标是从Kafka读取交易流水，实时计算“近1分钟内的交易总额”，并输出到控制台和Delta表。测试数据的生成我直接用了一段简单的Python脚本，每秒钟向Kafka发送约5000条记录，事件时间由生成时的系统时间决定，模拟字段包括交易ID、用户ID、金额、事件时间戳。

环境方面，我用的是本机部署的Spark 3.5版本，Standalone模式，两个Executor，每个Executor分配2核和4GB内存。Kafka运行在同一个局域网里，网络往返理论上不影响结论。整个实验不是要给出一个“标准答案”，而是想看看在这种常规配置下，微批和连续模式的真实表现差距有多大。

5.2 微批次模式实测

我先用最常规的微批次方式写聚合逻辑：

from pyspark.sql import SparkSession from pyspark.sql.functions import window, sum, col spark = SparkSession.builder \ .appName("MicroBatchTest") \ .getOrCreate() df = spark.readStream \ .format("kafka") \ .option("kafka.bootstrap.servers", "localhost:9092") \ .option("subscribe", "trade-topic") \ .option("startingOffsets", "latest") \ .load() \ .selectExpr("CAST(value AS STRING) as json") # 这里省略JSON解析细节 trades = df.selectExpr("event_id", "amount", "event_time") aggregates = trades \ .withWatermark("event_time", "30 seconds") \ .groupBy(window(col("event_time"), "1 minute")) \ .agg(sum("amount").alias("total_amount")) query = aggregates.writeStream \ .outputMode("update") \ .format("console") \ .trigger(ProcessingTime("1 second")) \ .option("truncate", "false") \ .start()

实测结果：当Kafka持续有数据进入时，1秒触发一次的微批次，结束到结束的端到端延迟大约是1.1秒到1.6秒之间。这个延迟包括了生成数据、Kafka传输、Spark拉取、计算、输出、控制台展示的整个链路。考虑到数据是秒级持续的，这个表现其实可接受。

我也试过把trigger改到ProcessingTime("0")，理论上系统会连续调度微批次。实测延迟确实降到了500毫秒到800毫秒，但CPU使用率明显上升，吞吐也打了折扣。这说明微批次在高频调度下会有一部分开销被“空转”消耗掉。

5.3 连续模式实测

连续模式的实测就有意思了。由于它不支持聚合，我单独写了一个无状态过滤作业：从Kafka读数据，过滤金额大于100的订单，输出到Kafka另一个topic。

filtered = df.filter(col("amount") > 100) filtered.writeStream \ .trigger(continuous="1 second") \ .format("kafka") \ .option("kafka.bootstrap.servers", "localhost:9092") \ .option("topic", "filtered-trade-topic") \ .option("checkpointLocation", "/tmp/ckpt-continuous-test") \ .start()

这次延迟明显低了很多：数据从生成到写回Kafka，端到端延迟大致在200毫秒到400毫秒之间。对于“无状态过滤”这种场景，连续处理已经接近Flink的表现了。我还特意在网络异常的场景下做了恢复测试：杀掉作业，再重新启动。由于连续模式是实验特性，恢复点依赖epoch Checkpoint，结果有少量数据被重复消费。这个重复量在可接受范围内，但对于要求严格语义的场景，需要谨慎评估。

5.4 踩坑记录：配置、聚合、恢复

这次实验最花时间的不是写代码，而是排坑。我把几个典型的坑详细列出来，都是网上资料不太会讲的东西。

第一个坑：连续模式加聚合，启动时才报错。由于PySpark里trigger(continuous=...)的参数很宽松，很多错误要到作业真正启动、分析执行计划时才会暴露。我一开始以为把groupBy去掉就没事了，结果忘了withWatermark也不被连续模式支持。排查时要用日志里的Unsupported Operation关键字定位，而不是猜。

第二个坑：checkpoint目录冲突。我连续几次实验用了同一个checkpoint路径，恢复时会读到旧的epoch状态，导致作业启动后长期不消费新数据。这个问题的本质是Spark用Checkpoint标识作业的唯一性，如果逻辑变了但目录没变，会和各种内部状态对不上。解决办法是每个实验都换新目录，或者明确清理历史状态。

第三个坑：Watermark设置太宽导致结果“迟到”。我在微批次聚合时把Watermark设成了“30 seconds”，然后又用ProcessingTime("1 second")触发，结果窗口结束后的结果并不会立刻输出，要等Watermark推进到窗口边界之后才输出。对用户来说，这会给人一种“怎么数据一直不更新”的错觉。所以Watermark不是越大越好，它体现的是你愿意等迟到数据多久。

第四个坑：Kafka的offset提交混乱。如果你把startingOffsets设为earliest且没有保存offset，每次重启都可能从头消费，这时候重复数据会非常多。生产环境应该在Checkpoint里保存offset进度，同时保证group id稳定。

6. 生产化调优心得：让实时模式真正可用

6.1 流量控制与背压

很多团队上线实时作业后遇到的第一问题不是延迟，而是“作业本身被数据流量冲垮”。微批次模式下，每个批次能处理的数据量是有限的，如果源端持续涌入大量数据，而你又没有做限制，批次堆积会导致作业越来越慢，最终完全卡死。

Structured Streaming提供的控制手段有两个：

• maxOffsetsPerTrigger：限制每次触发最多读取的offset数。
• minRatePerPartition/maxRatePerPartition：限制每个分区每秒的读写速率。

我给生产作业设过这样的组合：maxOffsetsPerTrigger先设成一个保守值，比如每秒写入量的两倍，然后观察Consumer Lag，如果积压下降，再逐步调高。这比一次性放开让作业自己扛要稳得多。

6.2 状态后端与Checkpoint

微批次聚合的状态存储默认放在checkpoint路径下，也就是HDFS或对象存储。对状态量大的作业，我建议：

• 把checkpoint目录放到高可用、带冗余的存储上。
• 定期清理过期状态。Spark没有Flink那样细粒度的TTL配置，但你可以通过Watermark老化机制控制状态清理范围。
• Checkpoint写入频率不要太高。如果每批都做全量状态快照，I/O开销会很可观。实际调优时可以把WAL保留时间适当调大，避免频繁做checkpoint合并。

6.3 Sink与资源策略

最后说说Sink。console和foreach是调试工具，生产环境要切换成真正的持久化Sink。我用得最多的是Delta Lake和Kafka。

用Delta做Sink有三个好处：支持ACID、支持幂等写入、可以和Spark批处理共享同一张表。配合foreachBatch，你还可以在每个微批中对Delta表做merge，真正做到“结果实时更新且没有重复”。这里给一段foreachBatch的示意代码：

def write_to_delta(df, epoch_id): df.write \ .format("delta") \ .mode("append") \ .save("/path/to/delta/table") streaming_query = df.writeStream \ .foreachBatch(write_to_delta) \ .outputMode("update") \ .trigger(ProcessingTime("5 seconds")) \ .option("checkpointLocation", "/tmp/ckpt-delta") \ .start()

资源调优方面，有几个经验可以分享。Executor数量根据分区数和吞吐量来定，不要只盯CPU，JVM的GC开销在流处理里也影响很大。数据量大时打开spark.sql.streaming.schemaInference要做好控制，避免每次都重新推断schema。另外，Kafka源尽量让minPartitions匹配Kafka分区数，避免出现部分Executor空闲、部分过载的问题。

最后分享一点个人体会

整套折腾下来，我对Spark实时模式的看法已经从“最多做个准实时”变成了“可以进生产，但要认清场合”。如果你要的是无状态、秒级、高吞吐的流处理管道，同时团队已有Spark基础，那Spark这套方案完全不输Flink，甚至因为能复用批处理生态而更省心。如果你要的是毫秒级、复杂状态、严谨事件时间语义的核心实时决策链路，那Flink依然是更稳妥的选择。选型本质上不是选“谁更好”，而是选“谁更适合你现在的场景和团队”。与其追着“实时王座”的流量话题走，不如把每个方案的边界搞清楚，让工具在它该发力的地方发力。