<YARN><MRv2><Spark on YARN>

MRv1 VS MRv2

• MRv1:

  - JobTracker: 资源管理 & 作业控制
  - 每个作业由一个JobInProgress控制，每个任务由一个TaskInProgress控制。由于每个任务可能有多个运行实例，因此，TaskInProgress实际管理了多个运行实例TaskAttempt，每个运行实例可能运行了一个MapTask或ReduceTask。每个Map/Reduce Task会通过RPC协议将状态汇报给TaskTracker，再由TaskTracker进一步汇报给JobTracker。

• MRv2 / YARN:

  - ResourceManager: 资源管理
  - MRAppMaster：作业控制。MRAppMaster只负责管理一个作业，包括该作业的资源申请、作业运行过程监控和作业容错等。MRAppMaster会与ResourceManager、NodeManager通信，以申请资源和启动任务。

MRv1的不足

• JobTracker是MR框架的中心，存在单点故障。它需要与集群中的机器定时通信(heartbeat)，需要管理哪些程序应该运行在哪些机器上，管理所有job失败，重启等。
• JobTracker完成了太多的任务，造成了过多的资源消耗，当job过多时，造成了很大的内存消耗，潜在地也增加了JobTracker的风险。【所以MRv2的重构思想是分离JobTracker-->资源管理 + 任务调度】
• 在TaskTracker端，仅仅以map/reduce task数目作为资源的表示过于简单。未考虑到cpu&内存的占用情况。若两个大内存消耗的task被调度到一块的话，很容易出现OOM(out of memory)。【因此MRv2的改进就是：为Application分配container，资源包括内存、CPU、磁盘、网络等等。】
• 在TaskTracker端，把资源强制划分为map task slot & reduce task slot。当系统中只要map task或只有reduce task时，会造成资源的浪费。

YARN架构

• Client：提交分布式程序的客户端，上传资源文件和JAR包到HDFS集群；
• ResourceManager：负责将集群的资源分配给各个应用使用；【RM是一个中心的服务，它调度、启动每一个Job所属的AM，监控AM的存在情况。】
• Container：资源分配和调度的基本单元，其中封装了的资源如内存、CPU、磁盘、网络带宽等。每个任务会被分配一个Container，并在该Container中执行且只能使用其封装的资源。
• NodeManager：计算节点，负责启动Container，同时通过心跳不断地与RM通信，描述该Worker节点的资源（ CPU,内存，硬盘和网络带宽等）状况。【NM的功能比较专一，即负责Container状态的维护，并向RM保持心跳。】
• AppMaster：对应client提交的一个应用。客户端每提交一个应用,RM会在Worker节点上给它分配一个全局唯一的App master，App master可以在任何一台Worker节点上启动，负责管理作业的整个生命周期，包括通知NM创建Container，管理Container等。【AM负责一个Job生命周期内的所有工作。】
• YARN中分离出AM，还使得AM变成一个可变更的部分，用户可以对不同的编程模型写自己的AM，让更多类型的编程模型能够跑在Hadoop集群上。

MRv2工作流程

• RM收到client请求后，会在全局查看资源，如果哪台worker合适，其上运行的NM就为该作业生成container实例。生成的第一个Container实例内运行的就是AppMaster。AppMaster运行成功的时候要向RM进行注册。
• AppMaster向RM申请资源(eg:10个Container)，得到消息反馈后，控制NM启动Container并运行任务，Container启动后直接对App Master负责（作业的调度中心是App Master，极大的减轻的RM的负担）。
• Tip:如果没有足够的container可以被申请,则会进行等待其他作业完成任务，空出Container后进行分配。
• App Master监控容器上任务的执行情况，反馈作业的执行状态信息和完成状态。

MRAppMaster

• MRAppMaster是MR的ApplicationMaster实现，它使得MR计算框架可以运行于YARN之上。
• 在YARN中，MRAppMaster负责管理MapReduce作业的生命周期，包括创建MapReduce作业，向ResourceManager申请资源，与NodeManage通信要求其启动Container，监控作业的运行状态，当任务失败时重新启动任务等。

整体框架

• YARN使用了基于事件驱动的异步编程模型，它通过事件将各个组件联系起来，并由一个中央事件调度器统一将各种事件分配给对应的事件处理器。
• TBD...

