> **摘要**：任何新技术的诞生，都是旧方案疼到一定程度的产物。Structured Streaming 的出现，背后是 Lambda 架构双链路之痛、DStream API 割裂、语义全靠业务代码自己扛这三重积怨。本文沿"批处理 → DStream → Structured Streaming"的演进线，拆解它诞生的四个真实动因和背后的设计取舍：为什么用"无限表"而不是别的抽象、为什么坚持微批而不是连续处理、为什么把 Exactly-Once 提到一等目标。
>
> **关键词**：Structured Streaming, Spark, DStream, Lambda 架构, 流批一体, 增量查询, 实时计算, Exactly-Once

---

## 一、先看需求：为什么实时计算成了必答题

一切要从业务侧的变化说起。互联网渗透到每个行业后，"昨天看的报表"越来越不够用：

- **风控反欺诈**：一笔可疑交易发生时要秒级拦截，等 T+1 的离线报表，钱早转走了；
- **实时推荐/广告**：用户点击行为要分钟级进入特征，推荐才谈得上"懂我"；
- **IoT 监控与运维**：几十万设备上报的指标，异常要秒级告警，而不是事后复盘。

Hadoop 生态的 MapReduce 是为"大规模离线吞吐"设计的，分钟级都困难，更别说秒级。**数据从产生到可用的时间差，就是业务风险敞口的时间**——这是实时计算登上舞台的根本推手。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-2482016/a38d68e4db73847e3681e5861aef297f.png)


## 二、第一代答案：Lambda 架构的双链路之痛

早期社区给出的答案是 **Lambda 架构**（Nathan Marz，2011）：一套系统分两条链路——

- **Batch Layer**：全量数据走 MapReduce，算得慢但结果准，产出"批视图"；
- **Speed Layer**：最新数据走 Storm 等实时引擎，算得快但结果近似，产出"实时视图"；
- **Serving Layer**：查询时把两个视图合并，给出"当前答案"。

听起来很美，落地全是坑：

1. **一套逻辑写两遍**。批视图用批处理代码，实时视图用流处理代码，两套 API、两套算子、两拨人维护。业务逻辑改一次，两边都得同步改，漏一个就是事故。
2. **结果天然不一致**。两套代码对同一个指标算出两个数，到底信谁？ Serving 层合并时还要人工权衡权重，这套"缝合"逻辑本身又成了新的 bug 温床。
3. **运维成本翻倍**。两套集群、两套监控、两套升级。小团队根本养不起，最后往往只维护了 Speed Layer，回到"近似但可用"的将就状态。

一句话：**Lambda 架构用工程复杂度换取了时效性，本质上是把"一致性"这个技术问题转嫁成了"运维问题"**。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-2482016/3e124a82347c2ee7978996169b47637e.png)


## 三、Spark 的第一代答案：DStream 与其短板

2013 年 Spark Streaming（DStream）带着"把流切成小批"的思路入场：每个 batchInterval 攒一个 RDD，走成熟的批处理引擎。它解决了 Lambda 的"两套集群"问题——流和批共用一套 Spark 集群，延迟做到秒级。

但用了几年，四个短板越来越疼：

**① API 割裂，红利吃不到。** 流侧用 DStream API，批侧用 DataFrame/SQL。Catalyst 优化器和 Tungsten 执行引擎的红利，DStream 一点吃不到；同一套业务要写两份代码，Lambda 的"两遍逻辑"换了个形式继续存在。

**② 语义全靠业务自己扛。** DStream 的容错是"至少一次"：挂了重放，重复数据得业务自己在 Sink 端去重。事件时间、迟到数据、窗口水位线这些概念，DStream 时代基本要开发者手写实现——每个做窗口聚合的人，都自己写过一版"过期数据清理"。

**③ 延迟下限卡在微批。** batchInterval 设 1 秒，延迟就是秒级；想压到百毫秒，批攒不起来，RDD 的调度开销又扛不住。

**④ 与 SQL 生态绝缘。** 2015 年 DataFrame/SQL 统一了 Spark 的批处理 API，流侧却自成一体，Thrift Server、JDBC、Hive  Metastore 这些资产在流场景全部用不上。

到 2015 年前后，Spark 社区内部形成共识：**继续修 DStream 补不上这些洞，需要一个新的流计算抽象**。这个共识的直接产物就是 2016 年随 Spark 2.0 发布的 Structured Streaming。

## 四、破局点：把流看作一张无限追加的表

Structured Streaming 的核心设计，可以浓缩成一句话：**流不是"切碎的批"，而是"一张永远在追加行的表"**。

这个抽象不是拍脑袋，而是三个深思熟虑的推导：

**推导一：如果流是一张表，就能复用全部批处理武器。** 输入流 = Input Table，查询 = 普通 SQL，结果 = Result Table。Catalyst 优化、Tungsten 执行、DataFrame/Dataset/SQL API、Codegen——批处理攒了五年的家底，流式查询开箱即用。流批一体从口号变成架构事实。

**推导二：如果引擎管着结果表，语义就可以引擎兜底。** DStream 时代一致性靠业务代码；现在引擎负责"新数据到了就增量更新结果表"，它天然知道哪些行变了、哪些状态该清理、故障后从哪里重放——**Exactly-Once 从"业务诉求"变成"引擎契约"**。

**推导三：如果事件时间是表里的一列，迟到数据就是普通更新。** 窗口聚合只是按事件时间列分组；迟到的行只是修正已更新的聚合值。配合水位线（Watermark）声明容忍阈值，引擎自动决定"窗口何时出结果、状态何时可删"——这套语义在 DStream 时代要靠用户手写。

