夏哉ke: bcwit.top/743

在实时大数据处理领域，Spark Streaming曾经是先行者，但受限于其“微批处理”的本质，在延迟敏感的场景下逐渐被Flink等纯流引擎挑战。然而，Spark3的到来彻底改变了这一格局。

Spark3实时处理的核心突破在于：

• 结构化流媒体（Structured Streaming） 的成熟，让流处理拥有了与批处理同等的易用性和正确性

• 连续处理（Continuous Processing） 模式的引入，将延迟从秒级压入毫秒级

• 与Delta Lake的深度融合，实现了流批一体的数据湖架构

• 自适应查询执行（AQE） 和动态分区剪裁等优化，让实时作业的稳定性大幅提升

Spark3实时处理的价值，不在于“取代谁”，而在于让技术团队可以用一套引擎同时覆盖批处理、微批处理、流处理三大场景，大幅降低技术栈的复杂度和运维成本。

本文将系统拆解Spark3实时处理的两套企业级方案——微批处理模式与连续处理模式，深入它们的原理、适用场景、优化技巧和生产实践，助你在实时大数据领域实现真正的专业掌握。

第一部分：战略定位——Spark3在实时处理版图中的位置

一、实时处理的“三座大山”

任何实时处理系统都必须回答三个核心问题：

不同的业务场景，对这三者的要求截然不同：

• 实时风控：延迟敏感（毫秒级），一致性要求极高

• 实时大屏：延迟可接受秒级，吞吐量大

• 数据入湖：延迟分钟级即可，但要求一致性

Spark3的独特价值在于：它用一套API，提供了覆盖以上所有场景的能力——开发者可以根据业务需求，在微批处理和连续处理之间自由选择，甚至混合使用。

二、Spark3实时处理的三大进化

1. 结构化流媒体的成熟
Structured Streaming 自Spark 2.0引入，在Spark3中已经成为稳定、成熟的生产级引擎。它将流数据视为“无限表”，用声明式API（DataFrame/Dataset）统一批处理和流处理的编程模型，大幅降低了开发门槛。

2. 连续处理的落地
Spark 2.3引入连续处理模式作为实验特性，在Spark3中已趋成熟。它放弃了微批处理的“定时触发”机制，采用“长时运行算子”模式，实现了毫秒级延迟，让Spark在低延迟场景下具备了与Flink正面竞争的能力。

3. 流批一体的数据湖架构
通过与Delta Lake的深度集成，Spark3实现了真正的流批一体。同一套代码，既可以跑批处理，也可以跑流处理；同一份数据，既可以批量写入，也可以流式读取。这彻底解决了传统Lambda架构中批流两套代码、两份数据的维护难题。

第二部分：核心引擎——结构化流媒体的设计哲学

三、无限表模型：将流视为表

Structured Streaming最核心的设计理念是：将输入数据流视为一张不断增长的“无限表”（Unbounded Table）。

• 每一批新数据，就是向这张表中追加的新行

• 对流数据的处理，就是对这张无限表执行查询

• 输出结果，就是每次查询后的结果集

这种模型带来了三个巨大的好处：

1. 统一编程模型：批处理和流处理的代码几乎一致，开发者无需学习两套API

2. 声明式优化：Catalyst优化器可以对流查询进行与批查询同级别的优化

3. 正确性保障：端到端的精确一次语义，由引擎层面保证

四、输出模式：结果如何写入

结构化流媒体定义了三种输出模式，对应不同的业务场景：

1. Append Mode（追加模式）

• 只输出新追加的行

• 适用于无状态聚合（如过滤、映射）或水印限制下的聚合

• 保证每条数据只输出一次

2. Complete Mode（完整模式）

• 每次触发都输出整个结果表

• 适用于有状态聚合，且结果集不大

• 注意：随着时间推移，输出量会线性增长

3. Update Mode（更新模式）

• 只输出本次触发中被更新的行

• 兼顾了完整性和效率

• 是大多数聚合场景的首选

五、事件时间与水印：处理乱序数据

流处理中最大的挑战之一，就是数据的乱序到达。Spark3通过事件时间（Event Time） 和水印（Watermark） 机制优雅地解决了这一问题。

事件时间：数据本身携带的时间戳，而非数据到达系统的时间。基于事件时间计算，可以保证即使数据乱序，最终结果依然正确。

水印：引擎对事件时间进展的猜测。水印的推进逻辑是：

• 引擎追踪已处理数据的最大事件时间

• 水印 = 最大事件时间 - 允许的延迟阈值

• 只有事件时间大于水印的数据才会被处理

核心权衡：水印阈值设置过小，会丢弃迟到的数据；设置过大，会延迟结果产出。需要根据业务对准确性和延迟的要求进行调优。

第三部分：方案一——微批处理模式深度拆解

六、微批处理的原理与架构

微批处理是Spark Streaming的传统模式，也是Structured Streaming的默认模式。其核心原理是：

