📚 课程目录第4章实时计算引擎选型

实时计算引擎选型：Flink vs Spark Streaming vs Kafka Streams

数据质量监控一旦上了规模，批处理就扛不住了。你需要实时算延迟、算成功率、算数据漂移——这些都得在秒级出结果。选哪个引擎？我这些年三个都用过，踩了不少坑，今天跟你聊聊我的真实感受。

核心观点：没有最好的引擎，只有最合适的场景。选型前先想清楚三个问题——你的数据源是什么？延迟要求多高？团队熟悉哪种生态？

三驾马车：各自擅长的领域

先给个全景图，让你心里有个底。

Flink：数据质量监控的主力军

我个人习惯把 Flink 放在第一位。为什么？因为它天生就是为事件驱动设计的。数据质量监控里最常见的场景——滑动窗口算成功率、滚动窗口算延迟分布——Flink 做起来得心应手。

举个例子。你要监控 API 接口的 5 分钟成功率，每 10 秒更新一次。Flink 的 SlidingEventTimeWindows 直接搞定，代码量很少：

DataStream<ApiLog> logs = env.addSource(kafkaConsumer);

logs
  .keyBy(log -> log.getApiName())
  .window(SlidingEventTimeWindows.of(
      Time.minutes(5),   // 窗口大小
      Time.seconds(10)   // 滑动步长
  ))
  .aggregate(new SuccessRateAggregator())
  .addSink(new AlertSink());

我在项目中遇到过一个问题：数据乱序导致窗口计算结果不准。Flink 的 watermark 机制可以处理，但需要你合理设置乱序容忍时间。我曾经因为 watermark 设得太小，导致高峰期丢了 3% 的数据——嗯，后来改成 forBoundedOutOfOrderness(30.seconds) 才稳住。

我的建议：如果你的数据质量规则复杂——比如需要多流 Join、状态回溯、CEP 模式匹配——直接选 Flink。它在这方面的成熟度是另外两个没法比的。

Spark Streaming：批流一体的老大哥

Spark Streaming 的核心是微批次（Micro-Batch）。说白了就是把实时流切成一个个小批次，然后用 Spark 的批处理引擎去算。这个设计有好有坏。

好处很明显：生态丰富。Spark SQL、MLlib、GraphX 都能用。如果你团队本来就熟悉 Spark，上手成本很低。

坏处也明显：延迟高。微批次再小也有调度开销。我见过有人把批次间隔设成 500ms，结果集群资源全耗在调度上了，实际吞吐反而下降。

数据质量监控里，Spark Streaming 适合什么场景？我个人觉得是那些需要同时做实时和离线计算的场景。比如你既要算 5 分钟的实时成功率，又要跑 T+1 的历史趋势分析——用 Spark 一套代码搞定。

val stream = SparkSession.builder
  .appName("DataQualityMonitor")
  .getOrCreate()
  .readStream
  .format("kafka")
  .option("subscribe", "api-logs")
  .load()

stream
  .selectExpr("CAST(value AS STRING)")
  .as[String]
  .groupBy(
    window($"timestamp", "5 minutes", "10 seconds"),
    $"api_name"
  )
  .agg(
    avg($"latency").as("avg_latency"),
    count(when($"status" === 200, 1)).as("success_count"),
    count("*").as("total_count")
  )
  .writeStream
  .outputMode("update")
  .format("console")
  .start()

注意：Spark Streaming 的 Structured Streaming 虽然支持事件时间，但 watermark 机制不如 Flink 灵活。如果你对乱序数据的容忍度要求很高，建议先做压力测试。

Kafka Streams：轻量级的选择

Kafka Streams 是个另类。它不需要独立的集群，就是一个 Java 库，嵌在你的应用里跑。我刚开始用的时候也觉得不靠谱——没有集群怎么保证高可用？后来发现它靠 Kafka 自身的分区和复制机制来实现容错。

