新生事物的成长往往是螺旋上升的，Hadoop 也是如此。Hadoop 1.0 是指 MapReduce + HDFS，其中 MapReduce 是一个离线处理框架，由编程模型（新旧API）、运行时环境（JobTracker 和 TaskTracker）和数据处理引擎（MapTask和ReduceTask）三部分组成。早期的 MapReduce 非常臃肿，有着很明显的缺点，JobTracker 有单点故障问题、框架设计只能执行 MapReduce 任务，不能跑 Storm，Flink 等计算框架的任务。

MapReduce 1.0的工作机制中，角色主要包括客户端，Jobtracker，Tasktracker。Jobtracker 主要是协调作业的运行，而 Tasktracker 是负责运行作业划分之后的任务。网上关于 MR 1.0 的内容很多，这里就不再过多赘述，流程图如下：

到了 MapReduce 2.0，核心思想则是将 MR 1.0 中 JobTracker 的资源管理和任务调度两个功能分开，分别由 ResourceManager 和 ApplicationMaster 进程实现。

MR 2.0 的工作流程主要分为以下6个执行过程（请将图片和文字对照起来看）：

如果想要将一个新的应用程序运行在 YARN 之上，通常需要编写两个组件：客户端和  ApplicationMaster。

· 客户端编写需要注意：客户端通常只需与 ResourceManager 交互，期间涉及到多个数据结构和一个 RPC 协议。

· ApplicationMaster 编写需要注意：ApplicationMaster 需要与 ResoureManager 和 NodeManager 交互，以申请资源和启动 Container，期间涉及到多个数据结构和两个 RPC 协议。

洋洋洒洒，回过头来，现在来给大家介绍一下 Taier 和 Yarn 之间的关系。

以 MR on Yarn 任务为例，其实现原理主要有2个关键步骤：

· 组装任务运行时的相关信息生成 pluginInfo，信息包含任务相关配置、YARN 配置、HDFS 配置和公共配置。

· 根据 pluginInfo 实例化相应的任务提交客户端，客户端负责向 YARN 提交任务，实现了 Taier 与计算集群的解耦、保证节点无侵入。

下图是目前已经在 Taier 上运行的 Flink 任务的一些参数，包括 groupName、jobID 等：

以 MR on Yarn 任务为例，其执行原理可以分为以下3个阶段：

● 准备阶段

· 对普通的 Hadoop MR 任务进行改造，修改 MR 代码的 Main 方法

· 编译修改后的 Hadoop MR 任务，并通过 Taier 的资源上传功能将 Jar 进行上传，目标选择 HDFS

· 配置 Haddoop MR 任务的任务参数

● 运行阶段

· Taier 的 worker-plugin 主要负责任务提交相关工作，其中 hadoop 插件会负责 MR 任务的相关处理

· 实例化 HadoopClient，并下载准备阶段上传的 MR 任务对应的 Jar（注意这里是一个任务的生命周期，为了保障任务的无状态，所以每次运行都会重新下载一次）

· 通过 MapReduceTemplate ，加载 Jar 并构建 MR 任务的类加载器

· 通过类加载器实获取 Class 类对象，并调用类对象的 Main 方法，传入 Configuration、args 等参数

· 返回 JobId

● 运维阶段

· 处理 JobId 并转化为 ApplicationId

· 实例化 YarnClient，获取 MR on Yarn 的相关信息，包括运行状态、日志、停止 Application

Hadoop MR 的任务在 Taier 中的实现是基于 Hadoop 的插件，在里面实现了相关的类，其中比较主要的包括：

· HadoopClient： 实现任务提交运行的相关接口（init、judgeSlots、processSubmitJobWithType、beforeSubmitFunc、afterSubmitFunc、getJobStatus、getJobLog、cancelJob）

· MapReduceTemplate：封装 MR 任务及其重要参数、方法，实例化 PackagedProgram

· PackagedProgram：MR 任务提交前的处理实现