1. 数据积累：将流数据按时间窗口（如1秒）切分成微批

2. 批量计算：每个微批作为一个独立的Spark作业执行

3. 结果输出：将计算结果写入目标存储

架构特点：

• 每个微批触发一次作业提交

• 作业之间有调度开销（通常数百毫秒）

• 端到端延迟通常在秒级（1-5秒）

适用场景：

• 实时大屏（秒级刷新可接受）

• 实时ETL（分钟级延迟）

• 数据入湖（可容忍秒级延迟）

• 复杂聚合（需要完整Spark计算能力）

七、微批处理的优化技巧

1. 触发间隔调优
trigger(Trigger.ProcessingTime("2 seconds")) 控制了微批的频率。间隔越短，延迟越低，但调度开销越大；间隔越长，吞吐越高，但延迟增加。经验值：1-5秒是延迟与吞吐的平衡区间。

2. 微批大小控制
每个微批处理的数据量，受触发间隔和上游数据速率共同影响。可以通过 spark.sql.streaming.numRecentProgress 监控微批的处理时间。如果处理时间接近触发间隔，说明系统接近瓶颈，需要扩容或优化。

3. 状态存储优化
有状态聚合（如group by）需要维护状态。默认情况下，状态存储在内存中，但会定期checkpoint到HDFS。对于大状态场景，可以考虑使用RocksDB作为状态后端，降低内存压力。

4. 分区数调优
微批作业的并行度由输入数据的分区数决定。如果Kafka分区数过少，可以通过 repartition() 增加分区，提高并行度。注意：重分区会引入shuffle开销。

八、微批处理的一致性保障

Spark3的微批处理模式提供了端到端的精确一次（Exactly-Once）语义，其保障机制分为三层：

1. 源端重放能力

• Kafka等Source需要支持从指定offset重新消费

• Structured Streaming会记录每个微批消费的offset范围

2. 引擎内一致性

• 每个微批是一个完整的Spark作业，要么全部成功，要么全部失败

• Checkpoint机制记录作业执行状态，失败后可重试

3. 目标端幂等性

• 需要目标存储支持幂等写入（如Kafka的幂等生产者、Delta Lake的事务）

• 如果目标端不支持幂等，至少需要保证“至少一次”语义

第四部分：方案二——连续处理模式深度拆解

九、连续处理的原理与架构

连续处理（Continuous Processing）是Spark3中真正意义上的流处理模式，其核心原理是：

1. 长时运行算子：算子持续运行，而非每批重新启动

2. 逐条处理：数据到达后立即处理，无需等待批次边界

3. 异步Checkpoint：状态检查点与数据处理异步进行，不阻塞数据流

架构特点：

• 算子常驻内存，无调度开销

• 端到端延迟可达毫秒级（通常10-100ms）

• 吞吐略低于微批模式（受单算子吞吐限制）

适用场景：

• 实时风控（毫秒级响应要求）

• 实时告警（低延迟要求）

• 物联网数据处理（设备数据实时处理）

• 在线机器学习特征计算

十、连续处理与微批处理的对比

关键选择：连续处理的延迟优势明显，但当前版本的一致性保障尚不如微批处理成熟（部分场景只能做到At-Least-Once）。对于资金交易等强一致场景，微批处理仍是首选；对于实时推荐、风控预警等对延迟敏感但对数据重复有一定容忍度的场景，连续处理更具优势。

十一、连续处理的优化技巧

1. 算子链优化
连续处理模式下，算子链（operator chain）的设计直接影响延迟。将计算密集型的算子合并，减少数据在算子间的序列化开销。

2. 并行度配置
连续处理的并行度由 spark.sql.streaming.continuous.numPartitions 控制。并行度过低会成为瓶颈，过高会增加调度开销。建议根据数据量和下游能力动态调整。

3. 资源预留
连续处理的算子常驻内存，需要预留足够的资源。在YARN或K8s部署时，确保TaskManager不会因资源不足被驱逐。

4. 监控与告警
连续处理缺少微批模式的“批次边界”，监控难度更大。需要关注：

• 处理延迟：数据从进入系统到输出的时间

• 背压指标：算子是否因下游慢而积压

• Checkpoint延迟：异步快照的耗时

第五部分：两套方案的融合实践——流批一体架构

十二、Lambda架构的痛点

传统的Lambda架构包含两条链路：

• 批处理层：用Spark批处理定期计算，保证准确性

• 流处理层：用Spark Streaming或Flink实时计算，保证低延迟

这套架构的问题显而易见：

• 两套代码，维护成本高

• 两套结果，需要额外的合并逻辑

• 数据冗余，存储成本翻倍

十三、Spark3的流批一体方案

Spark3 + Delta Lake 构建的流批一体架构，彻底解决了上述问题：

1. 统一编程模型
批处理和流处理使用相同的DataFrame API，甚至同一份代码可以同时用于批处理和流处理。

