企业官网建设流程全解析

1. 流处理选型的十字路口：为什么这两个框架总被放在一起比

但凡做过实时数据链路的人，几乎都绕不开一个灵魂拷问：Spark Streaming 和 Flink 到底选哪个？这个问题在技术社区里被反复咀嚼了七八年，至今仍然没有标准答案。原因很简单——它们都能做流处理，但底层对“流”的理解压根不在一个频道上。我自己从早期用 Spark Streaming 做日志聚合，到后来在多个项目里迁移到 Flink，踩过的坑、推翻过的架构方案、半夜被告警叫醒排查反压的经历，加起来足够写一本小册子。这篇文章不打算给你一个“谁更好”的结论，而是把两者的设计哲学、运行机制、性能表现、运维成本和适用场景彻底拆开，让你看完之后能根据自己的业务形态做出判断。

先说清楚这两个东西分别是什么。Spark Streaming 是 Apache Spark 生态里的流处理模块，核心思路是“把流切成一小段一小段的批”，也就是常说的微批（Micro-Batch）模型。Flink 则是一个从设计之初就面向流处理的计算引擎，它把批看成流的特例，采用真正的逐条事件处理模式。这个根本差异决定了它们在延迟、吞吐、状态管理、容错语义上的所有不同表现。适合读这篇文章的人包括：正在做实时数仓选型的数据工程师、需要从零搭建流处理平台的架构师、以及已经用了其中一个但想搞清楚另一个到底值不值得迁移的开发者。不管你是刚接触流处理的新手，还是已经调过几百个并行度的老手，我都会尽量把每个关键点讲透，配上实际参数和踩坑记录。

2. 核心设计哲学的分野：微批与原生流到底差在哪

2.1 Spark Streaming 的微批模型：把无限流切成有限批

Spark Streaming 的核心抽象叫 DStream（Discretized Stream），本质上是一系列连续的 RDD。你设定一个批处理间隔，比如 1 秒，那么 Spark Streaming 就会每隔 1 秒把这段时间内到达的数据打包成一个 RDD，然后交给 Spark 引擎去计算。这个设计的好处非常明显：它复用了 Spark 成熟的批处理引擎和调度机制，开发门槛低，只要会写 Spark 批处理代码，稍微改改就能跑流任务。而且因为底层是批，容错机制直接继承了 RDD 的血缘关系，出错重算就行，不需要额外维护复杂的状态快照。

但微批的代价也很直接。假设批间隔设为 1 秒，那理论上的最低延迟就是 1 秒，实际端到端延迟通常在 1.5 到 3 秒之间，因为还要算上调度开销和任务启动时间。如果你把批间隔调到 500 毫秒甚至 200 毫秒，调度器就会疲于奔命，大量时间花在任务分发和资源协调上，吞吐反而下降。我实测过一个场景：同样处理 10 万条每秒的 JSON 日志，批间隔 1 秒时吞吐很稳，降到 200 毫秒后 CPU 利用率飙升但处理量反而掉了三成。所以 Spark Streaming 的延迟下限是有物理瓶颈的，它适合那些对延迟要求在秒级、但对吞吐和生态整合要求更高的场景。

2.2 Flink 的原生流模型：事件即到即处理

Flink 的核心理念是“流是本质，批是特例”。数据一条一条地进入算子，算子维护自己的状态，事件在算子之间通过网络缓冲区传输，整个链路是持续运行的。没有人为的批边界，也就没有调度器反复启动任务的额外开销。Flink 的延迟可以做到毫秒级，官方 benchmark 里甚至能压到个位数毫秒。这个特性在风控、实时推荐、异常检测这类场景里非常关键——你总不希望一笔欺诈交易发生 3 秒后才被拦截吧。

