Cross-Platform Resource Scheduling for Spark and MapReduce on YARN论文理解

Cross-Platform Resource Scheduling for Spark and MapReduce on YARN论文理解

摘要

1. MapReduce不能有效的处理大数据的非批处理过程（例：交互式作业，实时查询和流计算）；新兴的Apache Spark则可以处理这一过程，Spark可以在已建立的Hadoop集群上运行并利用现有的HDFS。
2. 在YARN上部署Spark的三个主要挑战
   1）基于预留的资源管理不灵活
   2）任务间依赖性盲调度
   3）Spark和MapReduce应用程序之间的局部干扰
   这三个挑战导致资源利用效率低下和性能显着下降。
3. 本文提出并开发了一个跨平台资源调度中间件iKayak，旨在提高多租户Spark-on-YARN集群的资源利用率和应用程序性能。
4. iKayak依赖于三个关键机制（分别对应以上三个主要挑战）
   1）预留感知执行器放置以避免长时间等待资源预留
   2）依赖性感知资源调整以利用reduce任务占用的未充分利用资源
   3）跨平台位置感知任务分配以协调位置之间的竞争Spark和MapReduce应用程序
5. 实验结果部分
   本文在YARN实施iKayak。测试平台上的实验结果表明，与两种流行的Spark-on-YARN部署模型（即YARN客户端模型和YARN集群模型）相比，iKayak可以使Spark应用程序的性能提高50％，MapReduce应用程序的性能提高19％。

关键字：

Spark-on-YARN，资源调度，跨平台，应用程序性能，预留感知执行器放置，依赖性感知资源调整，位置感知任务分配

引言

1. MapReduce由于其one-pass 计算模型，使得它不合适低延迟应用程序（low-latency applications）和迭代计算（iterative computations）；Spark可解决这些。。。问题？
2. Spark使应用程序可以将数据可靠地存储在内存中。 每个Spark应用程序都有多个进程，称为执行程序，在集群上运行，即使在没有运行任何作业时也代表它在内存中加载相关数据。 它允许应用程序避免昂贵的磁盘访问，这是Spark高性能的关键。（所以：一般通过集成Spark进行交互式和流式计算。）
3. 具有动态资源分配的单个集群管理器可以提高资源利用率。企业更愿意在现有的Hadoop集群上部署新兴的Spark应用程序，以便利用已建立的集群，访问现有的HDFS数据集，并利用Hadoop的安全环境。（例如，eBay和Yahoo! 使用MapReduce生成报告并回答历史查询，同时部署Spark以实时计算关键指标。）
4. Hadoop YARN 是一个新兴的跨平台集群管理器。它允许多个计算平台在单个集群上共存和共享资源，并从其细粒度的资源管理方案中受益。然而，我们发现YARN的基于预留的资源调度策略Spar应用程序的动态需求之间存在语义差距，导致资源利用效率低下和应用程序性能低下。具体而言，Spark-on-YARN引发了三个关键挑战。（即摘要中的三个主要挑战）（再一次描述如下）
   1） YARN基于预留的资源调度策略使得资源需求高的任务很难及时获得所需的资源。
   2）YARN中的现有调度程序无法识别map和reduce任务之间依赖关系的影响。
   3）MapReduce和Spark应用程序都尝试将任务或执行程序与其相关的HDFS块一起放置以进行位置感知，同时他们需要与YARN协商进行资源调度。
5. Spark是基于多线程编程模型。 此特征可能导致Spark的单个执行程序一次占用大量资源的情况。 因此，具有高资源需求的执行器可能必须等待很长时间才能进行资源预留，导致资源利用率低和性能差。 更糟糕的是，当要保留所需资源但在很长一段时间内不能满足时，对于具有非常大的资源需求（例如，Spark流）的一些作业可能发生饥饿。
6. 跨平台资源调度中间件iKayak的提出和开发，具体设计：首先设计和开发一个预留感知执行器放置机制，为Spark执行器选择有效的托管节点，以实现更短的预留时间。（目的：及时满足执行者的高资源需求）；然后，设计和开发依赖性感知资源调整机制，以自适应地控制由reduce任务未充分利用的资源。（目的：允许map任务从reduce任务中抢占资源）；最后，进一步设计和开发了一个跨平台的任务分配机制，以协调MapReduce任务分配和Spark执行器放置之间的位置感知。（目的：增加共同托管Spark和MapReduce应用程序的节点上的本地数据访问机会）。
7. 实验部分，不写了= =

动机

YARN的资源预留机制

YARN中基于预约的调度。 与第一代Hadoop相比，YARN采用细粒度资源管理，这意味着应用程序可以在提交作业时为各个任务配置所需的资源，如CPU和内存。 如果群集中没有足够的可用资源，ResourceManager将开始在所选节点上为该任务预留资源。 完成此节点上的其他任务后，可以为即将执行的任务分配更多可用资源。 在满足预留之前，此节点上释放的资源将不允许分配给其他应用程序。 在预留过程中，新发布的资源被累积但不允许使用，这提供了良好的资源隔离能力，但导致资源利用率不高。

spark简介

