Spark Core（三）Executor上是如何launch task（转载）

1. 启动任务

在前面一篇博客中（Driver 启动、分配、调度Task）介绍了Driver是如何调动、启动任务的，Driver向Executor发送了LaunchTask的消息，Executor接收到了LaunchTask的消息后，进行了任务的启动，在CoarseGrainedExecutorBackend.scala

case LaunchTask(data) =>  
  if (executor == null) {  
    exitExecutor(1, "Received LaunchTask command but executor was null")  
  } else {  
    val taskDesc = ser.deserialize[TaskDescription](data.value)  
    logInfo("Got assigned task " + taskDesc.taskId)  
    executor.launchTask(this, taskId = taskDesc.taskId, attemptNumber = taskDesc.attemptNumber,  
      taskDesc.name, taskDesc.serializedTask)  
  }  

接收消息，反序列化了TaskDescription的对象

 

在TaskDescription反序列化了taskId, executeId, name，index, attemptNumber, serializedTask属性，其中serializedTask是ByteBuffer。

Executor的launchTask方法

def launchTask(  
     context: ExecutorBackend,  
     taskId: Long,  
     attemptNumber: Int,  
     taskName: String,  
     serializedTask: ByteBuffer): Unit = {  
   val tr = new TaskRunner(context, taskId = taskId, attemptNumber = attemptNumber, taskName,  
     serializedTask)  
   runningTasks.put(taskId, tr)  
   threadPool.execute(tr)  
 }  

方法中通过线程池中启动了线程运行TaskRunner的任务

private val threadPool = ThreadUtils.newDaemonCachedThreadPool("Executor task launch worker")  

关于线程池，在executor启动的是一个无固定大小线程数量限制的线程池，也就是说在executor的设计中，启动的任务数量是完全由Driver来管控

2. 任务的运行

前面提到了TaskDescription中的serializedTask是个bytebuffer, 里面的结构如下图所示：

 

分别是task所依赖的文件的数量，文件的名字，时间戳，Jar的数量，Jar的名字，Jar的时间戳，属性，subBuffer是个bytebuffer

2.1 加载Jars文件

Driver所运行的class等包括依赖的Jar文件在Executor上并不存在，Executor首先要fetch所依赖的jars，也就是TaskDescription中serializedTask中的jar部分

在上面的结构描述中，jar相关的只是numJars,jarName,timestamp并没有jar的内容，也就是在LaunchTask里的消息中并不携带Jar的内容，原因也很容易理解，rpc的消息体必须简单高效

• timestamp:这是用于判断文件的时间戳，在相同文件名的情况下只有新的才需要重新fetch
• jarName: 这里的JarName是网络文件名：spark://192.168.121.101:37684/jars/spark-examples_2.11-2.1.0.jar

 

通常在相同的Driver在起多个任务的时候，任务的所依赖的jar是基本相同的，所以没必要每个Task都重新fetch相同的jars

