工具篇-Spark-Streaming获取kafka数据的两种方式(转载)

时间:2021-09-11 03:01:52

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

一、基于Receiver的方式

工具篇-Spark-Streaming获取kafka数据的两种方式(转载)

原理

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自己一定是同步的,因此可以保证数据是消费一次且仅消费一次。