2. 统一存储
Delta Lake作为数据湖存储，同时支持：

• 批写入：定期批量写入

• 流写入：持续追加写入

• 流读取：作为Source供下游流作业消费

• 批读取：作为Table供分析查询

3. 统一运维
一套集群、一套监控、一套部署流程，运维复杂度大幅降低。

十四、流批一体的架构模式

模式一：ETL流批一体

• 源数据写入Delta Lake（批/流皆可）

• Spark流作业实时读取Delta Lake增量，进行实时ETL

• Spark批作业定期全量处理，修正数据错误

模式二：实时数仓流批一体

• ODS层：Delta Lake存储原始数据

• DWD层：Spark流作业实时清洗、维表关联，写入Delta Lake

• DWS层：Spark批作业定期聚合，输出到ClickHouse/MySQL

模式三：机器学习特征流批一体

• 离线特征：Spark批处理计算历史特征，写入特征库

• 实时特征：Spark流处理计算实时特征，增量更新

• 在线服务：合并离线+实时特征，提供完整的特征视图

第六部分：生产环境稳定性实践

十五、Checkpoint的配置与恢复

Checkpoint是Spark流作业的“生命线”，正确的配置和恢复流程至关重要。

Checkpoint配置要点：

• 存储位置：选择可靠的分布式存储（HDFS、S3），避免使用本地文件系统

• 写入频率：spark.sql.streaming.checkpointLocation 指定位置，引擎自动管理

• 清理策略：定期清理过期的Checkpoint文件，避免存储膨胀

作业恢复流程：

1. 作业异常停止时，保留Checkpoint目录

2. 修复问题后，使用相同的Checkpoint路径重新启动作业

3. 引擎自动从上次成功提交的批次恢复

常见陷阱：

• Checkpoint目录被误删除 → 作业状态丢失，只能从头消费

• Checkpoint目录与代码逻辑不匹配 → 启动失败，需要清理或迁移Checkpoint

十六、背压处理与资源调优

背压的成因：

• 下游写入慢（如数据库写入瓶颈）

• 状态处理慢（如复杂聚合、倾斜key）

• 资源不足（CPU/内存不够）

背压的处理策略：

1. 源端限流：配置 maxOffsetsPerTrigger 限制每批消费量

2. 资源扩容：增加Executor数量或并行度

3. 算子优化：优化慢算子，如使用广播变量、避免shuffle

4. 异步IO：对于维表关联等场景，使用异步IO提升并发

十七、监控与告警体系

Spark流作业需要建立完善的监控体系：

关键指标：

监控工具：

• Spark UI：查看作业详情、Stage执行情况

• 日志聚合：ELK、Splunk收集Driver和Executor日志

• 指标系统：Prometheus + Grafana采集Spark Metrics

十八、升级与迁移策略

版本升级的风险：

• 新版本的Checkpoint可能不兼容旧版本

• 优化器行为变化可能导致执行计划改变

安全升级流程：

1. 停止旧作业，保留Checkpoint

2. 在新版本环境启动新作业，使用相同的Checkpoint

3. 验证数据正确性和性能

4. 双跑一段时间，确认无误后切换流量

5. 保留旧Checkpoint作为回滚预案

第七部分：架构师的认知跃迁

十九、从“会用”到“精通”的三个层次

第一层：API熟练
能够使用DataFrame API编写流处理作业，配置基本的触发间隔和输出模式。这是起点，但不是终点。

第二层：原理理解
理解无限表模型、水印机制、状态管理、Checkpoint原理。能够解释“为什么这样配置”，能够预判作业的行为。

第三层：架构设计
具备端到端视角，能够在业务场景、技术选型、成本控制之间做出权衡。能够设计流批一体架构，能够预判数据量增长10倍时的瓶颈。

二十、两套方案的选型决策框架

二十一、技术之外的“软实力”

1. 与业务的对话能力
能够将技术指标（延迟、吞吐、一致性）翻译为业务价值（用户体验、数据准确度、成本控制）。让业务方理解技术决策背后的权衡。

2. 与运维的协作能力
理解部署环境（YARN/K8s）的限制，能够与运维团队协作优化资源配置。流作业不是“写完就扔”，而是需要持续运维的长期资产。

3. 与团队的传承能力
将踩过的坑、总结的经验沉淀为文档、规范、自动化工具。让团队其他成员能够快速上手，减少重复踩坑。

结语：专业掌握的真正内涵

Spark3实时处理的两套企业级方案——微批处理与连续处理，不是非此即彼的选择题，而是可以灵活组合的工具箱。

微批处理的优势在于成熟稳定、吞吐高、一致性强，是大多数生产场景的首选。

连续处理的价值在于极致低延迟，让Spark在实时风控、实时推荐等敏感场景中占据一席之地。

而真正专业的实时数据工程师，能够在深刻理解这两套方案的原理、优势、局限之后，根据业务场景做出最合适的选择，并将它们有机融合到流批一体的架构中。