026、流式计算：Kafka与Spark Streaming实时处理

一、深夜告警：数据延迟了15分钟

上周四凌晨两点，手机突然震个不停。监控系统告警：实时推荐引擎的数据流水线延迟超过15分钟。打开监控面板，Kafka消费者组的lag曲线像爬山一样往上窜，Spark Streaming的批处理时间已经超过窗口间隔。这不是第一次了，但这次特别棘手------业务方要求99.9%的消息必须在5秒内处理完毕。

先查了Spark UI，发现几个executor的GC时间占到了处理时间的40%。再翻Kafka consumer日志，看到频繁的rebalance记录。问题逐渐清晰：数据倾斜遇上配置不当，再加上序列化开销，整个管道就像早高峰的十字路口，堵死了。

二、Kafka：不只是个消息队列

很多人把Kafka当成加强版RabbitMQ用，这是第一个坑。Kafka的核心是分布式提交日志，它的设计目标是大规模、高吞吐的流数据持久化。

scala 复制代码

// 错误示范：每次消费都提交offset，性能杀手
consumer.poll(100).forEach { record =>
  process(record)
  consumer.commitSync()  // 别这样写！同步提交每个消息
}

// 建议写法：批量处理+异步提交
val records = consumer.poll(Duration.ofMillis(1000))
batchProcess(records)
consumer.commitAsync()  // 这里可以加回调处理提交失败

分区策略是关键。曾经有个项目，所有数据都发到同一个分区，因为key设成了常量。下游Spark任务只有一个task在干活，其他都在围观。

java 复制代码

// 分区数估算公式（经验值）
// 目标吞吐 = 单分区吞吐 * 分区数
// 单分区吞吐经验值：机械盘~10MB/s，SSD~30MB/s
// 建议：分区数 = 峰值吞吐 / 单分区吞吐 * 1.2（预留buffer）

三、Spark Streaming：微批处理的陷阱

Spark Streaming不是真正的流处理，而是微批处理。这个本质决定了它的行为模式。

scala 复制代码

// 窗口操作容易踩的坑
val stream = ssc.socketTextStream(...)
  .map(...)
  .window(Minutes(10), Minutes(5))  // 窗口长度10分钟，滑动间隔5分钟

// 注意：这里每个窗口包含的数据量是变化的
// 如果上游数据突发，OOM就来了

checkpoint目录配置不当会导致任务重启失败。曾经有同事把checkpoint放在HDFS默认路径，没设清理策略，最后磁盘写满，整个集群瘫痪。

scala 复制代码

ssc.checkpoint("hdfs://path/to/checkpoint")
// 一定要配置自动清理，比如：
sparkConf.set("spark.cleaner.ttl", "3600")

背压机制（backpressure）要打开，不然数据洪峰时直接打垮executor：

scala 复制代码

sparkConf.set("spark.streaming.backpressure.enabled", "true")
sparkConf.set("spark.streaming.kafka.maxRatePerPartition", "1000")  // 每分区最大速率

四、Kafka + Spark Streaming集成实战

两种集成方式：Receiver-based和Direct模式。现在基本都用Direct模式（createDirectStream），它更简单，也更容易保证Exactly-Once语义。

scala 复制代码

val kafkaParams = Map(
  "bootstrap.servers" -> "broker1:9092,broker2:9092",
  "key.deserializer" -> classOf[StringDeserializer],
  "value.deserializer" -> classOf[StringDeserializer],
  "group.id" -> "spark-streaming-group",
  "auto.offset.reset" -> "latest",  // 生产环境建议earliest，避免丢数据
  "enable.auto.commit" -> (false: java.lang.Boolean)  // 必须关掉！让Spark管理offset
)

val topics = Array("user_behavior")
val stream = KafkaUtils.createDirectStream[String, String](
  ssc,
  PreferConsistent,
  Subscribe[String, String](topics, kafkaParams)
)

// 手动维护offset到外部存储（如Redis、MySQL）
stream.foreachRDD { rdd =>
  val offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges
  // 处理业务逻辑
  processRDD(rdd)
  // 提交offset
  offsetRanges.foreach { range =>
    saveOffsetToStorage(range.topic, range.partition, range.untilOffset)
  }
}

这里有个细节：offset提交要在业务逻辑成功之后，但又要保证原子性。我们曾经遇到过处理成功但offset提交失败，导致数据重复消费。后来引入了事务表才解决。

五、调优笔记：从血泪教训中总结

序列化：用Kryo，别用Java原生序列化。配置时记得注册自定义类：

scala 复制代码

sparkConf.registerKryoClasses(Array(classOf[UserEvent], classOf[Order]))

并行度：Kafka分区数和Spark分区数最好保持1:1或整数倍关系。曾经设了60个Kafka分区，Spark却只有10个core，资源浪费严重。
内存管理：Streaming应用对内存敏感，建议单独设置executor内存模型：

bash 复制代码

--executor-memory 4G \
--conf spark.executor.memoryOverhead=1024 \
--conf spark.streaming.unpersist=true  # 自动清理已用过的RDD

监控指标：除了系统监控，一定要埋业务层的延迟统计。我们曾经系统指标一切正常，但业务延迟很高，最后发现是外部API调用超时。
失败恢复：测试各种失败场景------Kafka broker重启、Spark executor挂掉、网络分区。有个经验：先停掉Spark任务，往Kafka灌一批数据，再重启任务，检查offset是否从正确位置开始。

六、经验之谈：流式系统的哲学

流处理系统不是批处理的加速版，而是另一种编程范式。最大的思维转变是：从关注数据全集到关注数据变化。

调试流式作业，不要只盯着代码。去看Kafka的监控指标（ISR数量、网络出入流量）、Spark的GC日志、操作系统的IOwait。很多时候问题不在应用层。

生产环境一定要有熔断机制。我们现在的方案是：当延迟超过阈值，自动切换到一个降级处理路径（比如跳过复杂特征计算），保证数据至少能流动起来。

最后，流处理系统的复杂度是阶跃式上升的。从demo到POC再到生产，每跨一个阶段，要考虑的问题多一个数量级。建议循序渐进：先保证数据能流起来，再优化延迟，最后追求Exactly-Once语义。别想一步到位，那会掉进无数个坑里爬不出来。

七、写在最后

实时流处理就像维护一条高速运转的流水线，任何一个环节的微小卡顿都会累积成整个系统的延迟。最好的学习方式不是读文档，而是亲手搭一套环境，然后模拟各种故障场景。

保持对数据的敬畏------它不会按你设想的方式到来，总是在你最困的时候给你惊喜。做好监控，写好日志，留好降级路径。毕竟，凌晨三点的告警电话，谁都不想接第二次。