sparkStreaming消费kafka数据的两种方式（Receiver和Direct）详解及区别

spark Streaming读取kafka数据的两种方式：

（1）receiver-base

Receiver模式是使用kafka的高层次的消费者api来实现的，这种方式是使用receiver不间断的来接收数据（push的模式），接收的数据会存储到Executor中（默认存储级别是内存满后写入磁盘），然后sparkStreaming启动作业去处理数据，处理完这一批数据之后，更新zookeeper中保存的kafka的topic的分区的偏移量。

优点：

（1）这种方式需要开启WAL机制，接收的数据复制一份到WAL日志中，可以保证数据不丢失，但 是效率低了

（2）操作简单方便，不需要自己管理offset

缺点：

（1）无法保证数据只被处理一次：如果在写入外部存储的数据还没有将offset更新到zookeeper就挂掉了，这些数据会重复消费。

（2）kafka的topic分区和spark Streaming中生成的RDD分区是不相关的：因此，增加topic的分区数量只会增加reciver内部接收数据的线程数，并不会增加spark处理数据的并行度。

（2）Direct

Direct方式采用Kafka简单的消费者api方式来读取数据，此种方式不再需要专门Receiver来持续不断读取数据。定期查询topic的partition的最新的偏移量，Executor并依据此决定每个batch要接收的offset范围，拉取到的数据供sparkStreaming处理。

优点:

（1）降低内存：Direct方式的数据消费是计算时读取数据，然后直接计算，只需要考虑批量计算所需要的内存即可。而reciver方式需要一直接收数据，如果有大量数据涌入，需要扩大内存

（2）恰好依次语义：Spark Streaming自己就负责追踪消费的offset, 并保存在checkpoint中，Spark自己一定是同步的, 因此可以保证数据是消费一次且仅消费一次。

（3）高效：与reciver方式保证数据零丢失启用WAL（预写日志），会降低程序性能。Direct的方式可以直接从kafka指定topic的指定offset处恢复数据。

（4）简化并行：kafka中partition和RDD中的partition是一一对应的，更易于理解和调优

缺点：

（1）提高成本。Direct需要用户采用checkpoint或者第三方存储来维护offsets，而不像Reciver方式zookeeper来维护offset，提高了用户的开发成本。

（2）监控可视化：reciver方式指定topic的消费情况可以通过zookeeper来监控，而Direct没有那么方便，需要人力开发。