使用Spark进行内存计算。 Spark是一种崭露头角的大数据分析解决方案，通过使用高效的内存计算开发。它允许应用程序在内存中显式缓存数据集，以便应用程序可以从内存而不是磁盘访问数据，这可以显着提高性能。与MapReduce相比，Spark利用多个线程而不是多个进程来实现单个节点上的并行性，避免了几个JVM的内存开销，但导致单个执行器一次占用大量资源。当作业提交到集群时，应由用户配置特定Spark应用程序的资源需求（即，执行程序的数量和每个执行程序的资源请求）。 Spark可以在两种流行的模式下运行：Spark-on-Mesos和Spark-on-YARN。 Spark-on-Mesos采用“全有或全无”资源管理策略（例如，一次分配足够的资源或拒绝请求），这可能会导致出现故障，特别是在集群繁忙时。但是，YARN将保留（预留）资源而不是拒绝申请以避免这种饥饿。

Spark-on-YARN

在Spark-on-YARN部署模式中，Spark应用程序类似于MapReduce的作业。 如图1所示，MapReduce在自己的进程中运行每个任务。 任务完成后，该过程就会消失。 在Spark中，许多任务可以在单个进程（即执行程序）中并发运行，并且即使没有正在运行的作业，此进程也会在Spark应用程序的生命周期内保持不变。 因此，MapReduce不会受到基于预留的调度策略的影响，因为大多数map / reduce任务的预留时段由于其极小的资源需求而非常短。 但是，在YARN的当前资源调度策略下，具有单个容器的巨大资源需求的Spark应用程序可能遭受太长的资源预留期。

挑战

1. Ineffective Resource Utilization（资源利用率低下）
2. Underutilized Reduce Tasks（未充分利用Reduce任务）
3. Locality-Missing Assignment（局部缺失管理？缺乏局部性感知）

对应的三条解决方法：

1. 应将Spark执行器放置在合适的节点上，以及时满足其资源预留，避免等待时间过长，资源利用率低。
2. 分配用于Reduce任务的资源应根据其随时间变化的需求进行重新平衡，以避免在将任何Spark应用程序提交到群集时浪费资源。
3. 应优化Spark和MapReduce应用程序的任务分配，以减少局部性感知竞争，同时考虑Spark和MapReduce应用程序的位置感知。（感觉讲来讲去也就这三个。。。）

HDFS

HDFS通常在集群中有三个数据副本，这可以改善数据的位置。Spark和MapReduce都应用延迟调度来基于位置偏好来调度任务，即，他们尝试将任务调度到具有本地数据的节点上。 因此，即使群集中存在多个副本，Spark和MapReduce之间的这种位置感知竞争也会使它们都缺乏局部性感知。

iKayak设计

iKayak是一个跨平台的资源调度中间件，旨在优化Spark-on-YARN集群中的资源管理。 它利用了Spark和MapReduce应用程序的不同资源需求特性，并在考虑两个应用程序的数据局部性的同时动态优化资源调度。 图2显示了iKayak的架构。 它有三个主要组件：预留感知执行器放置，依赖性感知资源调整和位置感知任务分配协调。

三个组件细化：

1. 保留感知执行器放置自适应地将Spark执行器放置在有效的托管节点上，以便及时满足各个执行器的高资源需求。
2. 依赖性感知资源调整动态地利用分配的资源来减少任务，以缓解由于资源过度配置而导致的低资源利用率，尤其是当reduce任务空闲并等待来自map任务的中间数据时。
3. 位置感知任务分配协调可提高Spark和MapReduce应用程序的数据位置感知，以便它们可以共享多租户群集节点上的有限本地数据访问机会。

Reservation-Aware Executor Placement(预订意识执行者安置)

…部分翻译：
Spark提供了两个默认执行程序放置调度程序，即SpreadOut和Non-SpreadOut，用于将执行程序放置在集群中的多个节点上。它们都无法以资源预留感知方式放置执行程序。在YARN上运行Spark时，每个Spark执行程序都在YARN容器中运行。 Spark ApplicationMaster负责与YARN协商资源请求，并找到一组有效的主机来放置和运行执行程序。但是，YARN无法识别Spark应用程序的高效工作节点，因为它最初是为MapReduce计算而设计的。 MapReduce为每个任务调度容器并启动JVM，而Spark在同一容器内托管多个任务以进行多线程。相应地，Spark的单个容器的资源需求远远大于MapReduce的单个任务的资源需求。因此，MapReduce作业的默认“基于拉”的任务调度方法不适合Spark应用程序的执行程序放置。

Resource Reservation Analysis 资源预留分析
本文提出基于群集中每个可能的目标节点的资源预留感知开发有效的执行器放置算法。 该算法旨在使执行程序在放置在选定的工作节点上后尽快运行。 如算法1所示，它首先选择具有足够空闲资源的高效工作节点，以满足各个执行者的需求。 如果节点上没有足够的可用资源，iKayak会选择承载足够运行映射任务的高效工作节点来放置执行程序。 如果仍然没有足够的资源，iKayak最终会选择一个托管减少任务接近完成的节点。

Estimating Reduce Remaining Time 估计Reduce剩余时间
后面不想看了= =

---

本文spark-on-YARN指：Spark（Spark+MapReduce）-on-YARN
hosting a Spark application----托管Spark应用