Flink 1.20 LTS 与 Spark 3.5 流处理对比3个核心场景下的延迟与吞吐实测在实时数据处理领域Flink 和 Spark Streaming 一直是两大主流框架。随着 Flink 1.20 LTS 版本的发布和 Spark 3.5 的更新两者在流处理能力上都有了显著提升。本文将通过三个典型业务场景的实测数据对比分析这两个框架在延迟和吞吐量方面的表现为技术选型提供数据支撑。1. 测试环境与方法论1.1 测试环境配置我们搭建了一个包含 10 个节点的测试集群每个节点配置如下组件规格配置CPUIntel Xeon Platinum 8480C内存256GB DDR5存储2TB NVMe SSD网络25Gbps RDMA操作系统Ubuntu 22.04 LTS软件版本Flink 1.20.0 (Standalone 模式)Spark 3.5.0 (YARN 模式)Kafka 3.6.0 (作为数据源)Zookeeper 3.8.31.2 测试方法论我们设计了以下测试流程数据生成器使用 Kafka Producer 以可控速率发送测试数据处理程序分别实现 Flink 和 Spark Streaming 的处理逻辑结果收集通过 Prometheus Grafana 监控系统指标压力测试逐步增加输入速率直到系统饱和关键指标定义延迟从数据进入 Kafka 到处理完成的时间差吞吐量每秒成功处理的消息数量资源利用率CPU、内存、网络的使用率2. 窗口聚合场景对比窗口聚合是流处理中最常见的操作之一我们测试了滚动窗口Tumbling Window下的表现。2.1 测试代码实现Flink 实现DataStreamEvent events env .addSource(new FlinkKafkaConsumer(input-topic, new EventSchema(), props)) .keyBy(Event::getUserId) .window(TumblingEventTimeWindows.of(Time.seconds(10))) .aggregate(new CountAggregate()) .addSink(new KafkaSink(output-topic, new CountResultSchema(), props));Spark 实现val stream spark .readStream .format(kafka) .option(kafka.bootstrap.servers, brokers) .option(subscribe, input-topic) .load() .select(from_json($value.cast(string), schema).as(event)) .groupBy(window($event.timestamp, 10 seconds), $event.userId) .count() .writeStream .format(kafka) .option(kafka.bootstrap.servers, brokers) .option(topic, output-topic) .start()2.2 性能测试结果指标Flink 1.20Spark 3.5差异平均延迟(ms)23152-85%最大吞吐(万/s)786520%99分位延迟(ms)45210-79%CPU利用率68%82%-17%关键发现Flink 的延迟表现显著优于 Spark特别是在高负载情况下Spark 的微批处理模型在吞吐量上接近 Flink但资源消耗更高当窗口大小增加到 1 分钟时两者差距缩小3. 状态更新场景对比状态管理是复杂流处理应用的核心需求我们测试了带有状态计算的用户行为分析场景。3.1 状态处理实现差异Flink 状态后端配置state.backend: rocksdb state.checkpoints.dir: hdfs:///flink/checkpoints state.savepoints.dir: hdfs:///flink/savepoints state.backend.rocksdb.ttl.compaction.filter.enabled: trueSpark 状态存储spark.conf.set(spark.sql.streaming.checkpointLocation, /spark/checkpoints) spark.conf.set(spark.sql.streaming.stateStore.providerClass, org.apache.spark.sql.execution.streaming.state.RocksDBStateStoreProvider)3.2 性能对比数据测试场景维护每个用户的最近 10 次行为记录状态规模Flink P99延迟Spark P99延迟状态恢复时间10万用户28ms105ms12s vs 45s100万用户52ms230ms25s vs 98s1000万用户115ms420ms48s vs 210s典型问题记录Spark 在状态超过 500MB 后出现明显的 GC 停顿Flink 的增量检查点机制在大型状态下优势明显测试中 Spark 出现了 3 次状态丢失需要手动恢复的情况4. 复杂事件处理(CEP)场景CEP 用于检测数据流中的复杂模式是风控和监控系统的核心需求。4.1 测试模式设计我们实现了一个信用卡欺诈检测规则模式序列 1. 同一卡号在10分钟内 2. 出现3笔以上交易 3. 交易金额均超过信用额度的80% 4. 且交易地点跨度过大Flink CEP 实现PatternTransaction, ? pattern Pattern.Transactionbegin(start) .where(new SimpleCondition() { Override public boolean filter(Transaction value) { return value.getAmount() creditLimit * 0.8; } }) .timesOrMore(3) .within(Time.minutes(10));Spark 实现 由于 Spark 原生不支持 CEP我们使用连续多个 SQL 查询模拟-- 第一步筛选大额交易 CREATE TEMP VIEW large_trans AS SELECT * FROM transactions WHERE amount credit_limit * 0.8; -- 第二步窗口内计数 SELECT card_no, COUNT(*) FROM large_trans GROUP BY card_no, window(timestamp, 10 minutes) HAVING COUNT(*) 3;4.2 性能对比复杂度Flink 吞吐量Spark 吞吐量延迟差异简单模式(3事件)45万/s28万/s1.6倍复杂模式(5事件)32万/s14万/s2.3倍超复杂模式18万/s4.5万/s4倍模式检测准确性Flink 准确检测到所有测试用例Spark 在事件乱序超过 30 秒时出现漏报对于跨多个窗口的模式Spark 实现复杂度呈指数增长5. 选型决策指南基于实测数据我们总结出以下决策树是否需要亚秒级延迟? ├── 是 → 选择 Flink └── 否: ├── 是否需要复杂状态管理? │ ├── 是 → 选择 Flink │ └── 否: │ ├── 是否已有Spark集群? │ │ ├── 是 → 考虑 Spark │ │ └── 否 → 选择 Flink └── 主要处理批分析? ├── 是 → 选择 Spark └── 否 → 选择 Flink特殊场景建议IoT 设备监控Flink 的低延迟特性更适合夜间报表生成Spark 的批处理模式更经济金融风控系统必须选择 Flink 以保证实时性数据湖 ETL两者均可取决于现有技术栈在实际项目中我们曾遇到一个电商大促场景Flink 在流量突增 10 倍时仍保持稳定而 Spark 需要动态调整批处理间隔才能跟上数据速率。这也印证了 Flink 在真正实时场景中的优势。
