Spark Streaming源码解读之生成全生命周期彻底研究与思考

本期内容 :

  • DStream与RDD关系彻底研究
  • Streaming中RDD的生成彻底研究

  

  问题的提出 :

  1、 RDD是怎么生成的,依靠什么生成

  2、执行时是否与Spark Core上的RDD执行有什么不同的

  3、 运行之后我们要怎么处理

    为什么有第三点 : 是因为Spark Streaming 中会随着相关触发条件,窗口Window滑动的时候都会不断的产生RDD ,

  从最基本的层次考虑,RDD也是基本对象,每秒会产生RDD ,内存能不能完全容纳,每个处理完成后怎么进行管理?

  

一、 整个Spark Streaming操作的InPutDStream的流程源码

   

   

   

   

   

  ForEachDStreams的产生有两种方式 :

  1、 一种是DStreams 的Action,这是作业的产生且执行

  2、 ForEachRDD也会产生ForEachDStreams,如果在ForEachRDD中没有Action级别的操作的话是不会执行作业的,

  ForEachDStreams 不一定会触发Job的执行,但是一定会触发Job的产生,这句话是假的,因为是需要定时器Time与业务逻辑代码来产生的

  

  ForEachDStreams 与Job的关系 :

  1、 ForEachDStreams 与Job是否执行实际上是没有什么关系的,不一定触发Job的执行

  2、 有ForEachDStreams的时候会产生Job ,这句话是假的,在没有ForEachDStreams的时候也会继续产生Job

  Job的产生与业务逻辑代码没有什么关系,只是跟框架的调度,框架的定时器时间到了就会产生Job

  

  

  ForEachRDD是Spark RDD的后门,因为其是直接对RDD进行操作,但是背后还是封装成了ForEachStream,实际上在流处理中直接对RDD进行操作,但是本身还是产生了DStreams,在这个Spark Streaming的逻辑操作中,我们看到的都是对DStreams进行操作,其实就是对DStreams进行操作就是对RDD进行操作,DStreams就是RDD的一套模板,后面的DStreams对前面的DStreams有依赖。

  为什么说后面的DStreams对前面的DStreams有依赖呢?源码如下:

  

  

  

  DStreams依赖以其它的DStreams ,除了第一个DStreams ,因为其是数据源产生的。

  基于DStreams是怎么产生RDD ,是时间Time通过函数来产生的RDD ,是RDD的模板。

  要研究RDD到底是怎么生成的 ,查看整个DStreams的操作,肯定有地方触发使RDD的生成,根据源码的路径跟踪RDD到底是怎么生成的 ?

  

  RDD的生命周期 : 均是后面依赖前面,每一步都会产生DStreams实例,DStreams是RDD的模板

  为什么DStreams是从后面依赖前面的呢? DStreams必须是后往前依赖,有三点目的:

  1、 是代表Spark Streaming级别的业务逻辑操作

  2、 目的是根据这个生成RDD ,而RDD就是从后往前依赖的

  3、 DStreams是lazy级别的,lazy级别是从后往前依赖奠定了基础

  最重要的原因是第二点,DStreams的依赖必须要与RDD的依赖保持高度的一致,因为要根据时间间隔去生成RDD

  

  

  流程总结 :

    从产生级别理解,每一个RDD都对应一个Job ,就是DStreams操作的最后的一个RDD ,最后的RDD对前面有依赖关系,只要有最后一个RDD就可以推导出所有的RDD

  每一个DStreams的实例都有一个GeneratedRDD ,都有HashMap ,实际上执行的时候我们只需要关注最后一个,实际计算时就是从后往前推。

  逻辑级别 :有一个又一个的DStreams对象,通过Map等操作都会产生DStreams对象,DStreams模板会随着时间的推移会产生一系列的RDD ,随着时间实例的推移,有时间注入就会产生RDD。

  实际执行 : Spark STreaming操作就看最后一个DStreams ,从后往前找出RDD的依赖关系,相当于一个矩阵,加上时空维度。

  

  GeneratdRDD是怎么获取的 :

  DStream里面有个GetorCompute方法,就是根据时间生成RDD ,可能是缓冲级别获取的,或者计算出来的。

  

  如果没有依赖就必将是自力更生:

  

  Map的DStreams ,是有依赖的,GetOrCompute产生RDD ,看到很多DStreams其实就是一个DStreams ,DStreams是逻辑级别的呈现,都是从后往前推.

  Map会对RDD进行操作,DStreams里面的计算其实就是对RDD进行计算。

  

  GetOrCompute返回的是RDD ,还有一个就是ForEachDStreams :

  

  GenerateJob是通过调度器控制的 :

  

 GenerateJob会去调用DStreams ,然后会调度到GenerateJob :

  

   

  备注:

    • 资料来源于:王家林(Spark发行版本定制)
    • 新浪微博:http://www.weibo.com/ilovepains

  

时间: 2024-10-26 22:30:54

Spark Streaming源码解读之生成全生命周期彻底研究与思考的相关文章

(版本定制)第11课:Spark Streaming源码解读之Driver中的ReceiverTracker彻底研究和思考