Flink 的状态管理也是原生设计的。它提供了 KeyedState、OperatorState 等多种状态类型，配合 Checkpoint 机制做分布式快照。Checkpoint 基于 Chandy-Lamport 算法变体，通过注入 Barrier 对齐来实现一致性快照。这个机制让 Flink 能做到 Exactly-Once 语义，而且不依赖外部系统的幂等写入。相比之下，Spark Streaming 要保证 Exactly-Once 通常需要借助外部存储的事务能力或者幂等操作，实现起来更绕一些。不过 Flink 的状态后端选择也有讲究，MemoryStateBackend 适合本地调试，FsStateBackend 适合状态不大的生产任务，RocksDBStateBackend 则能支撑 TB 级状态，但读写性能会受磁盘 IO 影响，需要根据实际情况权衡。

2.3 延迟与吞吐的取舍：没有银弹，只有场景匹配

把两者放在同一张表里对比会更直观。以下数据基于我实际压测环境（3 节点集群，每节点 16 核 64GB，千兆内网）的粗略结果，具体数值会因数据特征和代码质量浮动：

从表里能看出来，Flink 在延迟和状态规模上有明显优势，但 Spark Streaming 的吞吐并不差太多，而且它的优势在于和 Spark SQL、MLlib、GraphX 的无缝集成。如果你的实时链路下游还要接复杂的批处理分析或者机器学习模型，Spark 生态的一体化会省掉很多数据搬运和格式转换的麻烦。所以选型的第一原则不是“谁技术更先进”，而是“我的业务到底最在意什么”。

3. 运行机制深度拆解：从任务调度到容错恢复

3.1 任务调度模型：粗粒度与细粒度的较量

Spark Streaming 的任务调度沿用了 Spark 的 DAG 调度器。每个批间隔生成一个 DAG，DAGScheduler 把它拆成 Stage，TaskScheduler 再把 Task 分发到 Executor 上。这个过程每个批次都要走一遍，包括任务序列化、资源分配、心跳通信。批间隔越短，这部分开销占比越高。我见过一个极端的例子：批间隔设成 100 毫秒，结果每个批次光调度就花了 80 毫秒，真正计算的时间只有 20 毫秒，CPU 大部分时间在空转。

Flink 的调度是细粒度的。JobManager 负责协调，TaskManager 上预先分配好 Slot，算子任务在 Slot 里长期运行，数据来了直接处理，不需要每个批次重新调度。这种长驻任务的模式减少了大量调度开销，但也意味着资源是常驻占用的，不像 Spark 那样可以动态释放。Flink 1.11 之后引入了 Application Mode 和 Session Mode 的区分，还有 Reactive Mode 可以根据负载自动扩缩容，但整体来说资源弹性还是不如 Spark on YARN/K8s 那么灵活。实际选型时，如果你的集群是共享的、负载波动大，Spark 的动态资源分配会更省成本；如果是专用集群、负载稳定，Flink 的长驻模式效率更高。

3.2 Checkpoint 与恢复：谁能在故障后更快站起来

Spark Streaming 的容错依赖 RDD 血缘和 Checkpoint。你可以设置 checkpoint 目录，定期把 DStream 的元数据和 RDD 数据写进去。故障恢复时，Driver 重启后从 checkpoint 恢复 DStream 图，然后重算丢失的批次。这个机制的问题在于：如果血缘链很长，重算代价会很大；而且 Checkpoint 本身是同步操作，频繁做会影响吞吐。我一般建议 checkpoint 间隔至少是批间隔的 5 到 10 倍，比如批间隔 1 秒，checkpoint 设 10 秒一次。

Flink 的 Checkpoint 是基于 Barrier 的异步快照。JobManager 定期触发 Checkpoint，Source 算子注入 Barrier，Barrier 随着数据流向下游传递，每个算子收到所有输入的 Barrier 后做本地状态快照，然后继续传递。整个过程是异步的，不阻塞数据处理。恢复时，Flink 从最近的 Completed Checkpoint 恢复所有算子的状态和 Source 的偏移量，做到精确一次。Flink 还支持 Savepoint，可以手动触发，用于版本升级、扩缩容或者迁移。这个功能在需要不停机发布新版本时特别有用，Spark Streaming 在这方面就弱一些，通常需要停任务再重启。

3.3 反压机制：谁在数据洪峰面前更从容