for ((name, timestamp) <- newJars) {  
        val localName = name.split("/").last  
        val currentTimeStamp = currentJars.get(name)  
          .orElse(currentJars.get(localName))  
          .getOrElse(-1L)  
        if (currentTimeStamp < timestamp) {  
          logInfo("Fetching " + name + " with timestamp " + timestamp)  
          // Fetch file with useCache mode, close cache for local mode.  
          Utils.fetchFile(name, new File(SparkFiles.getRootDirectory()), conf,  
            env.securityManager, hadoopConf, timestamp, useCache = !isLocal)  
          currentJars(name) = timestamp  
          // Add it to our class loader  
          val url = new File(SparkFiles.getRootDirectory(), localName).toURI.toURL  
          if (!urlClassLoader.getURLs().contains(url)) {  
            logInfo("Adding " + url + " to class loader")  
            urlClassLoader.addURL(url)  
          }  
        }  

在Utils.fetchFile里还做了一层cache，受参数控制

spark.files.useFetchCache  

而在fetchFile的缓存中，缓存的文件被保存在executor的临时文件夹中，例如

/tmp/spark-e9555893-6556-4a56-a692-54a984c3addb/executor-4b9581ca-fe9f-4e96-9db0-192146158a44/spark-bf41fdbd-a84e-473a-aa60-76480745b50b  

缓存文件的命名规则：

/tmp/spark-e9555893-6556-4a56-a692-54a984c3addb/executor-4b9581ca-fe9f-4e96-9db0-192146158a44/spark-bf41fdbd-a84e-473a-aa60-76480745b50b  

缓存文件的命名规则：

s"${url.hashCode}${timestamp}_cache"  

为了避免同时线程安全问题，可能存在多个任务Fetch相同的文件，FetchFile使用了文件锁，并且是细粒度的文件锁，只增对相同的文件

1. 相同的文件名，这里的文件名也是网络文件名

2. 相同的时间戳

整个完整的流程如下

1. 检查本地是否有相同的缓存文件
2. 如果没有，先Fetch文件从Driver中获取，通过URL：（

   spark://192.168.121.101:37684/jars/spark-examples_2.11-2.1.0.jar

   ）复制到本地的缓存文件
3. 复制本地缓存文件到工作目录 /work/app-ID/executorid/
4. 设置工作目录文件具有可执行权限

最后通过urlClassLoader去loader这个jar文件

2.2 运行task

前面所提到的subBuffer实际上就是Task的序列化对象，通过反序列化可以获取到Driver生成的Task

在Executor.scala里的run方法中

val res = task.run(  
           taskAttemptId = taskId,  
           attemptNumber = attemptNumber,  
           metricsSystem = env.metricsSystem)  

最后调用了task.run的方法，在task的run方法，所有继承了Task的类都只需要实现runTask的方法

2.3 反序列化RDD，Dependency

RDD是算子，Dependency是依赖，这是在Executor需要的运算，但是在前面的序列化对象中，并没有看到有RDD，Dep的属性，那么RDD,Dep是怎么传递到Task里进行运算的呢？

在DAG里生成的task就是ShuffleMapTask, ResultTask，下面以ShuffleMapTask为例，在runTask里

val (rdd, dep) = ser.deserialize[(RDD[_], ShuffleDependency[_, _, _])](  
     ByteBuffer.wrap(taskBinary.value), Thread.currentThread.getContextClassLoader)  
   _executorDeserializeTime = System.currentTimeMillis() - deserializeStartTime  
   _executorDeserializeCpuTime = if (threadMXBean.isCurrentThreadCpuTimeSupported) {  
     threadMXBean.getCurrentThreadCpuTime - deserializeStartCpuTime  
   } else 0L  

也就是基于taskBinary.value来进行反序列化获得，在来看taskBinary成员

taskBinary: Broadcast[Array[Byte]],  

/** Get the broadcasted value. */  
def value: T = {  
  assertValid()  
  getValue()  
}  

在前面博客章节中关于Spark Storage管理中提到在集群下使用的是TorrentBroadcast

@transient private lazy val _value: T = readBroadcastBlock()  

在前面的storage 系列（一）里面已经谈到过当本地的broadcastId不存在的时候，会尝试去远端（也就是Driver）获取内容，这里的BroadcastId格式是

broadcast_executorID  

博客中也提到了同一个Executor拥有一个Block，一个大Block也存在多个Piece的小Block, 也就是格式

broadcast_executorID_pieceid  

val blocks = readBlocks().flatMap(_.getChunks())  
          logInfo("Reading broadcast variable " + id + " took" + Utils.getUsedTimeMs(startTimeMs))  
  
          val obj = TorrentBroadcast.unBlockifyObject[T](  
            blocks, SparkEnv.get.serializer, compressionCodec)  
          // Store the merged copy in BlockManager so other tasks on this executor don't  
          // need to re-fetch it.  
          val storageLevel = StorageLevel.MEMORY_AND_DISK  
          if (!blockManager.putSingle(broadcastId, obj, storageLevel, tellMaster = false)) {  
            throw new SparkException(s"Failed to store $broadcastId in BlockManager")  
          }  

在远端获取多个piece块后，在blockManager里会合成一个以broadcast_executorID为key的大block块保存在blockManager里，作为缓存同一个executor下的其他运行的task直接使用blockManager里的块，而不在需要远端在去获取block。

在这里blockManager同时也保存着每个piece的block快，主要考虑到TorrentBroadcast的时候，Executor也可以作为一个传播block块的节点，而不只是Driver的单个节点。

Block里面的内容反序列化后生成RDD和Dependency对象。

2.4 序列化RDD,Dependency

前面讲了executor的反序列化的过程，当然序列化过程是在Driver中做的，回到DAGScheduler.scala的submitMissingTasks函数中

var taskBinary: Broadcast[Array[Byte]] = null  
   try {  
     // For ShuffleMapTask, serialize and broadcast (rdd, shuffleDep).  
     // For ResultTask, serialize and broadcast (rdd, func).  
     val taskBinaryBytes: Array[Byte] = stage match {  
       case stage: ShuffleMapStage =>  
         JavaUtils.bufferToArray(  
           closureSerializer.serialize((stage.rdd, stage.shuffleDep): AnyRef))  
       case stage: ResultStage =>  
         JavaUtils.bufferToArray(closureSerializer.serialize((stage.rdd, stage.func): AnyRef))  
     }  
  
     taskBinary = sc.broadcast(taskBinaryBytes)  
   } catch {  
     // In the case of a failure during serialization, abort the stage.  
     case e: NotSerializableException =>  
       abortStage(stage, "Task not serializable: " + e.toString, Some(e))  
       runningStages -= stage  
  
       // Abort execution  
       return  
     case NonFatal(e) =>  
       abortStage(stage, s"Task serialization failed: $e
${Utils.exceptionString(e)}", Some(e))  
       runningStages -= stage  
       return  
   }  

看到序列化的是Stage的rdd和shuffleDependency, 其中是Stage里的rdd就是shuffleDep.rdd也就是ShuffledRDD里prev的RDD

3 总结：

• TaskDescription 只是包含了任务需要的文件列表，jar文件，配置相关属性，并没有这些具体的文件
• 具体的文件下载路径是Driver直接在TaskDescription中的serializedTask提供的
• 具体要运行的Task是通过serializedTask中的subbuffer中反序列化的
• Task中依赖的RDD,Dependency是从BlockManager从Driver的Block块中获取进行反序列化
• ShuffleMapTask里依赖的的RDD是ShuffledRDD的前一个RDD,而Dependency就是ShuffleDependency