## 五、两个关键取舍：为什么是微批？为什么不物化整表？

### 5.1 为什么坚持微批，而不是纯连续处理

Flink 的纯流模式延迟可以到毫秒，Structured Streaming 却选择以微批为主力（连续处理到 Spark 3.x 仍是实验特性）。原因很工程：

- **复用成熟的分布式执行引擎**。微批 = 在现有 Spark SQL 引擎上跑一批"小查询"，容错、调度、资源管理、性能优化全部白嫖；
- **容错模型简单可靠**。批的边界天然就是事务边界：要么整批生效、要么整体重放，配合 WAL 和幂等 Sink 即可证明端到端 Exactly-Once；
- **吞吐优先于极限延迟**。Spark 的主战场是大规模实时 ETL 与聚合，秒级延迟足够覆盖，为毫秒延迟牺牲吞吐和稳定性不划算。

延迟敏感算子（`map`/`filter`）在 3.x 后可用 `Trigger.Continuous` 尝鲜，但社区态度很明确：生产主力仍是微批。

### 5.2 为什么不物化整张输入表

"无限表"只是逻辑抽象。如果真把每条到达的数据 append 进一张物理大表，存储先爆。引擎的做法是：**只读最新一段数据，结合保留的最小中间状态算出新结果，源数据读完即弃**。

```properties
# 状态只保留聚合中间值等最小集合，而非输入数据本身
spark.sql.streaming.stateStore.providerClass=org.apache.spark.sql.execution.streaming.state.RocksDBStateStoreProvider
```

这也是为什么 Structured Streaming 能 7×24 小时长跑——状态规模取决于"业务本身"（如聚合键基数），而不是数据总量。

## 六、设计目标全景：四大动机如何映射到机制

回顾它的诞生，四条动因各自长成了引擎里的具体设计：

| 诞生动因（旧方案的痛） | Structured Streaming 的解法 |
|---|---|
| Lambda 双链路、逻辑写两遍 | 一套 SQL 同时表达批与流，流批一体 |
| DStream 吃不到 Catalyst/Tungsten | 查询直接编译进 Spark SQL 引擎 |
| 一致性、事件时间靠业务自扛 | 引擎契约：增量更新 + WAL + 幂等 Sink → Exactly-Once；Watermark 管迟到数据 |
| 与 SQL 生态绝缘、API 割裂 | DataFrame/Dataset 统一 API，直接接 JDBC/Thrift/Hive 生态 |

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-2482016/20cbb37245c2cb3f0c650cef6ec73edf.png)


## 七、总结

- Structured Streaming 的诞生，是 Lambda 架构双链路之痛、DStream 四大短板（API 割裂、优化器缺席、语义自扛、生态绝缘）共同倒逼的结果；
- 核心抽象"无限表"是一次精心推导：用批处理的成熟武器打流式的仗，把一致性从业务代码上收为引擎契约；
- 坚持微批是明确的工程取舍：复用 Spark SQL 引擎与简单容错模型，优先吞吐和稳定性，而非极限延迟；
- 不物化整表是成本设计：只保留最小中间状态，让长跑作业的状态规模与数据总量解耦；
- 对工程师的意义：选型上理解"它为什么长这样"，才能判断什么场景适合它、什么场景该去看 Flink。

---

摘要：任何新技术的诞生，都是旧方案疼到一定程度的产物。Structured Streaming 的出现，背后是 Lambda 架构双链路之痛、DStream API 割裂、语义全靠业务代码自己扛这三重积怨。本文沿"批处理 → DStream → Structured Streaming"的演进线，拆解它诞生的四个真实动因和背后的设计取舍：为什么用"无限表"而不是别的抽象、为什么坚持微批而不是连续处理、为什么把 Exactly-Once 提到一等目标。

Structured Streaming 诞生原因剖析：为什么 Spark 要用一张“无限表“重做流计算

摘要：任何新技术的诞生，都是旧方案疼到一定程度的产物。Structured Streaming 的出现，背后是 Lambda 架构双链路之痛、DStream API 割裂、语义全靠业务代码自己扛这三重积怨。本文沿"批处理 → DStream → Structured Streaming"的演进线，拆解它诞生的四个真实动因和背后的设计取舍：为什么用"无限表"而不是别的抽象、为什么坚持微批而不是连续处

大数据

架构设计

后端

StructuredStreaming诞生于Lambda双链路之痛、DStream四大短板（API割裂、语义自扛、优化器缺席、生态绝缘）。核心抽象"无限表"将流视为追加行的表，复用SparkSQL引擎实现流批一体；微批模式确保Exactly-Once与高吞吐；状态存储解耦数据总量，支撑7×24小时长跑。适合秒级延迟的实时ETL场景。

代码解释

MapReduce

Hadoop 

Spark 

Storm

Hive

让每一个 Agent，都跑在云上

bigdata-class

oceanus

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

StructuredStreaming诞生于Lambda双链路之痛、DStream四大短板（API割裂、语义自扛、优化器缺席、生态绝缘）。核心抽象"无限表"将流视为追加行的表，复用SparkSQL引擎实现流批一体；微批模式确保Exactly-Once与高吞吐；状态存储解耦数据总量，支撑7×24小时长跑。适合秒级延迟的实...

Structured Streaming 诞生原因剖析：为什么 Spark 要用一张“无限表“重做流计算-腾讯云开发者社区-腾讯云

Structured Streaming 诞生原因剖析：为什么 Spark 要用一张“无限表“重做流计算

Structured Streaming 诞生原因剖析：为什么 Spark 要用一张“无限表“重做流计算

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