Spark on Yarn解密及运行流程

一、Hadoop Yarn解析

1，Yarn是Hadoop推出整个分布式（大数据）集群的资源管理器，负责资源的管理和分配，基于Yarn我们可以在同一个大数据集群上同时运行多个计算框架，例如Spark、MapReduce、Storm等；
2，Yarn基本工作流程如下图所示：

注意：Container要向NodeManager汇报资源信息，Container（程序员）要向App Mstr（项目经理）汇报计算信息；

3，客户端Client向ResourceManager（老总，管理整个集群的资源）提交Application，ResourceManager接受应用并根据集群资源状况决定在某个具体Node上来启动当前提交的应用程序的任务调度器Driver（ApplicationMaster），决定后ResourceManager会命令具体的某个Node上的资源管理器NodeManager（管理当前机器的内存，cpu等资源的）来启动一个新的JVM进程运行程序的Driver部分，当ApplicationMaster启动的时候（会首先向ResourceManager注册来说明自己负责当前程序的运行）会下载当前Application相关的Jar等各种资源并基于此决定具体向ResourceManager申请资源的具体内容，ResourceManager接受到ApplicationMaster的资源分配的请求之后会最大化的满足资源分配的请求并发送资源的元数据信息给ApplicationMaster，ApplicationMaster收到资源的元数据信息后会根据元数据信息发指令给具体机器上的NodeManager让NodeManager来启动具体的Container，Container在启动后必须向AppplicationMaster注册，当ApplicationMaster获得了用于计算的Containers后，开始进行任务的调度和计算，直到作业的完成。需要补充说的是，如果ResourceManager第一次没有能够完全完成ApplicationMaster分配的资源的请求，后续ResourceManager发现集群中有新的可用资源时候，会主动向ApplicationMaster发送新的可用资源的元数据信息以提供更多的资源用于当前程序的运行！
补充说明：
1、container如果是Hadoop的MapReduce，不可复用，Spark on Yarn 可以复用
2.Container的销毁由具体的ApplicationManager销毁，ApplicationManager发指令给NodeManager来销毁Container

扩展：新旧 Hadoop MapReduce 框架比对

让我们来对新旧 MapReduce 框架做详细的分析和对比，可以看到有以下几点显著变化：

首先客户端不变，其调用 API 及接口大部分保持兼容，这也是为了对开发使用者透明化，使其不必对原有代码做大的改变 ，但是原框架中核心的 JobTracker 和 TaskTracker 不见了，取而代之的是 ResourceManager, ApplicationMaster 与 NodeManager 三个部分。

我们来详细解释这三个部分，首先 ResourceManager 是一个中心的服务，它做的事情是调度、启动每一个 Job 所属的 ApplicationMaster、另外监控 ApplicationMaster 的存在情况。细心的读者会发现：Job 里面所在的 task 的监控、重启等等内容不见了。这就是 AppMst 存在的原因。ResourceManager 负责作业与资源的调度。接收 JobSubmitter 提交的作业，按照作业的上下文 (Context) 信息，以及从 NodeManager 收集来的状态信息，启动调度过程，分配一个 Container 作为 App Mstr

NodeManager 功能比较专一，就是负责 Container 状态的维护，并向 RM 保持心跳。

ApplicationMaster 负责一个 Job 生命周期内的所有工作，类似老的框架中 JobTracker。但注意每一个 Job（不是每一种）都有一个 ApplicationMaster，它可以运行在 ResourceManager 以外的机器上。

Yarn 框架相对于老的 MapReduce 框架什么优势呢？我们可以看到：

这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。

在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。

对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。

老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。

Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 Java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有

二、Spark on Yarn 两种运行模式
Spark on yarn的两种运行模式实战：此时不需要启动spark集群，只需启动yarn即可！yarn的ResourceManager相当于spark standalone模式下的master！

1.spark on yarn的两种运行模式：唯一的决定因素是当前application从任务调度器driver运行在什么地方！

a) Cluster:driver运行的yarn集群下的某台机器上的jvm进程中！！！

b) Client：driver运行在当前提交程序的客户机器上，需要说明的是：无论是什么模式，只要当前机器运行了spark代码，就必须安装spark！

2.Spark on yarn的运行实战：

a) client模式：方便在命令终端直接看到运行的过程信息，尤其方便做测试使用，

例如：

./spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode client ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 50000

并行度变成50000，相当于50000台机器（1000-》50000）

Spark天机解密：Standalone模式下启动Spark集群（也就是启动Master和Worker）其实启动的是资源管理器，真正作业计算的时候和集群资源管理器没有任何关系，所以Spark的Job真正执行作业的时候不是运行在你启动的Spark集群中的，而是运行在一个个JVM中的，只要在JVM所在的机器上安装配置了Spark即可！！！

3.Spark on yarn 模式下Driver和application的关系：

a) cluster:driver位于ApplicationMaster进程中，我们需要通过hadoop默认指定的8088端口来通过web控制台查看当前的spark程序运行的信息，例如进度，资源的使用；

b) client：driver为提交代码的机器上，此时applicationmaster依旧位于集群中且只负责资源的申请和launchExecutor，此时启动后的executor并不会向applicationmaster进程注册，而是向driver注册！

三 最佳实践

1． Spark on yarn 模式下hadoop yarn的配置yarn.nodemanager.local-dir会覆盖spark.local.dir!!!

2． 在实际生产环境下一版是采用cluster，我们会通过history server来获取最终全部的运行信息；

3． 如果想直接看运行的日志信息，可以使用一下命令：

Yarn  logs –applicationId <app ID>