反压是流处理系统绕不开的问题。上游生产速率超过下游消费速率时，如果没有合理的反压机制，要么数据丢失，要么内存爆掉。Spark Streaming 从 1.5 版本开始引入了基于 PID 控制器的反压机制，通过动态调整接收速率来匹配处理能力。具体来说，它会监控每个批次的处理延迟和调度延迟，如果发现处理不过来，就降低接收器的速率。这个机制在大多数场景下够用，但 PID 参数调优比较玄学，有时候反应迟钝，有时候又过于敏感导致吞吐上不去。

Flink 的反压是基于信用值的网络流控。每个 Task 的输出缓冲区和输入缓冲区之间有信用机制，下游消费多少就授予上游多少信用，上游根据信用发送数据。这个机制更细粒度，反应更快，而且不会丢数据。但 Flink 的反压也会带来一个问题：当反压传导到 Source 时，如果 Source 不支持暂停（比如某些消息队列的消费者），就会导致数据积压在外部系统。所以用 Flink 的时候，Source 端的配置也很关键，比如 Kafka Consumer 的 max.poll.records 和 fetch.max.bytes 需要根据下游处理能力调整。

4. 状态管理与 Exactly-Once 语义的实现细节

4.1 Spark Streaming 的状态管理：updateStateByKey 与 mapWithState

Spark Streaming 做有状态计算主要靠两个 API：updateStateByKey 和 mapWithState。updateStateByKey 是早期方案，每次都要对整个状态 RDD 做全量转换，状态大了性能急剧下降。mapWithState 是后来引入的改进版，只处理有更新的 key，性能好很多，但 API 更复杂，而且状态存储在 Executor 内存里，受限于 JVM 堆大小。如果要存大状态，得自己接 Redis 或者 HBase 做外部存储，但这样就失去了 Exactly-Once 的保证，需要业务层做幂等。

我踩过的一个坑是：用 updateStateByKey 做用户会话统计，状态里存了每个用户的最后活跃时间和访问计数。跑了三天后状态膨胀到 20GB，GC 时间从 50ms 涨到 2 秒，任务频繁超时。后来改成 mapWithState 加上 TTL 清理，才把状态控制在 2GB 以内。所以用 Spark Streaming 做有状态计算，一定要提前规划状态的清理策略，不能让它无限增长。

4.2 Flink 的状态后端：Memory、Fs 与 RocksDB 的选择

Flink 的状态管理是分层的。StateBackend 决定了状态存储在哪里、怎么做快照。MemoryStateBackend 把状态存在 TaskManager 的 JVM 堆里，Checkpoint 也存到 JobManager 内存，只适合本地测试和小状态任务。FsStateBackend 把状态存在堆里，但 Checkpoint 写到分布式文件系统，适合状态在 GB 级以内的生产任务。RocksDBStateBackend 把状态存在 RocksDB 里，Checkpoint 也写到文件系统，能支撑 TB 级状态，但读写要经过序列化和磁盘 IO，延迟会比前两者高。

选择 StateBackend 的核心依据是状态规模和延迟要求。我的一般建议是：状态小于 1GB 且延迟敏感，用 FsStateBackend；状态在 1GB 到 100GB 之间，用 RocksDBStateBackend 并开启增量 Checkpoint；状态超过 100GB，必须用 RocksDB 并且要考虑状态分区和本地恢复。增量 Checkpoint 是 RocksDB 后端的一个重要优化，它只上传变化的 SST 文件，而不是全量快照，能把 Checkpoint 时间从分钟级降到秒级。

4.3 Exactly-Once 的端到端实现：Source 和 Sink 的配合

Exactly-Once 不是单个框架能保证的，它需要 Source、计算引擎、Sink 三方配合。Spark Streaming 要做的端到端 Exactly-Once，通常需要 Source 支持偏移量回滚（比如 Kafka 的 offset 提交），Sink 支持事务写入或者幂等写入。比如写 Kafka 时开启幂等生产者，写数据库时用 upsert 或者事务。Flink 的 TwoPhaseCommitSinkFunction 提供了更优雅的方案，它把 Sink 的提交分成预提交和正式提交两个阶段，配合 Checkpoint 完成原子性写入。Kafka Sink、File Sink、JDBC Sink 都有对应的实现。

