获课：xingkeit.top/5570/

Spark3 实时处理：Streaming + Structured Streaming 从入门到实战

随着数据实时性要求的不断提升，流式处理技术已成为大数据领域的核心能力。Apache Spark 作为统一的大数据处理引擎，其流式计算能力经历了从早期的 Spark Streaming 到 Spark Structured Streaming 的演进。Spark3 在此基础上进一步强化了流式处理的能力，实现了流批一体的统一编程模型。本文将从入门到实战，系统梳理 Spark 实时处理的技术体系。

一、Spark 流式计算的两代技术演进

理解 Spark 的流式处理，首先需要厘清两代技术的核心差异。

Spark Streaming 是 Spark 早期的流式计算组件，其核心思想是“微批次”处理。它将连续的数据流切分为一系列小的批次，每个批次由 Spark 的核心引擎进行批处理。这种设计简化了流式处理的实现——复用批处理的执行引擎和容错机制，但代价是引入了秒级的延迟。DStream（离散化流）作为 Spark Streaming 的抽象，将流式数据表示为连续的 RDD 序列。这种模型简单易懂，但在处理事件时间、状态管理、端到端一致性等方面存在局限。

Structured Streaming 是 Spark 2.0 引入的新一代流式引擎，在 Spark3 中已成为流式处理的主流方案。它的核心理念是将实时数据流视为“无界的表”，流式计算等同于对这张无限表的持续查询。这种模型极大地简化了流式开发的复杂度——开发者可以使用与批处理完全相同的 DataFrame/Dataset API 编写流式应用。Structured Streaming 基于 Spark SQL 引擎，支持事件时间处理、水位线机制、状态存储、以及多种输出模式，真正实现了流批一体。

二、Structured Streaming 核心模型

Structured Streaming 的编程模型建立在几个核心概念之上。

无界表是流式数据的抽象。每个数据流被看作一个不断追加的表格，新到达的数据就是新追加的行。对流的查询操作，本质上是定义在这个无界表上的持续查询。

触发器控制查询执行的时间间隔。默认模式下，每个批次处理完成后立即执行下一个批次，实现尽可能低的延迟。通过 trigger 接口，可以配置固定间隔的微批次，或使用连续处理模式追求毫秒级延迟。

输出模式定义了计算结果如何写入外部存储。追加模式仅将新追加的结果行输出，适用于简单查询；完整模式每次输出完整的计算结果表，适用于聚合场景；更新模式仅输出发生变化的结果行，是目前最常用的模式，在增量聚合场景下平衡了性能与完整性。

水位线是处理乱序数据的关键机制。流式数据往往存在延迟到达的情况，水位线定义了事件时间的处理边界——系统只处理时间戳在水位线之前的数据，超出水位线的晚到数据被丢弃或侧输出。合理设置水位线，需要在数据完整性和处理延迟之间做出权衡。

状态存储用于维护流式计算的中间状态。聚合操作、流-流 Join、去重等操作都需要维护状态。Structured Streaming 使用 RocksDB 作为默认的状态后端，支持海量状态的存储。状态数据会定期进行 checkpoint 写入可靠存储，保证故障恢复能力。

三、实时处理典型场景实战

Spark3 的 Structured Streaming 能够应对多样化的实时处理场景。

实时 ETL 与数据清洗是最基础的应用场景。从 Kafka 消费原始日志，通过 DataFrame 算子进行字段解析、格式转换、脏数据过滤，然后将清洗后的数据写入数据湖或 OLAP 引擎。这种场景下，流式处理扮演了实时数据管道的关键角色。

实时聚合统计是流式处理的核心能力。电商大屏需要统计实时的 GMV、订单量、UV 等指标。使用窗口聚合功能，可以定义滚动窗口、滑动窗口或会话窗口，按时间维度对数据进行聚合。配合水位线机制，即使数据乱序到达，也能保证统计结果的准确性。与批处理不同，流式聚合的结果是持续更新的，可以通过更新模式将增量结果输出到 ClickHouse 或 Redis，供前端实时展示。

流-流 Join 应对更复杂的业务场景。在广告归因分析中，需要将点击流和转化流进行关联。Structured Streaming 支持两个流之间的 Join 操作，可以基于事件时间窗口进行匹配。由于两个流的数据到达顺序不可控，Join 操作需要维护较长时间范围的状态，对存储和计算资源有较高要求。

