4. Spark Structured Streaming 核心概念：无界表、微批处理、连续处理模式、事件时间与处理时间
在构建信用额度定价的流式决策系统时，理解 Spark Structured Streaming 的底层抽象是设计高效、准确管道的前提。Structured Streaming 将实时数据流建模为一张持续追加的无界表，并提供了两种执行引擎：微批处理（默认）与连续处理。同时，为了在定价决策中正确处理延迟数据与时钟偏差，必须区分事件时间与处理时间。本节将逐一拆解这些核心概念，并展示它们在信用额度定价场景中的映射关系。
4.1 无界表：流数据的统一抽象
Structured Streaming 最核心的设计思想是将流数据视为一张不断增长、永不终止的表。每当新数据到达数据源（如 Kafka、Kinesis），Spark 将其视为向这张“无界表”中追加新行。开发者可以使用与批处理完全相同的 DataFrame/Dataset API 对这张表进行查询、聚合与过滤。
4.2 微批处理模式（默认）
微批处理是 Structured Streaming 的默认执行模式。它将连续到达的数据流切分成一系列小批次（通常间隔 100ms ~ 1s），每个批次作为一个独立的 Spark 作业执行。这种模式继承了 Spark 批处理引擎的容错性与 Exactly-Once 语义，非常适合对准确性要求极高的信用额度定价场景。
| 特性 | 微批处理模式 | 信用额度定价影响 |
|---|---|---|
| 延迟 | 亚秒级至秒级（取决于批次间隔） | 适用于非实时调额（如日切后重定价） |
| 容错 | 基于 WAL + 状态 Checkpoint，Exactly-Once | 保证每笔额度变更不重复、不丢失 |
| 吞吐 | 高（可批量处理大量事件） | 适合高并发交易场景下的批量定价 |
| 适用场景 | 对延迟不敏感、需要强一致性的场景 | 额度重算、风险汇总、批量审批 |
trigger(processingTime='10 seconds') 灵活控制延迟与吞吐的平衡。
4.3 连续处理模式
连续处理模式是 Spark 2.3 引入的实验性执行引擎，旨在将端到端延迟降低到毫秒级。与微批处理不同，连续处理不再等待批次边界，而是以长运行任务的形式持续读取、处理并输出数据。它适用于对延迟极度敏感、且可以接受至少一次（At-Least-Once）语义的场景。
map、filter、select 等无状态操作，不支持聚合（如 groupBy）或流-流 Join。在信用额度定价中，若涉及状态管理（如用户累计额度），仍需回退到微批处理。
4.4 事件时间与处理时间
在流式定价决策中，数据到达时间（处理时间）与事件实际发生时间（事件时间）往往不一致。Structured Streaming 提供了明确的时间语义支持，帮助开发者正确处理延迟、乱序数据。
- 事件时间（Event Time）： 事件实际发生的时间戳，通常嵌入在数据记录中（如交易时间、征信查询时间）。这是信用额度定价的业务时间基准——额度调整应基于事件发生时的用户状态，而非数据到达系统的时刻。
- 处理时间（Processing Time）： 数据到达 Spark 引擎并被处理的时间。处理时间简单易用，但受系统负载、网络延迟影响，不具备可重复性。
| 维度 | 事件时间 | 处理时间 |
|---|---|---|
| 定义 | 事件实际发生的时间 | 数据被处理的时间 |
| 确定性 | 确定（由数据源决定） | 不确定（依赖系统时钟与负载） |
| 乱序容忍 | 支持（通过 Watermark） | 不支持 |
| 定价场景 | 交易时间、征信时间、额度变更时间 | 日志审计、监控告警 |
| 代码示例 | .withWatermark("event_time", "10 seconds") |
默认时间语义 |
4.5 核心概念在信用额度定价中的综合应用
将上述概念整合到信用额度定价的流式决策管道中，形成如下架构映射：
- 无界表： 将 Kafka 中的交易事件、征信查询、额度变更请求统一建模为“定价事件流表”。
- 微批处理（默认）： 使用 5~10 秒的批次间隔，执行额度计算、风险聚合、规则匹配等有状态操作，保证 Exactly-Once 语义。
- 事件时间 + Watermark： 以交易时间作为事件时间，设置 30 秒水位线，容忍网络延迟与乱序，确保额度计算的时间窗口准确。
- 连续处理（可选）： 在需要毫秒级响应的场景（如实时欺诈拦截后的紧急降额），使用连续处理模式执行无状态过滤与告警。