获课：xingkeit.top/5570/

Spark Streaming 对接 Kafka：底层消费机制与参数配置实战

Kafka 负责搬运数据，Spark Streaming 负责消化数据——这是实时计算领域最经典的搭档。但这对搭档能不能配合好，取决于你是否真正理解 Spark Streaming 消费 Kafka 的两套底层机制，以及关键参数该怎么调。

一、两种消费机制：Receiver 已死，Direct 当立

Receiver 方式（传统）：Spark 开一个 Receiver 线程，用 Kafka 高级 Consumer API 拉数据，全部塞进 Executor 内存。问题一堆——数据量一暴就内存溢出，默认配置下故障会丢数据。要保零丢失？得开 WAL（预写日志），数据同时写一份到 HDFS，Kafka 存一份、HDFS 存一份，资源浪费严重。更致命的是，offset 存 ZooKeeper，Spark 消费进度和 ZK 记录不同步，偶尔数据重复消费。

Direct 方式（推荐，Spark 1.3+ 引入）：没有 Receiver 这一层。Spark 周期性地主动查询 Kafka 每个 partition 的最新 offset，定义好批次范围后，用 Kafka 低级 API 直接拉取指定 offset 区间的数据。offset 不再依赖 ZK，而是由 Spark 自身的 checkpoint 记录，彻底消除了不同步导致的重复消费问题。Kafka partition 和 RDD partition 一一对应，并行关系清晰，调优直觉明确。

一句话总结：Receiver 是"别人喂我吃"，Direct 是"我自己去拿"。 生产环境请直接用 Direct，Receiver 方式在 spark-streaming-kafka-0-10 中已不再支持。

二、五个核心参数，决定稳定性

反压机制是生产环境的命根子。当 HBase 写入延迟、ES 响应变慢时，反压会自动把 maxRatePerPartition 往下压。某电商项目实测：HBase 出问题时，反压把每批数据量从 10000 条压到约 1000 条，系统稳住了；HBase 恢复后自动回升。

三、Offset 管理：三条路选一条

第一条：Spark checkpoint（最常用）。 Offset 随 checkpoint 一起存 HDFS，重启后精确恢复。缺点是改了代码就无法从旧 checkpoint 启动。

第二条：Kafka 自身 offset topic。 设置 enable.auto.commit=false，offset 写到 Kafka 内部 topic。好处是不受代码变更影响，但 Kafka 不支持事务，输出必须幂等。

第三条：手动更新 ZK。 每个批次拿到处理完的 offset，自己写回 ZK。最灵活，但维护成本最高。

四、一句话总结

用 Direct 方式，开反压，控好 maxRatePerPartition，offset 交给 checkpoint。这四件事做到位，Spark Streaming 吃 Kafka 就像刀切豆腐——稳、准、快。