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通信，以申请资源和启动任务。

YARN架构

• Client：提交分布式程序的客户端，上传资源文件和JAR包到HDFS集群；
• ResourceManager：负责将集群的资源分配给各个应用使用；
• Container：资源分配和调度的基本单元，其中封装了的资源如内存、CPU、磁盘、网络带宽等。每个任务会被分配一个Container，并在该Container中执行且只能使用其封装的资源。
• NodeManager：计算节点，负责启动Container，同时通过心跳不断地与RM通信，描述该Worker节点的资源（ CPU,内存，硬盘和网络带宽等）状况。
• AppMaster：对应client提交的一个应用。客户端每提交一个应用,RM会在Worker节点上给它分配一个全局唯一的App master，App master可以在任何一台Worker节点上启动，负责管理作业的整个生命周期，包括通知NM创建Container，管理Container等。

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相同。

FYI

• YARN-dong的博客