大数据计算框架Spark之任务调度

Spark有几种资源调度设施。每个Spark Application(SparkContext实例)独立地运行在一组executor进程内。cluster manager为应用间的调度提供设施。在每个Spark应用内，如果将多个job(多个spark action)提交给不同的线程，那么他们会并行运行。

1 Application间的资源调度

集群上，每个Spark application获得独立的一组executor JVM，这组executor JVM只为那个application运行task和存储数据。如果多个用户要共享集群，有不同的策略管理资源分配，这取决于使用的cluster manager。

资源的静态分区(static partitioning)可被所有的cluster manager获得，这样每个application在他的生命周期内都可获得他能使用的最多资源。standalone、YARN、coarse-grained Mesos mode这三种模式使用的就是这种方式。

1.1控制资源使用

集群类型下，如下配置资源分配：

1. Standalone mode：application提交到standalone mode集群，将会以FIFO的顺序运行，每个application会尽可能地使用所有可用节点，配置spark.cores.max来限制application使用节点的数目，或者设置spark.deploy.defaultCores。除了可以设置application可用内核数，还可以设置spark.executor.memory来控制内存的使用。
2. Mesos：为了使用静态分区(static partitioning)在Mesos集群上，spark.mesos.coarse=true,可以通过设置spark.cores.max来限制每个application的资源共享，通过设置spark.executor.memory来控制executor内存的使用。
3. YARN：通过设置--num-executors选项，spark YARN客户端可控制集群上有多少executor被分配(对应的配置属性为spark.executor.instances)，--executor-memory(对应的配置属性spark.executor.memory)和--executor-cores(对应的配置属性spark.executor.cores)控制了分配给每个executor的资源。

应用之间无法共享内存。

1.2动态资源分配

Spark提供了依据应用的工作量动态调整资源的机制。这意味着你的application不在使用的资源会返还给集群，当需要的时候再申请分配资源，这种特性对于多应用共享集群特别有用。

这个特性默认失效，但在所有coarse-grained cluster manager上都可用，如：standalone mode, YARN mode, 和Mesos coarse-grained mode。

使用这个特性有两个要求。首先用于必须设置spark.dynamicAllocation.enabled=true,其次要设置external shuffle service在集群上的每个worker node并设置spark.shuffle.service.enabled=true。设置external shuffle service目的是executor可被移除但是不删除他们生成的shuffle文件。

设置这个变量的方式为：

• 在standalone模式：设置spark.shuffle.service.enabled=true
• Mesos coarse-grained模式：在所有从节点运行$SPARK_HOME/sbin/start-mesos-shuffle-service.sh设置spark.shuffle.service.enabled=true
• YARN：详见运行spark与YARN

1.3资源分配策略

当Spark不再使用executor时就出让它，需要的时候再获取它。因为没有一个确定的方式预测将要被移除的executor是否在不久的将来会被使用，或者一个将要被添加的新executor实际上是否是空闲的，所以我们需要一系列试探来确定是移除executor(可能会移除多个)还是请求executor(可能会请求多个)。

请求策略

开启Spark application动态分配资源特性，当pending task等待被调度时，Spark application会请求额外的executor。这就意味着，当前的这些executor无法同时满足所有的task，这些task已经被提交，但是还没有执行完。

Spark轮流请求executor。当task等待的时间大于spark.dynamicAllocation.schedulerBacklogTimeout时，真正的请求(申请executor的请求)被触发，之后，如果未完成task队列存在，那么每隔spark.dynamicAllocation.sustainedSchedulerBacklogTimeout秒请求被触发一次。每一轮请求的executor数量以指数级增长。例如，第一轮请求一个executor，第二轮请求2个，第三，四轮分别请求4,8个。

按指数形式增长的动机有两个，首先，起初应用应该慎重地请求executor，以防只需几个executor就能满足需求，这和TCP慢启动类似。其次，当应用确实需要更多的executor时，，应用应该能够及时地增加资源的使用。

移除策略

当executor闲置超过spark.dynamicAllocation.executorIdleTimeout秒时，就将他移除。注意，大多数情况下，executor的移除条件和请求条件是互斥的，这样如果仍然有待调度的task的情况下executor是不会被移除的。

executor优雅地退役

非动态分配资源情况下，一个Spark executor或者是由于失败而退出，或者是因相关application退出而退出。这两种情况下，不在需要与executor相关联的状态并且这些状态可以被安全地丢弃。动态分配资源的情况下，当executor被明确移除时，application仍然在运行。如果application要想使用这些由executor存储和写下的状态，就必须重新计算状态。这样就需要一种优雅的退役机制，即在executor退役前保留他的状态。

这个机制对于shuffles特别重要。shuffle期间,executor自己的map输出写入本地磁盘。当其他的executor要获取这些文件的时候，这个executor充当了文件服务器的角色。对于那些落后的executor，他们的task执行时间比同辈要长，在shuffle完成之前，动态资源分配可能移除了一个executor，这种情形下，那个executor写入本地的文件(即executor的状态)不必重新计算。

保留shuffle文件的办法就是使用外部的shuffle服务，这是在Spark 1.2中引入的。这个外部的shuffle服务指的是长时间运行的进程，它运行与集群的每个节点上，独立于application和executor。如果这个服务可用，executor就从这个服务获shuffle file，而不是彼此之间获取shuffle file。这意味着executor生成的任何shuffle文件都可能被服务包含，即使在executor生命周期之外也是如此。

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!