但要注意，TwoPhaseCommitSinkFunction 要求外部系统支持事务或者至少支持幂等写入。如果 Sink 是那种不支持事务的存储，比如某些 NoSQL 数据库，那还是得靠业务层做去重。我见过一个团队用 Flink 写 HBase，以为开了 Checkpoint 就万事大吉，结果故障恢复后数据重复了，就是因为 HBase 的写入不是幂等的。后来他们在 HBase 的 rowkey 里加了事件 ID，用版本号做去重，才解决了问题。

5. 生态整合与开发体验：谁更贴近你的技术栈

5.1 Spark 生态的一体化优势

Spark 最大的护城河是生态。Spark SQL、DataFrame、MLlib、GraphX、Structured Streaming，这些组件共享同一套 API 和运行时。如果你的团队已经在用 Spark 做批处理，那上 Spark Streaming 几乎是零学习成本。Structured Streaming 更是把流和批的 API 统一了，你可以用 DataFrame 的写法处理流数据，底层引擎自动优化。而且 Spark 的社区活跃度极高，遇到问题搜一下基本都有答案，第三方库和工具链也丰富。

但 Spark Streaming 的生态优势也带来一个包袱：它要兼顾批和流，所以在流处理的极致性能上做了妥协。比如 Structured Streaming 虽然 API 更优雅，但底层还是微批，延迟下限摆在那里。而且 Spark 的版本升级经常带来 API 不兼容，从 1.x 到 2.x 再到 3.x，每次大版本升级都要改不少代码。Flink 的 API 相对稳定一些，1.x 到 1.17 的核心 API 基本没大改，但 Flink 的生态确实不如 Spark 丰富，很多功能需要自己造轮子。

5.2 Flink 的生态短板与补齐速度

Flink 的 Table API 和 SQL 是后来才完善的，早期版本做 SQL 流处理限制很多。Flink 1.12 之后 Table API 逐渐成熟，支持了更多的内置函数和连接器，但和 Spark SQL 的成熟度还有差距。Flink ML 也一直不温不火，做机器学习还是得把数据导出到 Python 环境用 scikit-learn 或者 TensorFlow。不过 Flink 在 CDC（Change Data Capture）和实时数仓方面发力很猛，Flink CDC 连接器可以直接从 MySQL、PostgreSQL 抓取变更日志，配合 Flink SQL 做实时 ETL，这套组合在实时数仓场景里非常受欢迎。

开发体验上，Spark 的交互式 Shell 和 Notebook 支持更好，调试方便。Flink 的本地调试相对麻烦一些，尤其是涉及状态和 Checkpoint 的逻辑，本地跑和集群跑行为可能不一致。我一般建议 Flink 任务先在本地用 MiniCluster 跑通逻辑，再上集群做集成测试。另外 Flink 的 Web UI 比 Spark 的更直观，能实时看到每个算子的吞吐、延迟、反压状态，排查问题效率高很多。

5.3 运维复杂度与社区支持

运维层面，Spark Streaming 通常跑在 YARN 或者 K8s 上，资源调度交给集群管理器，运维团队只需要关注 Spark 任务本身。Flink 的部署模式更多样，Standalone、YARN、K8s、Mesos 都支持，但每种模式的配置和调优都不一样。Flink on K8s 的 Native Kubernetes 模式虽然优雅，但对 K8s 版本和网络插件有要求，踩坑概率不低。我见过一个团队从 Spark 迁到 Flink，光 K8s 网络策略就调了两周。

社区支持方面，Spark 的 Stack Overflow 问答量和 GitHub Issue 响应速度都优于 Flink。但 Flink 的中文社区很活跃，国内大厂贡献了很多连接器和优化，遇到问题在中文社区提问往往能更快得到回复。另外 Flink 的官方文档质量很高，尤其是概念解释和配置说明，比 Spark 文档更系统。Spark 文档有时候过于简略，很多细节要靠读源码或者搜博客。

6. 实战选型指南：什么场景该用谁

