Spark定制班第6课:Spark Streaming源码解读之Job动态生成和深度思考

本期内容:
1 Spark Streaming Job生成深度思考
2 Spark Streaming Job生成源码解析

1 Spark Streaming Job生成深度思考

  前面的课程中已经讲了,Spark Streaming的Job是通过JobGenerator生成。这里说的Job和Spark Core中的Job不是一回事。Spark Streaming中的Job相当于Java中线程要处理的Runnable的业务逻辑的封装。Spark Core上的Job是一个运行的作业。
  JobGenerator会利用DStream来生成Job。从流程上看,DStream一般分三种类型:
  1、输入的DStreams。
  2、输出的DStreams,是一个逻辑级别的Action,它是SparkStreaming框架提出的,它的底层还是会被翻译成物理级别的Action。所谓物理级别的Action是RDD的Action。
  3、中间的业务处理的通过Transformation(转换)产生的DStream。也就是业务处理逻辑的中间过程。
  产生DStream也可以说有两类:一类是根据数据源产生DStream,另一类是通过前面的DStream转换后生成DStream。
  所以说,JobGenerator是根据DStream的依赖关系,或者说根据DStreamGraph来产生Job。
  当然从时间维度上讲,JobGenarator会不断地产生Job。我们做连续不断的大数据任务时,如果不采用流式处理,一般会用定时任务。其实我们也是变相地在做流处理。不管是定时1分钟、1小时,甚至是1天,都类似在做流处理。应该更深刻的理解此前说过的一句话吧:一切没有经过流处理或近似流处理的数据,都将是没有价值的数据。原来的定时任务实际上是在做变相的流处理。我们相信,一切处理终将会被流处理完全统一。

2 Spark Streaming Job生成源码解析

  其实,Spark Streaming的流处理实际上就是以时间作为触发器的。这和基于事件触发的Storm不同。
  看看Spark Streaming应用程序代码的最开始的共同之处:定义SparkStreamingContext。给个例子:

val ssc = new StreamingContext(conf, Seconds(5))

  这个5秒钟的Batch Duration(批处理时间间隔)就是用来设置定时器的时间长度。
  系统翻译基于DStream的依赖关系,成为了RDD之间的依赖关系,而最后的处理是一个action,但由于这个处理是定义在一个方法中,而此方法没有被马上调用,也就没有马上执行。这是为了便于管理,要形成队列来依次处理。
  Spark Streaming应用程序代码的最后面的共同之处:运行SparkStreamingContext的start():

ssc.start()

  这里才是真正启动流处理执行的地方。启动SparkStreamingContext,会启动JobScheduler。

  Spark Streaming作业的三大核心是:
  1. JobGenerator:负责Job的生成。
  2. ReceiverTracker:负责数据的接收。
  3. JobScheduler:负责Job的调度执行。

  JobGenerator、ReceiverTracker其实是在JobScheduler的start()中被启动。

  先提供 Job生成的总体轮廓。本期剖析的Job生成的主流程图如下所示:


  先从JobScheduler.start开始剖析。
  JobScheduler.start的代码片段:

class JobScheduler(val ssc: StreamingContext) extends Logging {
  ...
  private val jobGenerator = new JobGenerator(this)
  ...
  def start(): Unit = synchronized {
    ...
    receiverTracker = new ReceiverTracker(ssc)
    ...
    receiverTracker.start()
     jobGenerator.start ()
    ...
  }
  ...
}

  我们先看JobGenerator的start():

/** Start generation of jobs */
def start(): Unit = synchronized {
  ...
  eventLoop = new  EventLoop [JobGeneratorEvent]("JobGenerator") {
    override protected def  onReceive (event: JobGeneratorEvent): Unit =  processEvent (event)
    ...
    }
  }
  eventLoop.start()

  if (ssc.isCheckpointPresent) {
    restart()
  } else {
    startFirstTime()
  }
}

  注释也说明这是生成jobs。
  代码中生成了EventLoop,并启动它。EventLoop是个消息接收器,其中有个消息队列,用于接收消息;它启动后,其中会有个线程不断地从该队列中取消息进行处理。
  代码中覆盖了EventLoop的onReceive方法,OnReceive()里,一般不要做复杂耗时的操作,应该交给别的线程去处理。按照定义,OnReceive也就是调用了processEvent方法。
   JobGenerator.processEvent的代码:

/** Processes all events */
private def  processEvent (event: JobGeneratorEvent) {
  ...
  event match {
    case  GenerateJobs (time) =>  generateJobs (time)
    ...
  }
}

  一般情况下,会执行 GenerateJobs(time)这种类型的事件消息。其相应的会执行generateJobs(time):
  JobGenerator.generateJobs的代码:

/** Generate jobs and perform checkpoint for the given `time`.  */
private def generateJobs(time: Time) {
  ...
  Try {
    jobScheduler.receiverTracker.allocateBlocksToBatch(time) // allocate received blocks to batch
     graph.generateJobs (time) // generate jobs using allocated block
  } match {
    case Success(jobs) =>
      val streamIdToInputInfos = jobScheduler.inputInfoTracker.getInfo(time)
      jobScheduler.submitJobSet(JobSet(time, jobs, streamIdToInputInfos))
      ...
  }
  ...
}

  主要是先获取数据,然后对这些数据来生成相应的jobs,生成工作是调用DStreamGraph的generateJobs。
  DStreamGraph.generateJobs的代码:

