Design and Implementation of Scheduling Pool Scheduling Algorithm Based on Reuse of Jobs in Spark理解

论文：Design and Implementation of Scheduling Pool Scheduling Algorithm Based on Reuse of Jobs in Spark

摘要：

1. 本文中的reuse of jobs指的是the calculation reuse inside the jobs，这样的reuse可以大大的缩短Spark 中的作业的执行时间。
2. 本文提出的是基于作业重用（reuse of jobs）的调度池调度算法，本文调度算法是基于Spark中的原始调度池调度算法并充分利用可以重用的部分（the calculation reuse）。
3. 实验证明本文算法实现了作业重用并提高了集群的执行效率。

---

引言

1. Spark中两种主要的作业调度算法：FIFO调度算法 和 FAIR调度算法，但是这两种算法在实际应用中都有一些不足，特别是在多用户和多作业的应用中。
2. 在多用户和多作业的应用中存在大量的可重用部分。
3. 本文的创新点有:
   1）该算法引入了重用匹配机制，可以自动重用不同的作业; 用户无需手动编写程序来确定需要重用哪些作业;
   2）重用是在该算法中的应用程序之间，而不仅仅是在同一个应用程序中;
   3）该算法是Spark中原始调度算法的改进，不再采用FIFO或轮询方式来调度作业。 同时，为了保证调度效率，引入了调度母池和安全距离的概念。

---

Spark中的作业调度算法

Spark中的作业调度是作业调度程序将作业分配给下一个层次调度程序以进一步调度和执行的过程。 当用户在客户端计算机上提交应用程序时，Spark中的DAG调度程序 将通过执行这些应用程序来生成许多作业。 然后，Spark中的Job调度程序 将根据集群的资源条件和这些作业的优先级需求进行合理的资源分配。（也不知道讲的啥，翻译的。。。）
Spark中的作业可以分为两类，一类是作业之间存在依赖关系，因此生成后的这类作业将通过FIFO或FAIR调度算法进行调度; 另一种是作业之间没有依赖关系，因此生成后的这种作业将被放入调度池中，然后由调度池中的FIFO和FAIR调度算法进行调度。 在实际应用中，依赖关系的存在在用户查询等作业中的可能性较小，因此本文仅讨论了作业之间没有依赖关系的作业调度。

1、FIFO算法

FIFO调度算法是Spark中首次出现的作业调度算法（现为默认调度算法）。Spark集群将以FIFO的形式执行作业调度队列中的作业（先第一个，再第二个…）。但是，当执行的作业不占用集群的所有资源并且剩余资源能够满足队列中的后续作业时，后续作业将立即执行。
优点：简单易行，系统开销小。
缺点：很可能会导致很多空闲的集群资源，特别是当存在大量并行作业时，执行效率低。同时，该算法不考虑作业的特殊要求。
特点：是有利于长期工作，不利于短期工作。
鉴于FIFO算法的缺点，Spark的0.8版本中提出了FAIR算法

2、FAIR算法

FAIR调度算法主要是解决作业调度中的公平性问题。 在此算法中，Spark集群以滚动轮询的形式执行作业，并且所有作业都可以公平地共享集群资源。 因此，短期工作也可以获得资源并执行。
优点：可以很好地解决短作业可能处于长等待状态的不公平问题，并确保所有作业可以公平地共享集群资源，从而提高集群资源的利用率。
缺点：FAIR调度算法通过频繁的中断和频繁的作业上下文切换实现轮询的目的，这大大增加了集群的开销，从而降低了作业的执行效率。

3、调度池调度算法

Spark中的调度池调度算法主要使用Hadoop中的FAIR调度算法作为参考，并根据自己的机制进行一些更改。 该调度算法的实现主要取决于调度池。
1）调度池的主要参数
Spark中的调度池实际上是一个放置已准备好被调度作业的容器。调度池有三个关键参数。一个是调度模式，它支持FIFO和FAIR两种调度算法。此参数用于控制调度池中作业的执行方式。一个是权重，表示一个调度池相对于其他调度池占用的集群资源的大小（默认值为1，表示所有调度池都获得相同数量的集群资源）。另一个参数是minshare，它指示每个调度池可以获得的最小群集资源量。当作业调度程序分配集群资源时，它确保每个调度池可以获取minshare资源的数量（默认值：0）。
另外：用户还可以为调度池设置名称，使用该名称将其与其他用户的调度池或Spark的默认调度池区分开来。
用户可以在Spark中的配置文件中手动设置上述参数。
2）调度池的调度过程