6.1 优先选 Spark Streaming 的场景

如果你的实时任务延迟要求在秒级、吞吐要求高、而且下游还要接批处理或者机器学习，Spark Streaming 是更稳妥的选择。比如日志聚合、实时报表、用户行为分析这类场景，秒级延迟完全够用，Spark 生态的一体化能省掉很多数据搬运工作。另外如果团队已经熟悉 Spark，迁移成本几乎为零，招人也好招。还有一点：Spark Streaming 的运维相对简单，YARN 上跑几百个流任务很常见，资源隔离和优先级调度都很成熟。

6.2 优先选 Flink 的场景

毫秒级延迟、Exactly-Once 语义、大状态、复杂事件处理，这四个需求里只要占两个，Flink 就是更合适的选择。比如实时风控、实时推荐、IoT 设备监控、金融交易监控，这些场景对延迟和准确性要求极高，Spark Streaming 的微批模型很难满足。另外 Flink 的 CEP 库做复杂事件模式匹配非常方便，比如检测“连续三次登录失败后五分钟内转账”这种规则，用 Flink CEP 几行代码就能搞定，Spark 那边得自己写状态机。

6.3 混合架构：两者共存的现实方案

实际生产环境里，很多团队是两者共存的。比如用 Flink 做实时 ETL 和风控，用 Spark Streaming 做实时报表和离线补数。这种混合架构的关键是统一数据源和元数据管理，避免两套系统数据不一致。我一般建议用 Kafka 作为统一的数据总线，Flink 和 Spark 都从 Kafka 消费，各自处理各自的部分。元数据用 Hive Metastore 或者 DataHub 统一管理，保证 schema 一致。资源调度上，如果跑在同一个 YARN 集群，要设置好队列容量和优先级，避免互相抢资源。

7. 常见问题与排查技巧实录

7.1 Spark Streaming 常见问题速查

7.2 Flink 常见问题速查

7.3 独家避坑经验

第一个坑：Spark Streaming 的 checkpoint 目录不要和 Spark 的默认文件系统混用。我见过一个团队把 checkpoint 写到 /tmp 下，结果机器重启后 checkpoint 丢了，任务恢复失败。checkpoint 一定要写到可靠的分布式文件系统，比如 HDFS 或者 S3，并且设置好生命周期策略。

第二个坑：Flink 的并行度不要超过 Kafka 分区数。如果并行度大于分区数，多出来的 Subtask 会空闲，浪费资源。而且 Kafka 消费者的并行度最好和分区数一致，这样每个 Subtask 处理一个分区，避免 rebalance 带来的抖动。

第三个坑：Spark Streaming 的 batch interval 和窗口操作的时间关系要理清。窗口长度必须是批间隔的整数倍，滑动间隔也是。如果设了窗口长度 10 秒、滑动间隔 3 秒、批间隔 1 秒，那窗口计算会非常频繁，状态也会膨胀。我一般建议滑动间隔至少是批间隔的 3 到 5 倍。

第四个坑：Flink 的 Checkpoint 间隔不要设得太短。Checkpoint 本身有开销，太频繁会影响吞吐。一般建议 Checkpoint 间隔在 1 到 5 分钟之间，具体看状态大小和恢复时间要求。如果状态很大，恢复时间可能比 Checkpoint 间隔还长，那就得考虑用 Savepoint 做版本管理，而不是依赖 Checkpoint 恢复。

第五个坑：两者混用时，Kafka 的消费者组要分开。Spark 和 Flink 用不同的 group.id，否则会互相抢分区，导致数据重复消费或者漏消费。这个坑我踩过，当时两个任务用同一个 group.id，结果 Spark 任务把 Flink 任务的分区抢走了，Flink 那边一直没数据，排查了半天才发现是消费者组冲突。

8. 性能调优的实战参数与计算过程

8.1 Spark Streaming 调优参数