def generateJobs(time: Time): Seq[Job] = {
  logDebug("Generating jobs for time " + time)
  val jobs = this.synchronized {
    outputStreams.flatMap { outputStream =>
      val jobOption = outputStream. generateJob (time)
      jobOption.foreach(_.setCallSite(outputStream.creationSite))
      jobOption
    }
  }
  logDebug("Generated " + jobs.length + " jobs for time " + time)
  jobs
}

  这里的outputDStream是DStream中最后处理的Dstream,根据DStreamGraph的最后面的outputDStream,从后往前推,
  DStream.generateJob的代码:
/**
 * Generate a SparkStreaming job for the given time. This is an internal method that
 * should not be called directly. This default implementation creates a job
 * that materializes the corresponding RDD. Subclasses of DStream may override this
 * to generate their own jobs.
 */
 private[streaming] def generateJob(time: Time): Option[Job] = {
   getOrCompute (time) match {
    case Some(rdd) => {
      val  jobFunc  = () => {
        val emptyFunc = { (iterator: Iterator[T]) => {} }
        context.sparkContext.runJob(rdd, emptyFunc)
      }
      Some(new  Job (time, jobFunc))
    }
    case None => None
  }
}
  代码的注释也说明了DStream间的操作是逻辑级别的,RDD之间的操作是物理的。
  getOrCompute是获得指定时间的RDD。
  其中的Job是Spark Streaming中定义的。这里并不是真正执行了Spark Core的作业。而是用函数jobFunc封装了Spark作业的执行本身。
  这个Job类其实就是相当于Java中的Bean,并没有做Spark的作业的执行。

  至此,JobGenarator.start中的消息处理的定义就剖析完了。再看其中的后续代码。
  JobGenarator.start的代码:

/** Start generation of jobs */
def start(): Unit = synchronized {
  ...
  eventLoop = new EventLoop[JobGeneratorEvent]("JobGenerator") {
    override protected def onReceive(event: JobGeneratorEvent): Unit = processEvent(event)
    ...
    }
  }
  eventLoop.start()

  if (ssc.isCheckpointPresent) {
    restart()
  } else {
     startFirstTime()
  }
}

  restart是利用checkPoint重新启动JobGenerator。我们主要看看startFirstTime。
  JobGenerator.startFirstTime代码:

/** Starts the generator for the first time */
private def startFirstTime() {
  val startTime = new Time(timer.getStartTime())
   graph.start (startTime - graph.batchDuration)
   timer.start (startTime.milliseconds)
  logInfo("Started JobGenerator at " + startTime)
}

  其中启动了DStreamGraph和RecurringTimer。
  DStreamGraph.start对DStreamGraph中的各DStream做初始化。
  RecurringTimer.start代码:

/**
 * Start at the given start time.
 */
def start(startTime: Long): Long = synchronized {
  nextTime = startTime
   thread.start ()
  logInfo("Started timer for " + name + " at time " + nextTime)
  nextTime
}

  实际上是启动一个线程来定时调用回调函数。再回过头看timer的定义:

private val timer = new RecurringTimer(clock, ssc.graph.batchDuration.milliseconds,
   longTime => eventLoop.post(GenerateJobs(new Time(longTime))) , "JobGenerator")

  其中的匿名的回调函数是发送GenerateJobs消息给eventLoop。
  原来JobGenerator.processEvent中获得的消息是RecurringTimer定时触发的。

   JobGenerator中的generateJobs剖析完了,再看后面的代码。
   JobGenerator.generateJobs的代码:

/** Generate jobs and perform checkpoint for the given `time`.  */
private def generateJobs(time: Time) {
  ...
  Try {
    jobScheduler.receiverTracker.allocateBlocksToBatch(time) // allocate received blocks to batch
     graph.generateJobs (time) // generate jobs using allocated block
  } match {
    case Success(jobs) =>
      val streamIdToInputInfos = jobScheduler.inputInfoTracker.getInfo(time)
       jobScheduler.submitJobSet (JobSet(time, jobs, streamIdToInputInfos))
      ...
  }
  ...
}

  JobScheduler.submitJobSet的代码:

def submitJobSet(jobSet: JobSet) {
  if (jobSet.jobs.isEmpty) {
    logInfo("No jobs added for time " + jobSet.time)
  } else {
    listenerBus.post(StreamingListenerBatchSubmitted(jobSet.toBatchInfo))
    jobSets.put(jobSet.time, jobSet)
    jobSet.jobs.foreach(job =>  jobExecutor.execute (new  JobHandler (job)))
    logInfo("Added jobs for time " + jobSet.time)
  }
}

jobExecutor是线程池,JobHandler是Runnable的子类。
JobHandler.run的代码:

private class JobHandler(job: Job) extends Runnable with Logging {
  import JobScheduler._
   def run() {
    try {
      ...
      if (_eventLoop != null) {
        ...
        PairRDDFunctions.disableOutputSpecValidation.withValue(true) {
           job.run ()
        }
        ...
      } else {
        // JobScheduler has been stopped.
      }
    } finally {
      ssc.sc.setLocalProperty(JobScheduler.BATCH_TIME_PROPERTY_KEY, null)
      ssc.sc.setLocalProperty(JobScheduler.OUTPUT_OP_ID_PROPERTY_KEY, null)
    }
  }
}

  Job.run的代码:

def run() {
  _result = Try( func ())
}

  此处,执行了Job中封装的业务逻辑。


你可能感兴趣的:(源码,scala,spark,解密,架构)