SparkStreaming两种从Kafka中接收数据的方式

1.基于Receiver（接收器）的方式:

使用Receiver来接收Kafka中的数据。Receiver是一个基于Kafka高级消费者API实现的，对于所有接收器来说,这些接收器都是通过Receiver来接收Kafka中的数据并保存数据到 Spark的executor中,之后通过SparkStreaming启动Job来处理这些数据。 然而在默认的配置下,这种方式在某些异常情况下回出现数据丢失情况,为了确保数据的零丢失,需要在SparkStreaming中开启(Write Ahead Logs)预写日志。它能够确保将所有从Kafka中接收到的数据都预写到分布式文件系统的(write ahead logs)中。所以在异常情况下能够从预写日志中恢复数据。

编程:
import org.apache.spark.streaming.kafka._
val kafkaStream = KafkaUtils.createStream(
streamingContext,//spark上下文对象
[ZK quorum], //zk连接
[consumer group id], //消费者组
[per-topic number of Kafka partitions to consume]//每个消费者消费的分区数(最好一个消费者对应一个分区)
)

记忆点:

(1)Kafka的topic中的分区个数与SparkStreaming中生成的RDD中的分区个数是没有关系
的。通过:
val kafkaStreams = (1 to 10).map(i => {
val iDStream = KafkaUtils.createStream()
iDStream…
…
})

val unifiedStream = sc.union(kafkaStreams)

unifiedStream.print()
创建多个接收器,只是增加了接收器的线程个数,并没有增加
SparkStreaming处理数据的并行度。
(2)如果你已经开启(Write Ahead Logs)预写日志,日志存放在做了副本的HDFS
文件系统中,接收器接收到的数据已经备份到预写日志中了,相当于对数据做了两次备份
(一次是在预写日志中,第二次是在Spark中)会一定程度上降低效率。存储级别设置为
StorageLevel.MEMORY_AND_DISK_SER。
例如:KafkaUtils.createStream(…, StorageLevel.MEMORY_AND_DISK_SER)

2.直接Direct方式:

1 在Spark1.3的时候提出的一种不需要接收器,而是直接的方式接收Kafka中的数据,保证了数据
传输的可靠性。取代了使用接收器的方式接收数据,这种方式会周期性的查询Kafka中每个主题下****每个
分区中的最新的偏移量,因此定义偏移量的范围在每个批次当中去处理。当Job启后处理数据的时候,Kafka的低级消费者API从Kafka中读取定义好的范围的偏移量。

这种直接的方式相比接收器Receiver方式具有以下优势:
(1)简化并行度。
使用直接的接收方式不需要向Receiver接收器接收一样需要创建多个输入流并关联它们。
用directStream(直接流)这种方式,Spark Streaming将创建分区个数和Kafka主题中分区数一样的RDD
(DStream底层就是RDD),接下来directStream输入流将使用并行的方式从Kafka中读取数据。所以在Kafka中的分区数与Spark中RDD分区数存在一对一的映射关系。
(2)高效。
使用Receiver接收器接收方式开启预写日志能够保证零数据的丢失,并且接收器也进一步复制了数据,事实上这种接收器的方式接收数据效率是低下的,因为数据事实上被复制了两次:第一次是由Kafka低级API消费数据并保存到Spark中的内存中;第二次是由预写日志。直接接收的方式避免这个问题,因为它没有使用接收器,因此不需要Write Ahead Logs(预写日志)。只要Kafka中有滞留的数据,则就能从Kafka中恢复数据。
(3)恰好消费一次。
Receiver接收器的方式是使用Kafka高级消费者API,将消费的偏移量保存在zookeeper中,这是一种传统的从kafka中消费数据的方式。但是Receiver接收器(结合预写日志)的方式也只能保证数据的零丢失(至少一次),在某些失败的情况下可能会重复消费数据两次(比如网络延迟造成消费偏移量提交失败)。这种情况发生是由SparkStreaming接收数据的能力与zookeeper跟踪消费偏移量的能力不一致造成的。因此用第二种Direct****直接接收的方式,使用的是Kafka低级的消费者API而不使用zookeeper,消费的偏移量由SparkStreaming内部的checkpoint跟踪,这样的话就消除了Spark、Kafka、Zookeeper之间的的不一致性,所以每条记录由SparkStreaming有效的恰好接收一次,目的是为了实现你的输出结果恰好输出一次,你的输出操作(保存数据到外部数据源)一定是幂等的或者是一个原子性的事物操作(保存数据与偏移量一定是在一个事物中)。
缺点:
不能通Kafka监控工具来监听消费情况