动态资源分配

Spark提供了一种机制，可以根据工作负载动态调整应用程序占用的资源。这意味着如果您的应用程序不再使用，您的应用程序可能会将资源返回给群集，并在需要时再次请求它们。如果多个应用程序在Spark群集中共享资源，则此功能特别有用。

默认情况下禁用此功能，并且可在所有粗粒度集群管理器上使用此功能，例如独立模式，YARN模式和 Mesos粗粒度模式。

配置和设置

使用此功能有两个要求。首先，您的应用程序必须设置 spark.dynamicAllocation.enabled为true。其次，您必须在同一集群中的每个工作节点上设置一个外部随机播放服务，并spark.shuffle.service.enabled在应用程序中设置为true。外部shuffle服务的目的是允许删除执行程序，而不删除它们写入的shuffle文件（下面将详细介绍）。集群管理器的设置方式各不相同：

在独立模式下，只需启动您的工作人员spark.shuffle.service.enabled即可true。

在Mesos粗粒度模式下，$SPARK_HOME/sbin/start-mesos-shuffle-service.sh在spark.shuffle.service.enabled设置为所有从节点上运行true。例如，你可以通过马拉松来这样做。

在YARN模式下，请按照此处的说明进行操作。

所有其他相关的配置是可选的，下spark.dynamicAllocation.和 spark.shuffle.service.命名空间

资源分配政策

在高层次上，Spark应该在不再使用执行者时放弃执行者，并在需要时获取执行者。既然没有明确的方法来预测即将被删除的执行者是否会在不久的将来执行一个任务，还是将要添加的新的执行者实际上是空闲的，那么我们需要一套启发式来确定何时删除并请求执行者。

请求政策

启用动态分配的Spark应用程序在等待等待调度的任务中请求附加执行程序。这种情况必然意味着现有的执行者集合不足以同时使所有已经提交但尚未完成的任务饱和。

Spark要求执行者轮回。当有待处理的任务持续spark.dynamicAllocation.schedulerBacklogTimeout几秒钟时，触发实际请求，spark.dynamicAllocation.sustainedSchedulerBacklogTimeout然后如果挂起的任务队列仍然存在，则每秒钟再次触发。此外，每轮要求的执行人数从上一轮呈指数级增长。例如，一个应用程序将在第一轮中添加1个执行者，然后在后续的回合中添加2,4,8个等等执行者。

指数增长政策的动机是双重的。首先，一个应用程序应该在开始时谨慎地请求执行者，以防只有少数额外的执行者是足够的。这回应了TCP慢启动的理由。第二，应用程序应该能够及时提高其资源使用情况，以证明实际需要许多执行者。