转载自：https://blog.csdn.net/weixin_41615494/article/details/7952173

一、基于Receiver的方式

原理

Receiver从Kafka中获取的数据存储在Spark Executor的内存中，然后Spark Streaming启动的job会去处理那些数据，如果突然数据暴增，大量batch堆积，很容易出现内存溢出的问题。 
在默认的配置下，这种方式可能会因为底层失败而丢失数据。如果要让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL），该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。

要点

1. Kafka中Topic的Partition与Spark中RDD的Partition没有关系。所以，在KafkaUtils.createStream()中，提高partition的数量只会增加一个Receiver中读取Partition线程的数量，不会增加Spark处理数据的并行度。可以创建多个Kafka输入DStream，使用不同的Consumer Group和Topic，来通过多个Receiver并行接收数据。

2. 如果基于容错的文件系统，比如HDFS，启用了预写日志机制，接收到的数据都会被复制一份到预写日志中。此时在KafkaUtils.createStream()中，设置的持久化级别是StorageLevel.MEMORY_AND_DISK_SER。

二、基于Direct的方式

原理

该方式在Spark 1.3中引入，来确保更加健壮的机制。这种方式会周期性地查询Kafka，获取每个Topic+Partition的最新的Offset，从而定义每个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。

优点

1. 简化并行读取：在Kafka Partition和RDD Partition之间，有一个一对一的映射关系，所以如果要读取多个partition，不需要创建多个输入DStream然后对它们进行Union操作，Spark会创建跟Kafka Partition一样多的RDD Partition，并且会并行从Kafka中读取数据。 
2. 高性能：如果要保证零数据丢失，在基于Receiver的方式中，需要开启WAL机制，这种方式数据实际上被复制了两份效率低下，Kafka自己本身就有高可靠的机制，会对数据复制一份。而基于Direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，就可以通过Kafka的副本进行恢复。

对比（在实际生产环境中大都用Direct方式）：

基于Receiver的方式，使用Kafka的高阶API在ZooKeeper中保存消费过的offset的，这是消费Kafka数据的传统方式。这种方式配合WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会重复处理。因为Spark和ZooKeeper之间可能是不同步的。

基于Direct的方式，使用Kafka的简单API，Spark Streaming自己就负责追踪消费的Offset，并保存在Checkpoint中，Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。