图1描述了Spark中调度池的调度过程。用户提交应用程序后，Spark集群执行应用程序并根据调度池的配置文件生成相应的调度池，然后将所有用户的作业放入调度池中。这些调度池根据权重值获取集群资源。在调度池内，根据用户设置的调度模式，Spark集群将确定作业的调度方式。如果设置为FIFO模式，那么Spark集群将按照FIFO调度算法在该调度池中执行作业，如果设置为FAIR模式，那么Spark集群将按照FAIR调度算法执行工作。同时，为了防止小权重调度池中的作业长时间无法获取资源的现象，spark集群将根据用户设置的minshare集合的值为这些调度池分配最少量的资源，以便小权重调度池能够在某个群集资源下执行其作业。这确保了调度池的作业调度公平性。
3）调度池调度问题
调度池算法可应用于多用户模式下，但是每个用户为其作业创立独自的调度池，故每个调度池只能调度自己池中的作业，虽然这也是一种并行，但是却使得不同调度池间的作业重用不起作用，这一点也成为提高Spark中多用户和多作业应用模式性能的主要制约因素。
调度算法的两个关键点：效率和公平性。 但是，调度池中采用的FIFO和FAIR调度算法不能同时满足这两个点。 为了改善这种情况，满足Spark中多用户多作业应用模式的需求，提出了一种基于作业重用的Spark调度池调度算法。 基于现有的调度池调度算法，该算法引入了重用机制，再保证公平性不变的情况下，提高了作业的执行效率。

---

基于作业重用的调度池调度算法

1、算法描述与分析

该算法是对调度池内原始FIFO调度算法的重写。 具体算法描述如下：

1. 第一步：选出占用集群资源最多的调度池$Pool_i$作为重用匹配的母池;
2. 第二步：缓存$Job_1$（位于$Pool_i$内部作业队列头部的作业），并在开始执行时缓存$Job_1$的每个计算结果;
3. 第三步：对于其他的调度池$Pool_j$，我们选择其中的第m个作业作为分界线，m的位置称为安全距离。 作业调度程序将选择第（m + 1）个作业，第（m + 2）个作业…直到作业队列的最后一个作业分别与$Pool_i$内的$Job_1$匹配（基于重用）。 同时，记录$Pool_j$内每个作业的重用度D，形成重用度集合{$D_m$$_ +$$_1$，$D_m$$_ +$$_2$，$D_m$$_ +$$_3$…̙};
4. 第四步：从上述重用度集合{$D_m$$_ +$$_1$，$D_m$$_ +$$_2$，$D_m$$_ +$$_3$…̙}中，选出最大重用度$D_m$$_a$$_x$。 并缓存重用度$D_m$$_a$$_x$对应的的作业$Job_m$$_a$$_x$，然后根据已经缓存的$Job_1$的计算结果，重写$Job_m$$_a$$_x$的重用部分;
5. 第五步：将已完成重写的$Job_m$$_a$$_x$放回$Pool_j$内作业队列的头部，然后等待执行;
6. 第六步：重复第二步到第五步的过程。

图2显示了整个上面的调度过程。
下面我们将分析新算法的三个方面：第一个方面是如何选择重用匹配$Pool_i$ 池（母池）。在此算法中选择与其他调度池相比具有最多占用集群资源的那个作为重用匹配的母池。原因是如果我们选择一个集群资源很少的调度池作为重用匹配的母池，可能会出现这样的情况：由于重用匹配的母池占用很少的资源，那些具有更多集群资源的调度池可能会有当它（母池？）只完成一两个工作时，他们（具有更多集群资源的调度池？）已经完成了所有的工作。也就是说那些具有大量集群资源的调度池中的作业只有机会与重用匹配的母池内的一个或两个作业相匹配（所以前面讲的其它池完成了所有工作是说可以相匹配的工作？而不是全部作业？），在重用匹配后，作业的重用程度将越来越低。因此，在这种情况下，我们无法实现作业之间的最大重用。因此，非常有必要挑选占用大量集群资源的调度池作为重用匹配的母池。
第二个方面是如何选取m。 如果m的值太小，则很可能在匹配时执行作业，或者与重用匹配的母池内的$Job_1$匹配。 因此，这些工作没有机会被重写，所以没有重用它们。 同时，如果m的值太大，则会导致作业队列中有少量作业重用匹配，因此也会导致低重用度。 因此，为了估算合适的m，需要估计作业队列内作业的执行时间以及预先重用匹配和重写的开销。
第三个方面是考虑如何计算重用度D.我们比较重用度D的大小，以确定应该在调度池内的这些作业中重写和调度哪个作业。 我们可以使用以下方法计算每个作业的重用度D：将等待调度的作业与重用匹配的母池内的$Job_1$匹配，每次重用一个作业时，作业的重用度D自动加一。 这样，每个作业的重用度D将是一个整数，并且不同作业之间的重用度的比较将变得非常方便。

2、算法的性能分析

为了反映基于作业重用的调度池调度算法的性能优势，下面将分析集群的吞吐量和作业的响应时间。

