Spark Streaming从Kafka中读数据的两种方式

   Spark Streaming流式处理kafka中的数据，首先是把数据接收过来，然后转换为Spark Streaming中的数据结构DStream。接收数据的方式有两种：利用Receiver接收数据 与 Direct。

基于Receiver的方式
流程：
  Receiver是使用Kafka高阶API接口实现的。Receiver从 Kafka获取的数据都是存储在 Executor内存的，然后Spark Streaming启动的 job 会去处理这些数据。用这种方式来与 Kafka 集成，配置中设置了 enable.auto.commit为 true，表明自己不需要维护 offset，而是由 Kafka 自己来维护（在 Kafka 0.10 后，默认的 offset 存储位置改为了 Kafka，实际上就是 Kafka 的一个 topic），Kafka 消费者会周期性地（默认为 5s）去修改偏移量。

问题：
  这种方式接收的数据都保存在 Receiver 中，此方法可能会在失败时丢失数据。为确保零数据丢失，必须在Spark Streaming中另外启用预写日志 （Write Ahead Log） 。这将同步保存所有收到的Kafka数据到分布式文件系统（例如HDFS）上，以便在发生故障时可以恢复所有数据。
  数据从 Kafka 取出后，进行了 WAL，在这个时候，Driver 与 Executor 因为某种原因宕机，这时最新偏移量还没来得及提交，那么在 Driver 恢复后，会从记录的偏移量继续消费数据并处理 WAL 的数据，这样一来，被 WAL 持久化的数据就会被重复计算一次。因此，开启了 WAL 后，这样的容错机制最多只能实现“至少一次”的消息送达语义。而且开启 WAL 后，增加了 I/O 开销，降低了 Spark Streaming 的吞吐量，还会产生冗余存储。

注意点：
   在Receiver的方式中，Kafka中的topic partition与Spark Streaming中生成的RDD partition无关。所以如果加大每个topic的partition数量，仅仅是增加线程来处理由单一Receiver消费的主题。但是这并没有增加Spark在处理数据上的并行度。
   对于不同的Group和topic可以使用多个Receiver创建不同的Dstream来并行接收数据，之后可以利用union来统一成一个Dstream。
   如果启用了Write Ahead Logs复制到文件系统如HDFS，那么storage level需要设置成 StorageLevel.MEMORY_AND_DISK_SER，即KafkaUtils.createStream(…,StorageLevel.MEMORY_AND_DISK_SER)。

特点

• 需要使用单独的Receiver线程来异步获取Kafka数据
• Receiver底层实现中使用了Kafka高级消费者API,因此,不需要自己管理Offset,只需指定Zookeeper和消费者组GroupID,系统便会自行管理
• 执行过程: Spark Streaming启动时，会在Executor中同时启动Receiver异步线程用于从Kafka持续获取数据，获取的数据先存储在Receiver中(存储方式由StorageLevel决定)，后续，当Batch Job触发后，这些数据会被转移到剩下的Executor中被处理。处理完毕后，Receiver会自动更新Zookeeper中的Offset
• 默认情况下,程序失败或Executor宕掉后可能会丢失数据，为避免数据丢失，可启用预写日志(Write Ahead Log,WAL)。将Receiver收到的数据再备份一份到更可靠的系统如HDFS分布式文件中，以冗余的数据来换取数据不丢失
• 生产下，为保证数据完全不丢失，一般需要启用WAL。启用WAL，在数据量较大，网络不好情况下，会严重降低性能

直接读取方式（ Direct Stream方法）
流程：
  这种方法不使用接收器（Receiver）