作业生命周期

• MRAppMaster类中的作业创建入口

• public class MRAppMaster extends CompositeService{
      public void start(){
          ...
          job = createJob(getConfig());  // 创建Job
          ...
      }

• 作业初始化: 
• 作业启动：
• TBD...

Protocal Buffer

• Hadoop2.x中已经将Protocal Buffer作为默认的序列化/反序列化框架，原来的自己实现的基于Writable的方式已经被淘汰了。
• PB是Google开源的一种轻量级的结构化数据存储格式，可以用于结构化数据的序列化/反序列化，很适合做数据存储或 RPC 数据交换格式。
• 优点是序列化/反序列化速度快，网络或者磁盘IO传输的数据少，支持向后兼容，这在可扩展地数据密集型应用中是非常重要的。
• 关于PB： TBD...

Resource Manager

• 在YARN中，ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationManager）。
• RM主要由以下几个部分组成：
  • 用户交互：
  • NM管理：
    • NMLivelinessMonitor：监控NM是否alive。若一个NM在一定时间内(默认10min)未汇报信条信息，则认为NM dead，将其移除集群。
    • NodesListManager：维护正常节点和异常节点列表，管理exlude（类似于黑名单）和inlude（类似于白名单）节点列表，这两个列表均是在配置文件中设置的，可以动态加载。
    • ResourceTackerService：处理来自NM的请求，主要包括两种请求：注册和心跳。其中，注册是NodeManager启动S时发生的行为，请求包中包含节点ID，可用的资源上限等信息，而心跳是周期性行为，包含各个Container运行状态，运行的Application列表、节点健康状况（可通过一个脚本设置），而ResourceTrackerService则为NM返回待释放的Container列表、Application列表等。
  • AM管理：
    • AMLivelinessMonitor：监控AM是否alive，如果一个ApplicationMaster在一定时间（默认为10min）内未汇报心跳信息，则认为它dead，它上面所有正在运行的Container将被认为死亡，AM本身会被重新分配到另外一个节点上（用户可指定每个ApplicationMaster的尝试次数，默认是1次）执行。
    • ApplicationMasterLauncher：与NodeManager通信，要求它为某个应用程序启动ApplicationMaster。
    • ApplicationMasterService：处理来自ApplicationMaster的请求，主要包括两种请求：注册和心跳，其中，注册是ApplicationMaster启动时发生的行为，包括请求包中包含所在节点，RPC端口号和tracking URL等信息，而心跳是周期性 行为，包含请求资源的类型描述、待释放的Container列表等，而AMS则为之返回新分配的Container、失败的Container等信息。
  • TBD...

Spark on YARN

• Spark on YARN模式的优点：与其他计算框架共享集群资源（eg：Spark框架与MapReduce框架同时运行，如果不用Yarn进行资源分配，MapReduce分到的内存资源会很少，效率低下）；资源按需分配，进而提高集群资源利用率等。
• 

• Yarn中的App Master可以理解为Spark中Standalone模式中的driver。

  Container中运行着Executor,在Executor中以多线程并行的方式运行Task。工作流程大体与MRv2相同。

Usage

• official doc.
• spark on yarn包含两种模式：
  • cluster mode：在Application master内运行spark driver，也就是在任务提交之后client就go away 了。
  • client：在client内运行driver，那么application master就只是从yarn申请资源。
• 运行实例
  

  ./bin/spark-submit --class org.apache.spark.examples.SparkPi 
      --master yarn 
      --deploy-mode cluster 
      --driver-memory 4g 
      --executor-memory 2g 
      --executor-cores 1 
      --queue thequeue 
      lib/spark-examples*.jar 
      10
  

  上述例子会 start a yarn client program which starts the default Application Master. 该client会周期地从Application Master拉取状态更新信息显示到console，并在程序结束运行的时候立即退出。

• 为了使spark runtime jars对yarn端可用，需要指定 spark.yarn.archive or spark.yarn.jars。如果两者都未指定，则spark会在$SPARK_HOME/jars 下create a zip file，然后upload it to the distributed cache.
• For debug: yarn logs -applicationId <app ID>  注意此功能首先要enable日志聚合。 同时可以配置log4j(从spark默认层面 or app层面)。

FYI

• YARN-dong的博客