它的优势在哪？轻、快、简单。如果你的数据质量监控逻辑不复杂——比如就是算个平均值、最大值、计数——Kafka Streams 完全够用。而且延迟极低，毫秒级。

但要注意，Kafka Streams 的状态管理能力有限。复杂的窗口聚合、多流 Join 做起来比较吃力。我曾经试过用它做 3 个流的 Join，结果状态存储膨胀得厉害，最后不得不切回 Flink。

KStream<String, ApiLog> logs = builder.stream("api-logs");

logs
  .groupBy((key, log) -> log.getApiName())
  .windowedBy(TimeWindows.of(Duration.ofMinutes(5))
      .advanceBy(Duration.ofSeconds(10)))
  .aggregate(
      SuccessRate::new,
      (key, log, rate) -> rate.update(log),
      Materialized.<String, SuccessRate, WindowStore<ByteArray, byte[]>>as(
          "success-rate-store")
  )
  .toStream()
  .to("success-rate-output");

适用场景：如果你的数据质量监控是 Kafka 原生生态的一部分，而且逻辑简单——比如监控某个 Topic 的消息延迟、空值率——Kafka Streams 是最省心的选择。部署简单，运维成本低。

选型对比：一张表说清楚

维度	Flink	Spark Streaming	Kafka Streams
延迟	百毫秒级	秒级（微批次）	毫秒级
状态管理	强（RocksDB + 增量快照）	中（基于 Checkpoint）	弱（本地状态存储）
精确一次语义	原生支持	支持（需配置）	支持（依赖 Kafka 事务）
生态集成	丰富（Connector 多）	非常丰富（Spark 全家桶）	有限（Kafka 原生）
运维复杂度	高（独立集群）	高（独立集群）	低（无集群）
学习曲线	陡	中（熟悉 Spark 则低）	平
数据质量监控适用度	★★★★★	★★★★	★★★

实战场景：我怎么做选型

给你三个真实场景，你看看自己属于哪一种。

场景一：复杂规则引擎

你需要监控几十个 API 的延迟、成功率、数据完整性，规则还在不断迭代。我建议选 Flink。它的 CEP 库和状态 API 能让你灵活地定义规则，而且支持动态更新——不用重启作业就能改规则。

场景二：批流一体平台

你们团队已经有 Spark 平台了，数据质量监控只是其中一部分。那就用 Spark Streaming。别为了一个场景再搭一套 Flink 集群——运维成本翻倍，不值当。

场景三：轻量级管道监控

你只需要监控 Kafka 消息的延迟、空值率、格式正确性。别折腾了，Kafka Streams 一把梭。我曾经在一个小团队里用 Kafka Streams 搭了整套数据质量监控，三个人维护了两年，没出过大问题。

我的经验：选型时别只看技术指标。团队能力、运维成本、现有生态——这些往往比延迟差几百毫秒更重要。你想想看，一个没人能维护的 Flink 作业，延迟再低有什么用？

避坑指南

不要迷信精确一次语义。 我曾经为了追求精确一次，把 Flink 的 checkpoint 间隔设得太短，结果频繁快照导致性能下降 30%。后来改成 30 秒一次，配合 Kafka 的幂等生产者，效果一样好。
注意状态存储的容量。 数据质量监控里经常要存窗口状态。如果窗口大、数据量大，RocksDB 的磁盘占用会飙升。我遇到过 100GB 状态把磁盘撑爆的情况——后来加了状态 TTL 才解决。
Kafka Streams 不适合复杂拓扑。 如果你的 DAG 超过 5 个节点，或者有循环依赖，别用 Kafka Streams。调试起来会让你怀疑人生。
Spark Streaming 的背压机制不如 Flink。 高峰期数据量暴增时，Spark 的背压反应慢，容易导致 OOM。我建议在 Spark Streaming 里手动限流，别全指望自动背压。

好了，选型这块就聊到这儿。记住一句话：选引擎不是选最好的，是选最合适的。 你的数据量、延迟要求、团队能力——这三个因素决定了最终答案。