本期内容: 1.ReceiverTracker的架构设计 2.消息循环系统 3.ReceiverTracker具体实现 上节课讲到了Receiver是如何不断的接收数据的,并且接收到的数据的元数据会汇报给ReceiverTracker,下面我们看看ReceiverTracker具体的功能及实现. ReceiverTracker主要的功能: 在Executor上启动Receivers. 停止Receivers . 更新Receiver接收数据的速度(也就是限流) 不断的等待Receivers的运行

Spark版本定制八:Spark Streaming源码解读之RDD生成全生命周期彻底研究和思考

本期内容: 1.DStream与RDD关系彻底研究 2.Streaming中RDD的生成彻底研究 一.DStream与RDD关系彻底研究 课前思考: RDD是怎么生成的? RDD依靠什么生成?根据DStream来的 RDD生成的依据是什么? Spark Streaming中RDD的执行是否和Spark Core中的RDD执行有所不同? 运行之后我们对RDD怎么处理? ForEachDStream不一定会触发Job的执行,但是它一定会触发job的产生,和Job是否执行没有关系: 对于DStream

Spark发行版笔记9:Spark Streaming源码解读之Receiver生成全生命周期彻底研究和思考

本节的主要内容: 一.Receiver启动的方式设想 二.Receiver启动源码彻底分析 Receiver的设计是非常巧妙和出色的,非常值得我们去学习.研究.借鉴. 在深入认识Receiver之前,我们有必要思考一下,如果没有Spark.Spark Streaming,我们怎么实现Reciver?数据不断接进来,我们该怎么做?该怎么启动Receiver呢?...... 首先,我们找到数据来源的入口,入口如下: 数据来源kafka.socket.flume等构建的都是基于InputDStream

Spark 定制版:008~Spark Streaming源码解读之RDD生成全生命周期彻底研究和思考

本讲内容: a. DStream与RDD关系的彻底的研究 b. Streaming中RDD的生成彻底研究 注:本讲内容基于Spark 1.6.1版本(在2016年5月来说是Spark最新版本)讲解. 上节回顾 上节课,我们重点给大家揭秘了JobScheduler内幕:可以说JobScheduler是整个Spark Streming的调度的核心,其地位相当于Spark Core中的DAGScheduler. JobScheduler是SparkStreaming 所有Job调度的中心,内部有两个重

Spark Streaming源码解读之Receiver生成全生命周期彻底研究和思考

本期内容 : Receiver启动的方式设想 Receiver启动源码彻底分析 多个输入源输入启动,Receiver启动失败,只要我们的集群存在就希望Receiver启动成功,运行过程中基于每个Teark启动都有可能运行失败. 启动一个应用程序的不同Receiver采用一个不同RDD的partion代表不同的Receiver ,然后启动的时候不同的partion执行层面是不同的Teark ,每个Teark启动的时候就真正的启动一个Receiver. 优点: 这种比较简单,就是使用Spark Co

Spark 定制版:009~Spark Streaming源码解读之Receiver在Driver的精妙实现全生命周期彻底研究和思考

本讲内容: a. Receiver启动的方式设想 b. Receiver启动源码彻底分析 注:本讲内容基于Spark 1.6.1版本(在2016年5月来说是Spark最新版本)讲解. 上节回顾 上一讲中,我们给大家具体分析了RDD的物理生成和逻辑生成过程,彻底明白DStream和RDD之间的关系,及其内部其他有关类的具体依赖等信息: a. DStream是RDD的模板,其内部generatedRDDs 保存了每个BatchDuration时间生成的RDD对象实例.DStream的依赖构成了RDD

Spark发行版笔记10:Spark Streaming源码解读之流数据不断接收和全生命周期彻底研究和思考

本节的主要内容: 一.数据接受架构和设计模式 二.接受数据的源码解读 Spark Streaming不断持续的接收数据,具有Receiver的Spark 应用程序的考虑. Receiver和Driver在不同进程,Receiver接收数据后要不断给Deriver汇报. 因为Driver负责调度,Receiver接收的数据如果不汇报给Deriver,Deriver调度时不会把接收的数据计算入调度系统中(如:数据ID,Block分片). 思考Spark Streaming接收数据: 不断有循环器接收

Spark Streaming源码解读之Receiver在Driver的精妙实现全生命周期彻底研究和思考

一:Receiver启动的方式设想 1. Spark Streaming通过Receiver持续不断的从外部数据源接收数据,并把数据汇报给Driver端,由此每个Batch Durations就可以根据汇报的数据生成不同的Job. 2. Receiver属于Spark Streaming应用程序启动阶段,那么我们找Receiver在哪里启动就应该去找Spark Streaming的启动. 3. Receivers和InputDStreams是一一对应的,默认情况下一般只有一个Receiver.

第9课:Spark Streaming源码解读之Receiver在Driver的精妙实现全生命周期彻底研究和思考

一:Receiver启动的方式设想 1. Spark Streaming通过Receiver持续不断的从外部数据源接收数据,并把数据汇报给Driver端,由此每个Batch Durations就可以根据汇报的数据生成不同的Job. 2. Receiver属于Spark Streaming应用程序启动阶段,那么我们找Receiver在哪里启动就应该去找Spark Streaming的启动. 3. Receivers和InputDStreams是一一对应的,默认情况下一般只有一个Receiver.