SparkStreaming 有几种方式消费 Kafka 中的数据（与 kafka 集成的方式）

1. 基于 Receiver 的方式
   Reciever 的问题是 offset 都会存到zk中，容易造成zk压力过大，而且 Reciever 获取数据和处理数据的线程不是同一批，可能会导致数据的积压，数据存储是在Spark executor的内存中，大量数据积压容易导致OOM的情况，为了数据不丢失，还需要启动预写日志机制，把 Kafka 数据同步写入到 HDFS 中。虽然可以保证数据零丢失但是无法实现 exactly-once（只执行一次）语义，因为 Spark 和 Zk 之间可能不同步。

2. 基于 Direct 的方式
   会周期性地查询 Kafka，来获得每个 topic + partition 的最新 offset，从而定义每个 batch 的 offset 范围，当处理数据的 job 启动是，会使用 Kafka 的简单 consumer api 来获取 Kafka 指定 offset 范围的数据，可以保证输入端数据 exactly-once 语义（保存在 checkpoint，Spark 自己一定是同步的）。要保证数据的不丢失，不需要再启动预写日志机制，因为 Kafka 如果本身做了副本，就可以通过 Kafka 副本进行恢复。