Spark任务调度策略/资源分配
目录
- Spark任务调度策略
- 资源分配
- 分配资源分析
- Spark的Master资源分配算法
- 概述流程
- 结合源码分析
Spark任务调度策略
FIFO
FIFO(先进先出)方式调度Job，每个Job被切分成多个Stage。第一个Job优先获取所有可用资源，接下来第二个Job再获取剩余可用资源。（每个Stage对应一个TaskSetManager）
优先级（Priority）： 在DAGscheduler创建TaskSet时使用JobId作为优先级的值。FIFO调度算法实现如下所示
private[spark] class FIFOSchedulingAlgorithm extends SchedulingAlgorithm {
override def comparator(s1: Schedulable, s2: Schedulable): Boolean = {
val priority1 = s1.priority
val priority2 = s2.priority
var res = math.signum(priority1 - priority2)
if (res == 0) {
val stageId1 = s1.stageId
val stageId2 = s2.stageId
res = math.signum(stageId1 - stageId2)
}
if (res < 0) {
true
} else {
false
}
}
}
由源码可知，FIFO依据JobId进行挑选较小值。因为越早提交的作业，JobId越小。
对同一个作业(Job)而言，越早生成的Stage，其StageId越小。有依赖关系的多个Stage之间，DAGScheduler会控制Stage是否会被提交到调度队列中（若其依赖的Stage未执行完前，此Stage不会被提交），其调度顺序可通过此来保证。但若某Job中有两个无入度的Stage的话，则先调度StageId小的Stage
FAIR
FAIR共享模式调度下，Spark以在多Job之间轮询方式为任务分配资源，所有的任务拥有大致相当的优先级来共享集群的资源。FAIR调度模型如下图：
Fair调度队列可存在多个调度队列，且队列呈树型结构，用户使用sc.setLocalProperty(“spark.scheduler.pool”, “poolName”)来指定要加入的队列，默认情况下会加入到buildDefaultPool。每个队列中还可指定自己内部的调度策略，且Fair还存在一些特殊的属性：
- schedulingMode: 设置调度池的调度模式FIFO或FAIR, 默认为FIFO
- minShare：最少资源保证量，当一个队列最少资源未满足时，它将优先于其它同级队列获取资源
- weight: 在一个队列内部分配资源时，默认情况下，采用公平轮询的方法将资源分配给各个应用程序，而该参数则将打破这种平衡。例如，如果用户配置一个指定调度池权重为2， 那么这个调度池将会获得相对于权重为1的调度池2倍的资源
以上参数，可通过conf/fairscheduler.xml文件配置调度池的属性。Fair调度算法实现：
private[spark] class FairSchedulingAlgorithm extends SchedulingAlgorithm {
override def comparator(s1: Schedulable, s2: Schedulable): Boolean = {
val minShare1 = s1.minShare
val minShare2 = s2.minShare
val runningTasks1 = s1.runningTasks
val runningTasks2 = s2.runningTasks
val s1Needy = runningTasks1 < minShare1
val s2Needy = runningTasks2 < minShare2
val minShareRatio1 = runningTasks1.toDouble / math.max(minShare1, 1.0).toDouble
val minShareRatio2 = runningTasks2.toDouble / math.max(minShare2, 1.0).toDouble
val taskToWeightRatio1 = runningTasks1.toDouble / s1.weight.toDouble
val taskToWeightRatio2 = runningTasks2.toDouble / s2.weight.toDouble
var compare: Int = 0
if (s1Needy && !s2Needy) {
return true
} else if (!s1Needy && s2Needy) {
return false
} else if (s1Needy && s2Needy) {
compare = minShareRatio1.compareTo(minShareRatio2)
} else {
compare = taskToWeightRatio1.compareTo(taskToWeightRatio2)
}
if (compare < 0) {
true
} else if (compare > 0) {
false
} else {
s1.name < s2.name
}
}
}
由源码可知，未满足minShare规定份额的资源的队列或任务集先执行；如果所有均不满足minShare的话，则选择缺失比率小的先调度；如果均不满足，则按执行权重比进行选择，先调度执行权重比小的。如果执行权重也相同的话则会选择StageId小的进行调度（name=“TaskSet_”+ taskSet.stageId.toString）。以此为标准将所有TaskSet进行排序， 然后选出优先级最高的进行调度。
默认情况下，Spark的调度程序以FIFO方式运行作业。每个job会被划分成很多stage，在第一个job运行完成之后，第二个job才会去执行。如果在队列头部的job不需要使用集群的全部资源，那么后面的job可以立即执行。队列头部的job很大的话，其余的job必须推迟执行。
从Spark 0.8开始，也可以在作业之间配置公平的共享。在公平分享下，Spark以“循环”方式在任务之间分配tasks，使所有job获得大致相等的集群资源份额。这意味着长job运行期间提交的短job，也可以立即获取到资源，并且仍然可以获得良好的响应时间，而无需等待长job完成。此模式最适合多用户。要启用公平调度程序，只需在配置SparkContext时：
val conf = new SparkConf().setMaster(...).setAppName(...)
conf.set("spark.scheduler.mode", "FAIR")
val sc = new SparkContext(conf)
资源分配
Spark的分配资源主要就是 executor、cpu、memory。分配资源，首先要了解机器有多大的内存，多少个cpu core，就根据这个实际情况去设置。一个cpu对应2-3task合理。
Standalone 模式
如果每台机器可用内存是4G，2个cpu core，20台机器，
那可以设置：20个executor，每个executor4G内存，2个cpu core（资源最大化利用）。
yarn 模式下
根据spark要提交的资源队列资源来考虑，如果所在队列资源为500G内存，100个cpu core。
可以设置50个executor；每个executor10G内存2个cpu
分配资源分析
增加每个executor的cpu core，也是增加了执行的并行能力。 原本20个executor，每个才2个cpu core。能够并行执行的task数量，就是40个task。如果现在每个executor的cpu core，增加到了5个。能够并行执行的task数量，就是100个task。执行的速度，提升了2.5倍。如果executor数量比较少，那么能够并行执行的task数量就比较少，就意味着Application的并行执行的能力就很弱。
增加每个executor的内存量。 增加了内存量以后，对性能的提升有几点：
- 如果需要对RDD进行cache，那么更多的内存，就可以缓存更多的数据，将更少的数据写入磁盘，甚至不写入磁盘。减少了磁盘IO
- 对于shuffle操作，reduce端，会需要内存来存放拉取的数据并进行聚合。如果内存不够，也会写入磁盘。如果给executor分配更多内存以后，就有更少的数据，需要写入磁盘，甚至不需要写入磁盘。减少了磁盘IO，提升了性能
- 对于task的执行，可能会创建很多对象。如果内存比较小，可能会频繁导致JVM堆内存满了，然后频繁GC（速度很慢）。内存加大以后，带来更少的GC
Spark的Master资源分配算法
概述流程
Master资源调度通过schedule()方法实现，步骤如下：
- 首先判断master是否是alive状态，如果不是alive则返回，也就是只有活动的master才会进行资源调度，standby master是不会进行资源调度的
- 把之前注册的worker中的alive状态的worker传入 Random.shuffle方法，该方法主要是把worker顺序打乱，返回一个数组
- 获取返回的worker的数量
- 用for循环进行driver调度，只有启用yarn-cluster模式提交application才会进行driver调度，因为yarn-client和 standalone模式都是在提交的客户端启动driver，不需要调度
- for循环遍历WaittingDrivers，如果这个worker的内存>=driver需要的内存并且CPU>=driver需要的CPU，则启动driver，将driver从WaittingDrivers队列中移除
- 启动driver的方法为launchDriver，将driver加入worker的内部缓存，将worker剩余的内存、CPU减去driver需要的内存、CPU，worker也被加入到driver缓存结构中，然后调用worker的actor方法，给worker发送LaunchDriver消息，让它把driver启动起来，然后将driver状态改为RUNNING
- driver启动后，进行application的调度，这里有两个算法，spreadOutApps和非spreadOutApps算法，这个在代码的SparkConf里可以设置， (“spark.deploy.spreadOut”, true)，默认是为true，启用spreadoutApps
- for遍历WaitingApps中的application，并且用if守卫过滤出还需要进行CPU分配的application，再次过滤状态为alive并且可以被application使用的worker，然后按照其剩余的CPU数量倒序排序
- 把需要分配的application数量放入一个数组，然后获取最终需要分配的CPU数量=application需要分配的CPU和worker总CPU的最小值
- while遍历worker，如果worker还有可分配的CPU，将总的需要分配的CPU-1，给这个worker分配的CPU+1，指针移到下一个CPU。循环一直到CPU分配完，这种分配算法的结果是application的CPU尽可能的平均分配到了各个worker上，应用程序尽可能多的运行在所有的Node上
- 给worker分配完CPU后，遍历分配到CPU的worker，在每个application内部缓存结构中，添加executor，创建executorDSC对象，其中封装了给这个executor分配多少 CPU core，然后在worker上启动executor，将application状态改为RUNNING
- 如果是非spreadOutApps算法，刚好相反，先把每个worker的CPU全部分配完，在分配下一个worker的CPU
结合源码分析
Driver向Master进行Application注册的时候，Master注册完之后，会调用schedule()方法，进行资源调度。schedule()源码如下：
private def schedule(): Unit = {
// 首先判断master状态不是alive的话，直接返回，也就是说standby是不会进行资源调度的
if (state != RecoveryState.ALIVE) { return }
// Drivers take strict precedence over executors
// Random.shuffle的原理主要是遍历整个ArrayBuffer,随机交换从后往前的两个位置的数
// 对传入集合中的元素进行随机打乱
val shuffledWorkers = Random.shuffle(workers) // Randomization helps balance drivers
// 取出worker中之前所有注册上来的worker，进行过滤，worker必须是alive状态
for (worker <- shuffledWorkers if worker.state == WorkerState.ALIVE) {
// 首先调度Driver。
// 为什么要调度Driver，什么情况下会注册Driver，调度Driver？
// 其实只有用yarn-cluster模式提交的时候，才会注册Driver，因为Standalone和yarn-client模式
// 都直接在本地启动Driver，不会注册Driver，更不会让master调度Driver了
// 遍历等待调度的Driver
for (driver <- waitingDrivers) {
// 如果当前worker的空闲内存量，大于等于Driver需要的内存，
// 并且worker的空闲cpu core，大于Driver所需的cpu数量
// Driver是在Worker上启动的。。因此Worker节点的内存和CPU需要能够让Driver运行
if (worker.memoryFree >= driver.desc.mem && worker.coresFree >= driver.desc.cores) {
// 启动Driver
launchDriver(worker, driver)
// 从缓存中移除
waitingDrivers -= driver
}
}
}
// 对worker的调度机制，在worker上启动executor
startExecutorsOnWorkers()
}
从上述源码中可以看出，首先对所有已注册的worker进行随机打散；接着进行遍历，去除不是alive状态的worker，首先对Driver进行调度，为什么一开始要调度Driver？因为只有在yarn-cluster模式下才需要调度Driver，在这个模式下，YARN需要找一个NodeManager来启动Driver，因此需要在已注册的worker节点集合中寻找满足条件的worker，来启动Driver。由于standalone和yarn-client都是在本地启动Driver，所以无需进行调度。
调度完Driver之后，就正式开始进行executor的调度了，调用了方法startExecutorsOnWorkers()，源码如下：
private def startExecutorsOnWorkers(): Unit = {
// Right now this is a very simple FIFO scheduler. We keep trying to fit in the first app
// in the queue, then the second app, etc.
// Application的调度机制，默认采用的是spreadOutApps调度算法
// 首先遍历waitingApps中的appInfo，并且过滤出，还需要调度的core的app，
// 说白了，就是处理app需要的cpu core
for (app <- waitingApps if app.coresLeft > 0) {
// 这是脚本文件中的 --executor-cores 这个参数
val coresPerExecutor: Option[Int] = app.desc.coresPerExecutor
// Filter out workers that don't have enough resources to launch an executor
// 过滤掉没有足够资源启动的worker
// 从worker中过滤出状态为alive的worker，并且这个worker的资源能够被Application使用
// 然后按照剩余cpu数量倒叙排序，从大到小排序
val usableWorkers = workers.toArray.filter(_.state == WorkerState.ALIVE)
.filter(worker => worker.memoryFree >= app.desc.memoryPerExecutorMB &&
worker.coresFree >= coresPerExecutor.getOrElse(1))
.sortBy(_.coresFree).reverse
// cpu core 和 memory 资源分配
val assignedCores = scheduleExecutorsOnWorkers(app, usableWorkers, spreadOutApps)
// Now that we've decided how many cores to allocate on each worker, let's allocate them
// 给每个worker分配完资源给application之后
// 遍历每个worker节点
for (pos <- 0 until usableWorkers.length if assignedCores(pos) > 0) {
// 启动executor
allocateWorkerResourceToExecutors(
app, assignedCores(pos), coresPerExecutor, usableWorkers(pos))
}
}
}
这里的调度机制默认是采用FIFO的调度算法。首先在等待调度队列的App中取出一个Application，并且过滤出还需要调度core的App（还没有调度完的App）；接着读取App中的coresPerExecutors参数，代表了每个executor被分配的多少个cpu core（spark-submit脚本中可设置的参数 --executor-cores）；然后从worker中过滤出状态为alive的worker，然后对这些worker再过滤出它们的内存和cpu core能够启动Application的worker，也就是对存活着的worker中过滤出有足够资源去启动Application的worker，并按照cpu core的大小降序排序，下一步使用scheduleExecutorsOnWorkers()方法，给每个worker分配资源，最后使用allocateWorkerResourceToExecutors()启动executor。
下面看看，worker节点怎么被分配executor，scheduleExecutorsOnWorkers()源码如下：
private def scheduleExecutorsOnWorkers(
app: ApplicationInfo,
usableWorkers: Array[WorkerInfo],
spreadOutApps: Boolean): Array[Int] = {
// --executor-cores app中每个executor被分配的cores
val coresPerExecutor = app.desc.coresPerExecutor
// 每个worker最少被分配的cpu core，默认就是coresPerExecutor
val minCoresPerExecutor = coresPerExecutor.getOrElse(1)
// 如果没有设置--executor-cores 参数的话，就默认分配一个executor
val oneExecutorPerWorker = coresPerExecutor.isEmpty
// --executor-memory 每个executor要被分配的内存大小
val memoryPerExecutor = app.desc.memoryPerExecutorMB
// 可用worker的个数
val numUsable = usableWorkers.length
// 创建一个空数组，存储了要分配给每个worker的cpu core数量
val assignedCores = new Array[Int](numUsable) // Number of cores to give to each worker
// 每个worker上分配几个executor
val assignedExecutors = new Array[Int](numUsable) // Number of new executors on each worker
// 获取需要分配的core的数量，取app剩余还需要分配的cpu core数量 和 worker总共可用CPU core数量的最小值
// 如果worker资源总数不够，那么只能先分配这么多cpu core
// app.coresLeft = requestedCores - coresGranted，
// 其中requestedCores代表app需要分配多少个cpu core，coresGranted代表当前集群worker节点已经被分配了多少个core
var coresToAssign = math.min(app.coresLeft, usableWorkers.map(_.coresFree).sum)
/** Return whether the specified worker can launch an executor for this app. */
// 判断当前worker剩余 cpu core 和 memory是否能够分配给app运行
def canLaunchExecutor(pos: Int): Boolean = {
// 只要当前剩余的cpu core，还没有被分配完，这个标志位就是true
val keepScheduling = coresToAssign >= minCoresPerExecutor
// 当前worker剩余的core是否能够分配给App
val enoughCores = usableWorkers(pos).coresFree - assignedCores(pos) >= minCoresPerExecutor
// If we allow multiple executors per worker, then we can always launch new executors.
// Otherwise, if there is already an executor on this worker, just give it more cores.
// 每个worker资源足够的情况下，可以启动多个executor，
// 否则的话，就给当前启动的这个worker足够的core和memory
val launchingNewExecutor = !oneExecutorPerWorker || assignedExecutors(pos) == 0
if (launchingNewExecutor) {
// 当前节点已分配出去的内存
val assignedMemory = assignedExecutors(pos) * memoryPerExecutor
// 剩余内存是否足够分配
val enoughMemory = usableWorkers(pos).memoryFree - assignedMemory >= memoryPerExecutor
val underLimit = assignedExecutors.sum + app.executors.size < app.executorLimit
keepScheduling && enoughCores && enoughMemory && underLimit
} else {
// 在一个worker持续分配资源
keepScheduling && enoughCores
}
}
// 过滤掉资源不够的worker
var freeWorkers = (0 until numUsable).filter(canLaunchExecutor)
while (freeWorkers.nonEmpty) {
freeWorkers.foreach { pos =>
var keepScheduling = true
while (keepScheduling && canLaunchExecutor(pos)) {
// 当前worker内存和core资源足够分配给一个app
// 可用worker可用core减去已分配的core
coresToAssign -= minCoresPerExecutor
// pos节点worker已被分配出去多少core
assignedCores(pos) += minCoresPerExecutor
// If we are launching one executor per worker, then every iteration assigns 1 core
// to the executor. Otherwise, every iteration assigns cores to a new executor.
if (oneExecutorPerWorker) {
// 一个worker点一个executor
assignedExecutors(pos) = 1
} else {
// 资源足够的情况下，一个worker可以分配多个executor
assignedExecutors(pos) += 1
}
// Spreading out an application means spreading out its executors across as
// many workers as possible. If we are not spreading out, then we should keep
// scheduling executors on this worker until we use all of its resources.
// Otherwise, just move on to the next worker.
// 如果是spreadOutApps模式下，那么就每个worker在分配executor后，接着就到下一个worker上分配
// 循环分配，保证每个可用worker都可以分配到executor
// 如果不是，那么就给当前这个executor一直分配core，直到这个executor所在的节点资源
// 已经都分配完了。
if (spreadOutApps) {
keepScheduling = false
}
}
}
// 过滤掉资源不足的worker
freeWorkers = freeWorkers.filter(canLaunchExecutor)
}
assignedCores
}
从上面代码中可以看出，Master的资源调度算法主要有两个：一个是SpreadOut算法，另一个是非SpreadOut算法。区别从源码中就可以看出来，SpreadOut算法，是将executor尽可能的分配到较多的worker节点上，这样做的好处是，每个节点都能工作，防止资源浪费，而第二种就是将executor尽可能少的分配到worker，直到这个worker资源不足，才到下一个worker上分配资源。这里注意，这个算法相对老版本的算法做了优化，老版本中分配core的单位是1个，而这里则是按照spark-submit脚本中配置的–executor-cores，为单位进行分配，这里要注意。