Spark Streaming 的性能调优核心是平衡批间隔、并行度和资源。批间隔的计算公式是：批间隔 ≥ 平均处理时间 × 1.5。平均处理时间可以从 Spark UI 的 Streaming 页面看到，取最近 100 个批次的平均值。并行度方面，Executor 数量 × 每个 Executor 的核数，应该至少是 Kafka 分区数的 1.5 倍，留出余量应对数据倾斜。内存分配上，Executor 内存的 60% 给计算，40% 给存储，如果用了 mapWithState，存储比例要调大。

具体参数示例：假设 Kafka 有 32 个分区，平均处理时间 800ms，那批间隔可以设 1 秒，Executor 数量 8 个，每个 4 核，总核数 32，刚好匹配分区数。Executor 内存 16GB，其中 10GB 给计算，6GB 给存储。spark.streaming.backpressure.enabled 设为 true，initialRate 设为 1000 条每秒每分区，让系统自己往上探。

8.2 Flink 调优参数

Flink 的调优核心是并行度、状态后端和网络缓冲。并行度一般设为 Kafka 分区数的整数倍，但不要超过分区数太多。状态后端如果选 RocksDB，要调大 taskmanager.memory.managed.size，一般占总内存的 40% 到 50%。网络缓冲方面，taskmanager.network.memory.fraction 默认 0.1，如果反压严重可以调到 0.2。Checkpoint 间隔设 3 分钟，超时设 10 分钟，最小暂停时间设 500ms，避免 Checkpoint 太密集。

具体参数示例：TaskManager 内存 32GB，managed.size 设 14GB，network.memory.fraction 设 0.15，并行度设 32。Checkpoint 配置：interval 3min，timeout 10min，min-pause 500ms，mode EXACTLY_ONCE，backend 用 RocksDB 并开启 incremental。这些参数不是固定的，要根据实际负载压测后调整。我一般会先用默认参数跑一轮，看 Web UI 的瓶颈在哪里，再针对性调优。

8.3 压测方法与指标解读

压测流处理任务不能只看吞吐，还要看延迟分布和资源利用率。我一般用 Kafka 的生产者压测工具往目标 Topic 灌数据，逐步增加速率，观察任务的端到端延迟和反压状态。Spark Streaming 看 Spark UI 的 Scheduling Delay 和 Processing Time，如果 Scheduling Delay 持续增长，说明处理不过来。Flink 看 Web UI 的 BackPressure 和 Checkpoint 时长，如果反压持续 high，说明某个算子瓶颈。

延迟测量最好在数据里打时间戳，从 Source 读到数据到 Sink 写出数据算端到端延迟。不要只看框架内部的延迟指标，那个不含外部系统的耗时。我见过一个任务框架内延迟只有 10ms，但端到端延迟 2 秒，原因是 Sink 写数据库时批量提交太慢。所以压测一定要覆盖全链路，不能只测计算部分。

9. 个人经验总结与后续扩展方向

写了这么多，其实核心就一句话：Spark Streaming 和 Flink 没有绝对的好坏，只有合不合适。我自己的选择逻辑是：延迟要求秒级、团队熟悉 Spark、下游有批处理需求，选 Spark Streaming；延迟要求毫秒级、需要 Exactly-Once、状态大、有 CEP 需求，选 Flink。如果两个都想用，那就用 Kafka 做总线，各取所长。

后续如果要做更深入的对比，可以往这几个方向扩展：一是 Flink 的流批一体和 Spark 的 Structured Streaming 在实时数仓场景下的性能对比；二是两者在 K8s 上的部署和弹性伸缩实践；三是 Flink SQL 和 Spark SQL 在流处理场景下的功能覆盖度和易用性对比。这些话题每一个都值得单独写一篇，等后面有机会再展开。

最后分享一个小技巧：不管选哪个框架，都先把监控和告警搭好。流处理任务最怕的不是性能不够，而是出问题了没人知道。Spark 的 StreamingListener 和 Flink 的 MetricReporter 都能对接 Prometheus，配上 Grafana 看板，延迟、吞吐、反压、Checkpoint 状态一目了然。我现在的习惯是每个流任务上线前必须配好告警规则，延迟超过阈值、Checkpoint 连续失败、任务重启次数超标，都要第一时间通知到人。这个习惯帮我避免了好几次半夜的数据事故。