1. 作业的响应时间
   群集中作业的响应时间（$T_r$）是指其完全完成时间减去其被提交到群集的时间。 它包括两部分：作业的等待时间（$T_w$）和作业的执行时间（$T_e$）。 三者之间的关系如公式1： $$T_r=T_w+T_e$$ 同时，作业的响应时间越短，作业的执行效率越高。 并且公式1表明等待时间和作业的执行时间决定了作业的响应时间。 因此，为了提高作业的执行效率，我们可以通过缩短作业的等待时间和作业的执行时间来缩短作业的响应时间。
   在算法中，由于重用机制，作业在写入后执行时不需要重新计算重用的部分，从而大大缩短了这些作业的执行时间。作业的重用度D越大，作业执行时间的影响就越明显。而且，一旦作业被重写，它将被直接安排到调度池内的作业队列的头部等待执行，这大大减少了这个作业的等待时间。 同时，队列中其他作业的等待时间也将大大减少，因为每个作业的执行速度在重写后变得更快。 这意味着整个队列中作业的平均等待时间已显着减少。
   通过以上分析，我们可以看出该算法既减少了作业的执行时间，又减少了作业的等待时间，从而有效缩短了作业的响应时间，提高了作业的执行效率。
2. 集群的吞吐量
   此处，群集的吞吐量是指群集单位时间内处理的作业数。 集群的吞吐量越大，调度算法的效率越高。 （原始调度算法缺点 start）在原始调度池调度算法中，如果调度池采用FIFO算法，则意味着位于作业队列后面的作业将浪费很长时间等待位于前面的作业完成。 工作队列。 如果它采用FAIR算法，将会频繁中断和频繁的作业上下文切换，这将导致集群的低吞吐量。（end）
   对于基于作业重用的调度池调度算法，由于存在重用机制，一些作业的大小在重用匹配和重写后会在一定程度上减少，这相当于“缩小” 这些工作。 这意味着群集可以同时处理更多作业，因此可以有效地提高群集的吞吐量。 而且，这些作业的重用度D越大，集群的吞吐量就越大。

---

实验部分

1、实验环境

在本实验中，使用三个服务器构建Spark集群环境（其中一个服务器作为主节点，另外两个服务器作为Worker节点（工作节点？））。 每台服务器的CPU数量为2个，共8个内核，内存容量为96 GB，硬盘容量为13 TB。 每个服务器都安装了Spark for 1.5.2版本，Hadoop版本2.6（为了使用HDFS平台存储实验数据），每个服务器的操作系统都是KYLIN操作系统（是啥？）。
实验数据来自Amplab大数据基准测试，该测试使用Pavlo等人开发的网络分析工作负载。 基准测试包含四种类型的查询，其中不同的参数执行扫描，聚合，连接和基于UDF的MapReduce作业，我们选择前三个查询进行实验。 实验数据是两个表，数据量达到27 GB。 同时，我们将分别使用三种调度算法：Spark中的原始调度池调度算法（OSPSA），基于重用的FIFO算法（FIFOBOR）和基于作业重用的调度池调度算法（SPSABOR） 来说明不同算法的性能。 我们将安全距离m设置为5。

2、实验结果

图3描述了使用上述三种算法在三个不同查询中作业的响应时间。在此图中，水平坐标表示每种类型的查询需要执行的数据量。 A表示大约500 MB的少量数据，B表示大约7 GB的中间数据量，C表示大约27 GB的大量数据。垂直坐标表示作业的响应时间。从这个图中，我们可以看到，在每种类型的查询中，无论数据的大小如何，SPSABOR算法的作业响应时间总是最小的，其次是FIFOBRO，最后是OSPSA。这是因为FIFOBRO算法使用了重用机制，因此作业的响应时间比OSPSA短，但它仍然使用FIFO调度算法，与我们提出的SPSABOR相比，调度效率更差。这与我们之前的分析一致。值得一提的是，相对于其他两种类型的查询，与其他两种调度算法相比，SPSABOR算法在连接查询中的性能有了更大的提高。这表明SPSABOR算法更适合于计算密集型作业，因为在这种情况下，作业之间重用的可能性要大得多。
同时，从扫描查询的图中，我们可以发现FIFOBRO算法的作业响应时间比OSPSA算法长，这是由于缓存重用部分和重写需要额外开销的作业。 虽然SPSABOR算法也有这样的开销，但其性能提升幅度远高于其开销量，因此它仍具有良好的性能优势。

---

结论

作为一种基于内存的分布式计算框架，Spark得到了越来越多企业的支持和应用。 如何进一步提高Spark的性能已成为Spark的开发者和应用者的关注。 在多用户和多作业的应用模式中，由于大量作业之间的相互作用，必须具有较高的重用率。 正是考虑到这一点，为了克服Spark中原始调度算法的不足，我们提出了基于作业重用的调度池调度算法。 该算法保持了原调度池调度算法的公平性，同时大大利用了不同应用中作业的重用，从而提高了spark的调度性能。 实验表明，基于作业重用的调度池调度算法可以大大缩短响应时间，提高Spark集群的吞吐量。

---

over，基本翻译的，读者可以参考原论文。