Spark对kafka两种连接方式的对比

Spark对于Kafka的连接主要有两种方式,一种是(直连方式)DirectKafkaInputDStream,另一种是KafkaInputDStream.DirectKafkaInputDStream只在driver端接收数据,所以继承了InputDStream,是没有receivers(接收器的方式)的

使用Receiver的方式有以下好处:

简化并行:不再需要创建多个kafka input DStream然后再union这些input DStream.使用directStream,spark Streaming会创建与Kafkapartitions相同数量的partitions的RDD,RDD的partition与Kafka的partition一一对应,这样更易于理解及调优

高效:在方式一中要保证零数据丢失需要启动WAL(预写日志),这会占用更多空间.而在方式二中,可以直接从Kafka指定的topic的指定offsets处恢复数据,不再需要使用WAL

恰好一次语义保证:基于Receiver方式使用了Kafka的highlevelAPI来在Zookeeper中消费已消费的offsers.这在某些情况下会导致一些数据被消费两次,比如streaming app在处理某个batch内已接收到的数据的过程中挂掉,但是数据已经处理了一部分.但这种情况下无法将已经处理数据的offsets更新到Zookeeper中,下次重启时,这批数据将再次被消费且处理.基于direct的方式,使用kafka的简单api,SparkStreaming自己就负责追踪消费的offset,并保存在checkpoint中.Spark自己一定是同步的,因此可以保证数据时消费一次且仅消费一次.这种方式中,只要将output操作和保存offsets操作封装成一个原子操作就能避免失败后的重复消费和处理,从而达到恰好一次有语义(Exactly-once)

上述分析总结:

1.createStream会使用Receiver;而createDirectStream不会

2.createStream使用Receiver会分发到某个executor上去启动并接受数据;而createDirecrtStream直接在driver上接收数据(直连方式)

3.createStream使用Receiver源源不断的接收数据并把数据交给ReceiverSupervisor处理最终存储为blocks作为RDD的输入,从kafka拉取数据与计算消费数据相互独立;而createDirectStream会在每个batch拉去数据并就地消费,到下个batch再次拉取消费,周而复始,从kafka拉去数据与计算消费数据是连续的,没有独立分开

4.createStream中创建的KafkaInputDStream每个batch所对应的RDD的partition不与Kafkapartition一一对应;而createDirectStream中创建的DirectKafkaInputDStream每个batch所对应的RDD的partition与Kafka partition一一对应