Spark Streaming与kafka集成有以下两种接收数据的方式：

  1. 基于Receiver的方式
  2. 基于Direct的方式

基于Receiver方式

java kafka consumer 获取offset kafka获取数据_数据

特点：

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

优点：

基于Receiver方式读取数据，用户可以专注于所读数据，而不用关注或维护consumer的offsets，这减少了用户的工作以及代码量，而且相对比较简单

基于Direct(No Receiver)方式

java kafka consumer 获取offset kafka获取数据_数据_02

特点：

  1. 不需要使用单独的Receiver线程从Kafka获取数据。
  2. 使用Kafka简单消费者API,不需要ZooKeeper参与，直接从Kafka Broker获取数据。
  3. 执行过程:Spark Streaming Batch Job触发时，Driver端确定要读取的Topic-Partition的OffsetRange，然后由Executor并行从Kafka各Partition读取数据并计算。
  4. 为保证整个应用EOS， Offset管理一般需要借助外部存储实现。如Mysql、HBase等。
  5. 由于不需要WAL，且Spark Streaming会创建和Kafka Topic Partition一样多的RDD Partition,且一一对应，这样,就可以并行读取，大大提高了性能。
  6. Spark Streaming应用启动后，自己通过内部currentOffsets变量跟踪Offset，避免了基于Receiver的方式中Spark Streaming和Zookeeper中的Offset不一致问题。

与基于Receiver的比较：

优点：

1.简化并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对他们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从kafka中读取数据。所以在kafka partition和RDD partition之间，有一一对应的关系。

2.高性能：如果要保证数据零丢失，在基于Receiver的方式中，需要开启WAL机制。这种方式其实效率很低，因为数据实际被复制了两份，kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于Direct的方式，不依赖于Receiver，不需要开启WAL机制，只要kafka中做了数据的复制，那么就可以通过kafka的副本进行恢复。

3.强一致语义：基于Receiver的方式，使用kafka的高阶API来在Zookeeper中保存消费过的offset。这是消费kafka数据的传统方式。这种方式配合WAL机制，可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和Zookeeper之间可能是不同步的。基于Direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据时消费一次且仅消费一次。

4.降低资源：Direct不需要Receiver，其申请的Executors全部参与到计算任务中；而Receiver则需要专门的Receivers来读取kafka数据且不参与计算。因此相同的资源申请，Direct能够支持更大的业务。Receiver与其他Executor是异步的，并持续不断接收数据，对于小业务量的场景还好，如果遇到大业务量时，需要提高Receiver的内存，但是参与计算的Executor并不需要那么多的内存，而Direct因为没有Receiver，而是在计算的时候读取数据，然后直接计算，所以对内存的要求很低。

5.鲁棒性更好：基于Receiver方式需要Receiver来异步持续不断的读取数据，因此遇到网络、存储负载等因素，导致实时任务出现堆积，但Receiver却还在持续读取数据，此种情况容易导致计算崩溃。Direct则没有这种顾虑，其Driver在触发batch计算任务时，才会读取数据并计算，队列出现堆积并不不会引起程序的失败。

缺点：

1.Direct方式需要采用checkpoint或者第三方存储来维护offset，而不是像Receiver那样，通过Zookeeper来维护offsets，提高了用户的开发成本。

2.基于Receiver方式指定topic指定consumer的消费情况均能够通过Zookeeper来监控，而Direct则没有这么便利，如果想做监控并可视化，则需要投入人力开发。

参考：

  1. https://zhuanlan.zhihu.com/p/52280041