Spark Streaming源码解读之No Receivers彻底思考

本期内容 :

  • Direct Acess
  • Kafka

  Spark Streaming接收数据现在支持的两种方式:

  01、 Receiver的方式来接收数据,及输入数据的控制

  02、 No Receiver的方式

  以上两种方式中,No Receiver的方式更符合读取、操作数据的思路,Spark作为一个计算框架他的底层有数据来源,也就是直接操作数据来源中的数据,

  如果操作数据来源的话肯定需要一个封装器,这个封装的类型一定是RDD的封装类型,Spark Streaming为了封装类型推出了自定义的RDD是KafkaRDD。

一、  No Receivers:   

  基于Spark Streaming的Bach-Oriented接口是在Kafka消费数据的一个实现,实现需要确定开始与结束的Offset(数据偏移量),Broker是Kafka中的概念,

  也就是Spark Streaming直接去操作Kafka中的数据。

  

  

 

  在ForEachRDD中可以获取OffsetRanges中产生所有分区的数据,即对源数据的控制。

  

  

  

封装了一个与Kafka的交互而已。

  

  

 

二、 DirectKafkaInPutDStreams :

  在实际运行的时候会产生KafkaRDD ,不同的Topic对应不同生成的Partition ,RatePerPartition控制了每秒所能够消费数据的速度,交互接口是KafkaCluster

  

 KafkaRDD本身包含很多Partition ,他有多少Partition就对应多少KafkaPartition

  

作为一个KafkaPartition 核心的方法就是消费多少数据,而且KafkaRDD的一个Partition只能属于一个Topic的,其实一般就是直接消费了一个Kafka的Topic

  

是从KafkaRDD的角度看,下一步就是读取数据。

  

  

直接抓Kafka数据的方式与Receiver的方式的实际价值 :

  1、 Direct的方式读取数据,因为Direct是没有缓存的,也就是不存在内存溢出等问题,

  2、 使用Receiver的方式去读取数据是存在缓存问题

  2、 使用Direct的方式,KafkaRDD默认数据就是分布在多个Executor ,KafkaRDD默认就是分布式的

  3、 使用Receiver的方式,默认情况下是和具体的Worker的Executor绑定了,Receiver方式是不方便做分布式,但是需要配置才可以做分布式的

  4、如果是Direct方式是直接读取Kafka数据,Dream多少次都无所谓,如果Dream就不会再进行下一步的处理了

  5、 使用Receiver方式,如果数据来不及处理,也就是数据操作Dream,如果操作多次Spark程序可能程序崩溃

 

原文地址:https://www.cnblogs.com/yinpin2011/p/5539822.html