辰辰爸的博客

在前四篇博文中，我们分析了Job提交运行总流程的第一阶段Stage划分与提交，它又被细化为三个分阶段：        1、Job的调度模型与运行反馈；        2、Stage划分；        3、Stage提交：对应TaskSet的生成。        Stage划分与提交阶段主要是由DAGScheduler完成的，而DAGScheduler负责Job的逻辑调度，主要职责

我们知道，spark是一个基于内存的分布式计算框架。运行在其上的应用程序，按照action划分为一个个job，而job提交运行的总流程，概括起来如下：        1、Stage划分与TaskSet生成：job按照rdd之间的依赖关系是否为宽依赖，由DAGScheduler划分为一个个stage，并将每个stage提交给TaskScheduler，将每个stage转化为一个TaskSet；

在《Spark源码分析之Job提交运行总流程概述》一文中，我们提到了，Job提交与运行的第一阶段Stage划分与提交，可以分为三个阶段：        1、Job的调度模型与运行反馈；        2、Stage划分；        3、Stage提交：对应TaskSet的生成。        今天，我们就结合源码来分析下第一个小阶段：Job的调度模型与运行反馈。

继上篇《Spark源码分析之Job的调度模型与运行反馈》之后，我们继续来看第二阶段--Stage划分。        Stage划分的大体流程如下图所示：        前面提到，对于JobSubmitted事件，我们通过调用DAGScheduler的handleJobSubmitted()方法来处理。那么我们先来看下代码：// 处理Job提交的函数 private[sch

各位看官，上一篇《Spark源码分析之Stage划分》详细讲述了Spark中Stage的划分，下面，我们进入第三个阶段--Stage提交。        Stage提交阶段的主要目的就一个，就是将每个Stage生成一组Task，即TaskSet，其处理流程如下图所示：        与Stage划分阶段一样，我们还是从handleJobSubmitted()方法入手，在Stage划

话说在《Spark源码分析之五：Task调度（一）》一文中，我们对Task调度分析到了DriverEndpoint的makeOffers()方法。这个方法针对接收到的ReviveOffers事件进行处理。代码如下：// Make fake resource offers on all executors    // 在所有的executors上提供假的资源（抽象的资源，也就是资源的对象信息

在Task调度相关的两篇文章《Spark源码分析之五：Task调度（一）》与《Spark源码分析之六：Task调度（二）》中，我们大致了解了Task调度相关的主要逻辑，并且在Task调度逻辑的最后，CoarseGrainedSchedulerBackend的内部类DriverEndpoint中的makeOffers()方法的最后，我们通过调用TaskSchedulerImpl的resourceOf

Spark是现在很流行的一个基于内存的分布式计算框架，那么，自然而然的，内存的管理就是Spark存储管理的重中之重了。那么，Spark究竟采用什么样的内存管理模型呢？本文就为大家揭开Spark内存管理模型的神秘面纱。        还记得我们在《》一文中提到的，在Task被传递到Executor上去执行时，在为其分配的TaskRunner线程的run()方法内，在Task真正运行之前，我们就要

在《Spark源码分析之七：Task运行（一）》一文中，我们详细叙述了Task运行的整体流程，最终Task被传输到Executor上，启动一个对应的TaskRunner线程，并且在线程池中被调度执行。继而，我们对TaskRunner的run()方法进行了详细的分析，总结出了其内Task执行的三个主要步骤：        Step1：Task及其运行时需要的辅助对象构造，主要包括：