Spark Streaming之Kafka的Receiver和Direct方式

云计算 waitig 734℃ 百度已收录 0评论

一 Receiver方式

Receiver是使用Kafka的high level的consumer API来实现的。Receiver从Kafka中获取数据都是存储在Spark Executor内存中的,然后Spark Streaming启动的job会去处理那些数据

 

然而这种方式很可能会丢失数据,如果要启用高可靠机制,让数据零丢失,就必须启动Spark Streaming预写日志机制。该机制会同步地接收到Kafka数据写入分布式文件系统,比如HDFS上的预写日志中。所以底层节点出现了失败,也可以使用预写日志的数据进行恢复

 

二 Direct方式

它会周期性的查询kafka,来获取每个topic + partition的最新offset,从而定义每一个batch的offset的范围。当处理数据的job启动时,就会使用kafka简单的消费者API来获取kafka指定offset的范围的数据

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

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

# 一次仅且一次的事务机制

基于Receiver的方式,是使用Kafka High Level的API在zookeeper中保存消费过的offset的。这是消费kafka数据的传统方式,这种方式配合这WAL机制可以保证数据零丢失,但是无法保证数据只被处理一次的且仅且一次,可能会两次或者更多,因为spark和zookeeper是不可能同步的。

低于Direct的方式,使用kafka简单API, SparkStreaming负责追踪消费的offset,并且保存在checkpoint中。因此可以保证数据消费一次仅仅一次

 


本文由【waitig】发表在等英博客
本文固定链接:Spark Streaming之Kafka的Receiver和Direct方式
欢迎关注本站官方公众号,每日都有干货分享!
等英博客官方公众号
点赞 (0)分享 (0)