Spark Core源代码分析: Spark任务运行模型
DAGScheduler
面向stage的调度层,为job生成以stage组成的DAG,提交TaskSet给TaskScheduler运行。
每个Stage内,都是独立的tasks,他们共同运行同一个compute function,享有同样的shuffledependencies。DAG在切分stage的时候是按照出现shuffle为界限的。
private[spark]
class DAGScheduler(
taskScheduler: TaskScheduler,
listenerBus: LiveListenerBus,
mapOutputTracker: MapOutputTrackerMaster,
blockManagerMaster: BlockManagerMaster,
env: SparkEnv)
extends Logging {
// Actor模式收取发来的DAGSchedulerEvent,并进行processEvent
private var eventProcessActor: ActorRef = _ private[scheduler] val nextJobId = new AtomicInteger(0)
private[scheduler] def numTotalJobs: Int = nextJobId.get()
private val nextStageId = new AtomicInteger(0) // 一系列信息维护,非常清晰
private[scheduler] val jobIdToStageIds = new HashMap[Int, HashSet[Int]]
private[scheduler] val stageIdToJobIds = new HashMap[Int, HashSet[Int]]
private[scheduler] val stageIdToStage = new HashMap[Int, Stage]
private[scheduler] val shuffleToMapStage = new HashMap[Int, Stage]
private[scheduler] val jobIdToActiveJob = new HashMap[Int, ActiveJob]
private[scheduler] val resultStageToJob = new HashMap[Stage, ActiveJob]
private[scheduler] val stageToInfos = new HashMap[Stage, StageInfo] // 不同状态stages的维护,非常清晰
// Stages we need to run whose parents aren't done
private[scheduler] val waitingStages = new HashSet[Stage] // Stages we are running right now
private[scheduler] val runningStages = new HashSet[Stage] // Stages that must be resubmitted due to fetch failures
private[scheduler] val failedStages = new HashSet[Stage] // Missing tasks from each stage
private[scheduler] val pendingTasks = new HashMap[Stage, HashSet[Task[_]]] private[scheduler] val activeJobs = new HashSet[ActiveJob] // Contains the locations that each RDD's partitions are cached on
private val cacheLocs = new HashMap[Int, Array[Seq[TaskLocation]]]
在start()方法中会初始化Actor,然后接收DAGSchedulerEvent处理。Scheduler会在SparkContext里start起来。
Event处理
源代码的阅读入口:能够依据processEvent(event:DAGSchedulerEvent)方法展开。
处理的事件包含这么一些:
Submit Job
JobSubmitted事件:
提交任务的事件传入參数例如以下
case JobSubmitted(jobId, rdd, func, partitions, allowLocal, callSite, listener, properties)
处理过程能够拆成三步看,每一步里面涉及的详细逻辑在以下补充展开
finalStage = newStage(rdd, partitions.size, None, jobId, Some(callSite))
本次newStage()操作能够相应新的result stage或者shuffle stage。返回Stage类(里面记录一些信息)。Stage类会传入Option[ShuffleDependency[_,_]]參数,内部有一个isShuffleMap变量,以标识该Stage是shuffle or result。
val job = new ActiveJob(jobId, finalStage, func, partitions, callSite, listener, properties)
ActiveJob类也是记录一些信息的类,能够当作是一个VO类
if (allowLocal && finalStage.parents.size == 0 && partitions.length == 1) {
// Compute very short actions like first() or take()
// with no parent stages locally.
listenerBus.post(SparkListenerJobStart(
job.jobId, Array[Int](), properties))
runLocally(job)
} else {
jobIdToActiveJob(jobId) = job
activeJobs += job
resultStageToJob(finalStage) = job
listenerBus.post(
SparkListenerJobStart(
job.jobId, jobIdToStageIds(jobId).toArray, properties))
submitStage(finalStage)
}
首先推断stage没有父亲依赖,且partition为1的话,就运行本地任务。否则,submitStage。
submitStage的逻辑为,首先寻找本次stage的parents。假设没有missing的parent stage,那么就submitMissingTask,即提交本次stage的tasks了。假设有,会对parent stage进行递归submitStage,并且getMissingParentStages得到的结果集是按id降序排的,也就是说递归submitStage的时候会按parent stage的id顺序进行。
submitMissingTask处理的是stage的parent已经available的stage。主要逻辑例如以下:
第一步:通过stage.isShuffleMap来决定生成ShuffleMapTask还是ResultTask,生成的ShuffleMapTask数目和partition数目相等。
第二步:把生成的tasks组建成一个TaskSet,提交给TaskScheduler的submitTasks方法。
TaskScheduler
DAGScheduler以stage为单位,提tasks给TaskScheduer,实现类为TaskSchedulerImpl。
TaskSchedulerImpl几个内部部件:
SchedulerBackend
SchedulableBuilder
DAGScheduler
TaskSetManager
TaskResultGetter
Tasks信息(taskIdToTaskSetId,taskIdToExecutorId,activeExecutorIds)
别的信息(SchedulerMode)
TaskScheduler做接收task、接收分到的资源和executor、维护信息、与backend打交道、把任务分配好等事情。
start(),stop()的时候,backend的start(),stop()
submitTasks(TaskSet)逻辑:
为这批Task生成新的TaskSetManager,把TaskSetManager加到SchedulerBuilder里,然后向backend进行一次reviveOffer()操作。
SchedulerBuilder
SchedulableBuilder有FIFO和Fair两种实现, addTaskSetManager会把TaskSetManager加到pool里。FIFO的话仅仅有一个pool。Fair有多个pool,Pool也分FIFO和Fair两种模式。
SchedulableBuilder的rootPool里面能够新增pool或者TaskSetManager,两者都是Scheduable的继承类,所以SchedulableBuilder用于维护rootPool这棵Scheduable 树结构。Pool是树上的非叶子节点,而TaskSetManager就是叶子节点。
在TaskScheduler初始化的时候会buildDafaultPool。
TaskSetManager
TaskSetManager负责这批Tasks的启动,失败重试,感知本地化等事情。每次reourseOffer方法会寻找合适(符合条件execId, host, locality)的Task并启动它。
reourseOffer方法,
def resourceOffer(
execId: String,
host: String,
maxLocality: TaskLocality.TaskLocality)
寻找符合execId, host和locality的task,找到的话就启动这个Task。启动的时候,把task加到runningTask的HashSet里,然后调DAGScheduler的taskStarted方法,taskStarted方法向eventProcessorActor发出BeginEvent的DAGSchedulerEvent。
TaskResultGetter
维护一个线程池,用来反序列化和从远端获取task结果。
def enqueueSuccessfulTask(taskSetManager: TaskSetManager, tid: Long, serializedData: ByteBuffer)
把序列化的数据反序列化解析出来之后,有两种情况:直接可读的result和间接task result。
前者是DirectTaskResult[T]类:
class DirectTaskResult[T](var valueBytes: ByteBuffer, var accumUpdates: Map[Long, Any], var metrics: TaskMetrics)
后者是IndirectTaskResult[T]类:
case class IndirectTaskResult[T](blockId: BlockId) extends TaskResult[T] with Serializable
在反解析出IndirectTaskResult后,能够得到BlockId这个类,他的实现有这么些:
在TaskResultGetter里,会通过blockManager的getRemoteBytes(BlockId)方法来获得序列化的task result,对这个task result进行反解析后得到DirectTaskResult类,从而获得反序列化后的真正结果数据。
这是大致的一个过程,详细另一些细节在之中,比方会向scheduler发送不同的event、blockManager会调用BlockManagerMaster把该Block remove掉。
BlockId类有这么些关键变量:
private[spark] sealed abstract class BlockId {
/** A globally unique identifier for this Block. Can be used for ser/de. */
def name: String
// convenience methods
def asRDDId = if (isRDD) Some(asInstanceOf[RDDBlockId]) else None
def isRDD = isInstanceOf[RDDBlockId]
def isShuffle = isInstanceOf[ShuffleBlockId]
def isBroadcast = isInstanceOf[BroadcastBlockId]
以下看BlockManager怎样通过BlockId获得数据:
调用的是BlockManager的内部方法
private def doGetRemote(blockId: BlockId, asValues: Boolean): Option[Any] = {
require(blockId != null, "BlockId is null")
// 通过BlockManagerMaster获得这个blockId的locations
val locations = Random.shuffle(master.getLocations(blockId))
for (loc <- locations) {
logDebug("Getting remote block " + blockId + " from " + loc)
// 使用BlockManagerWorker来获得block的数据
val data = BlockManagerWorker.syncGetBlock(
GetBlock(blockId), ConnectionManagerId(loc.host, loc.port))
if (data != null) {
if (asValues) {
// 取到就返回
return Some(dataDeserialize(blockId, data))
} else {
return Some(data)
}
}
logDebug("The value of block " + blockId + " is null")
}
logDebug("Block " + blockId + " not found")
None
}
思路是通过BlockManagerMaster来获得block的位置信息,得到的集合打乱后,遍历位置信息,通过BlockManagerWorker去获得数据,仅仅要得到了,就反序列化之后返回。
在TaskResultGetter处理的时候,成功和失败分别向Scheduler调用handleSuccessfulTask和handleFailedTask方法。
handleSuccessfulTask在DAGScheduler里,会发出CompletionEvent事件,这一步结尾工作会有非常多细节处理,这里先不阅读了。
handleFailedTask的话,仅仅要TaskSetManager不是zombie,task没有被kill,那么会继续调用backend.reviveOffers()来re-run。
全文完 :)
Spark Core源代码分析: Spark任务运行模型的更多相关文章
- Spark Core源代码分析: Spark任务模型
概述 一个Spark的Job分为多个stage,最后一个stage会包含一个或多个ResultTask,前面的stages会包含一个或多个ShuffleMapTasks. ResultTask运行并将 ...
- Spark Core源代码分析: RDD基础
RDD RDD初始參数:上下文和一组依赖 abstract class RDD[T: ClassTag]( @transient private var sc: SparkContext, @tran ...
- Spark SQL源代码分析之核心流程
/** Spark SQL源代码分析系列文章*/ 自从去年Spark Submit 2013 Michael Armbrust分享了他的Catalyst,到至今1年多了,Spark SQL的贡献者从几 ...
- Spark SQL 源代码分析之 In-Memory Columnar Storage 之 in-memory query
/** Spark SQL源代码分析系列文章*/ 前面讲到了Spark SQL In-Memory Columnar Storage的存储结构是基于列存储的. 那么基于以上存储结构,我们查询cache ...
- Spark SQL 源代码分析之Physical Plan 到 RDD的详细实现
/** Spark SQL源代码分析系列文章*/ 接上一篇文章Spark SQL Catalyst源代码分析之Physical Plan.本文将介绍Physical Plan的toRDD的详细实现细节 ...
- Spark SQL 源代码分析系列
从决定写Spark SQL文章的源代码分析,到现在一个月的时间,一个又一个几乎相同的结束很快,在这里也做了一个综合指数,方便阅读,下面是读取顺序 :) 第一章 Spark SQL源代码分析之核心流程 ...
- Spark Core Runtime分析: DAGScheduler, TaskScheduler, SchedulerBackend
Spark Runtime里的主要层次分析,梳理Runtime组件和运行流程, DAGScheduler Job=多个stage,Stage=多个同种task, Task分为ShuffleMapTas ...
- Pig源代码分析: 简析运行计划的生成
摘要 本文通过跟代码的方式,分析从输入一批Pig-latin到输出物理运行计划(与launcher引擎有关,通常是MR运行计划.也能够是Spark RDD的运行算子)的总体流程. 不会详细涉及AST怎 ...
- 【Spark Core】任务运行机制和Task源代码浅析1
引言 上一小节<TaskScheduler源代码与任务提交原理浅析2>介绍了Driver側将Stage进行划分.依据Executor闲置情况分发任务,终于通过DriverActor向exe ...
随机推荐
- 强制将IE8设置为IE7兼容模式来解析网页
强制将IE8设置为IE7兼容模式来解析网页 英文原文:http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx 文件兼容性用于定义让IE ...
- POJ 2481 Cows
Cows Time Limit: 3000MS Memory Limit: 65536K Total Submissions: 16546 Accepted: 5531 Description ...
- Binary Tree Level Order Traversal java实现
Given a binary tree, return the level order traversal of its nodes' values. (ie, from left to right, ...
- redis发布/订阅模式
其实在很多的MQ产品中都存在这样的一个模式,我们常听到的一个例子 就是邮件订阅的场景,什么意思呢,也就是说100个人订阅了你的博客,如果博主发表了文章,那么100个人就会同时收到通知邮件,除了这个 场 ...
- HDU 3695-Computer Virus on Planet Pandora(ac自动机)
题意: 给一个母串和多个模式串,求模式串在母串后翻转后的母串出现次数的的总和. 分析: 模板题 /*#include <cstdio> #include <cstring> # ...
- bzoj 1001: [BeiJing2006]狼抓兔子 平面图最小割
平面图跑最大流 可以转换为其对偶图跑最短路 一个环对应一个割 找到最小环(即最短路)极为所求,注意辅助边的建立 加入读入优化 不过时间还是一般 估计是dij写的不好 大神勿喷~~~ /*** ...
- TestNG传参的几种方式
1. 通过parameter传参 java代码部分: import org.testng.annotations.Parameters; import org.testng.annotations.T ...
- 【Linux学习】 写一个简单的Makefile编译源码获取当前系统时间
打算学习一下Linux,这两天先看了一下gcc的简单用法以及makefile的写法,今天是周末,天气闷热超市,早晨突然发现住处的冰箱可以用了,于是先出去吃了点东西,然后去超市买了一坨冰棍,老冰棍居多, ...
- Apriori学习笔记
Apriori算法是一种挖掘关联规则的频繁项集算法,是由Rakesh Agrawal和Ramakrishnan Srikant两位在1994年提出的布尔关联规则的频繁项集挖掘算法.算法的名字" ...
- 我喜欢的乐队-Euphoria
来自日本的后摇乐团,001年冬天由森川裕之.佐藤昭太.木下阳辅三人于东京组建,2003年签约日本独立厂牌123Record,并发行首张EP细碟<Floral Dew>.包括EP.Singl ...