异常检测与实时报警需要流式处理与机器学习的结合。通过预训练的模型对流式数据进行预测，当检测到异常指标时触发告警。Structured Streaming 支持在流式查询中调用 MLlib 模型或自定义 UDF，实现实时推理能力。

四、Kafka 集成与数据源

Kafka 是 Spark 流式处理最常用的数据源，二者的集成在 Spark3 中更加成熟。

Kafka Source 作为数据源时，可以指定消费的 topic、起始 offset 位置、消费者组配置等。Structured Streaming 会管理 offset 的提交，确保 exactly-once 语义。从 Kafka 读取的数据包含 value、key、topic、partition、offset 等元数据字段，供业务逻辑使用。

offset 管理是端到端一致性的关键。Structured Streaming 将 offset 信息保存在 checkpoint 目录中，故障恢复时从 checkpoint 读取上次提交的 offset，保证数据不重不丢。对于需要自定义 offset 提交逻辑的场景，可以结合 foreachBatch 接口实现精细控制。

多 topic 消费的场景，可以通过正则表达式订阅多个 topic，或使用 DataFrame 的 union 操作合并多个流。不同 topic 的数据格式可能不同，需要在处理逻辑中进行区分和适配。

五、Checkpoint 与容错机制

Structured Streaming 的容错能力基于 checkpoint 机制，这是生产环境稳定运行的核心保障。

Checkpoint 目录保存了查询的执行进度、状态数据、以及 source 和 sink 的 offset 信息。当查询因故障重启时，系统从 checkpoint 恢复状态，从上次 commit 的 offset 继续消费数据。checkpoint 必须存储在可靠的文件系统中，如 HDFS 或 S3。

状态恢复依赖 checkpoint 中的状态快照和增量更新。对于大规模状态，checkpoint 操作本身也会带来性能开销。通过合理配置状态存储后端、调整 checkpoint 间隔、启用增量 checkpoint，可以在容错能力和性能之间找到平衡点。

端到端一致性需要 source、引擎、sink 三方的协同。Structured Streaming 保证引擎内部的 exactly-once 处理，但要实现端到端的 exactly-once，需要 sink 支持幂等写入或事务性写入。Kafka sink 通过支持幂等生产者可以实现精确一次语义；JDBC sink 需要结合事务处理；文件 sink 可以通过分区覆盖机制实现幂等。

六、性能调优与最佳实践

Spark3 的 Structured Streaming 在性能方面引入了多项优化。

微批次大小直接影响延迟和吞吐的平衡。默认的微批次间隔由系统动态调整，但可以通过 maxFilesPerTrigger 或 maxRowsPerTrigger 控制每批次处理的数据量。较小的批次降低延迟，但增加调度开销；较大的批次提升吞吐，但增加单批次的延迟和内存压力。

状态存储优化对于长窗口或大状态场景至关重要。使用 RocksDB 作为状态后端时，需要配置合适的内存大小、调整压缩策略、监控状态存储的读写性能。对于不需要维护状态的场景，使用无状态操作可以大幅降低资源消耗。

数据倾斜在流式处理中同样常见。当某个 key 的数据量远大于其他 key 时，会导致处理节点负载不均。可以通过加盐打散、两阶段聚合、或调整分区策略来解决。

监控与调试是生产环境必不可少的环节。Spark UI 提供了流式查询的专门面板，可以监控输入速率、处理延迟、调度延迟、状态大小等关键指标。通过设置合理的告警阈值，及时发现异常情况。

七、总结与演进方向

Spark3 的 Structured Streaming 凭借统一的编程模型、强大的状态管理、完善的容错机制，已成为实时处理领域的成熟方案。从 Spark Streaming 到 Structured Streaming 的演进，不仅是一次技术升级，更体现了批流一体架构理念的成熟。

随着实时计算需求的持续深化，Structured Streaming 也在不断演进。与 Delta Lake 的结合实现了数据湖上的实时流式读写；与 MLflow 的集成让流式机器学习更加便捷；连续处理模式的完善将进一步降低延迟门槛。

掌握 Spark 流式处理，不仅意味着掌握了一项技术，更意味着建立了实时数据处理的完整思维框架。当你能将批处理和流式处理统一在同一个编程模型下，自如地在实时与离线之间切换时，便真正理解了大数据处理的精髓。