FusionInsight大数据开发---MapReduce与YARN应用开发

MapReduce

1. MapReduce的基本定义及过程
2. 搭建开发环境
3. 代码实例及运行程序
4. MapReduce开发接口介绍

1. MapReduce的基本定义及过程

MapReduce是面向大数据并行处理的计算模型、框架和平台，其资源调度由Yarn完成，任务资源隐含了以下三层含义：

• 1）MapReduce是 一个基于集群的高性能并行计算平台（cluster Infrastructure）。
• 2）MapReduce是 一个并行计算与运行软件框架（SoftWare Framework）
• 3）MapReduce是 一个并行程序设计模型与方法（Programming Model & Methodology）

MapReduce特点：

• 易于编程
• 良好的扩展性
• 高容错性

MapReduce的过程：

1. 把输入的数据（Input） 拆分为多个键值对（key-value对）
2. 每一个键值对分别调用Map进行并行处理
3. 每一个Map会产生多个新的键值对
4. 对Map阶段产生的数据进行排序、组合
5. 以键值对的形式输出最终结果

2. 搭建开发环境

1. 确认Yarn组件和MapReduce组件已经安装。
2. 客户端安装Eclipse和JDK程序。
3. 客户端机器的时间与FusInsight集群时间要保持一致，时间差要小于5分钟。
4. 在Yarn服务页面下载MapReduce客户端程序到客户端机器中。

• 1.下载客户端
• 2.获取样例工程
• 3.生成样例工程
• 4.导入eclipse
• 5.编码

开发相关类的总结

1) InputFormat类

• 将输入的数据分割成split，并将split拆分为<key,value>作为map的输入。

2） Mapper类

• 实现map函数，根据输入的<key,value>对产生中间结果。

3）Combiner类

• 实现combiner函数，合并中间结果中具有相同key值的键值对。

4） Partitioner类
实现getPartitioner函数，在Shuffle过程按照key值将中间数据分成R份，每一份由一个Reduce负责

5） Reduce类

• 实现reduce函数，将中间结果合并，得到最终的结果。

6）OutputFormat类

• 该类负责输出最终的结果，MapReduce使用OutputFormat类将数据输出存入到文件中，每个Reduce将它的输出直接写到自己的文件中。

调式代码

• MapReduce开发调式采用的原理是Java的远程调式机制

YARN

一、YARN出现的背景

　　YARN作为一种协调机制，是在Hadoop 2.0版本才出现使用的。在1.0版本中，对数据的处理、资源的调度主要依赖于MapReduce算法。来看一下Hadoop 1.版本的应用处理机制：

1. 一个需要用到Data A和Data C的应用提交给M/R
2. M/R为应用创建一个Job，Job将应用分片后提交给Job Tracker
3. Job Tracker根据应用所需的数据找到相应的DN节点，在DN节点上分配相应的Task Tracker执行任务
4. Task Tracker在执行任务时实时与Job Tracker进行交互，汇报任务执行情况
5. Job Tracker接受各Task Tracker的计算结果

我们先理解一下Job Tracker和Task Tracker。应用在提交给Job Tracker时已经分好片，在Job Tracker接受到的仍是一个完整的应用。之后由Job Tracker将分片的应用下放到相应的DN节点，由Task Tracker具体执行，这个时候Task Tracker收到的时整个应用的一部分，可以成为任务。那么我们可以将Job Tracker理解为整个应用和整个DN集群的管理器，而Task Tracker则是分片任务的管理器。选择回顾整个处理机制，我们能发现两个突出的问题：

1. Job Tracker的地位很重要，但负载也太大了。除了初始的应用分片不需要它处理，剩下的一切都需要它”追踪“，包括任务的具体执行情况也要它操个心。对整个系统来说，这不是好事。
2. Job Tracker时按照所需数据来进行分配，那么资源（主要指内存）就很容易分配不均。打个比方：一个Job被分成6个子Job，每个子Job需要的资源（内存）是1GB。但所有子Job所需要的数据全部集中在一台DN节点上，该节点内存只有4GB，一次只能接受4给子Job。剩下的2个子Job正能等内存释放后再进入执行。而在等待工程中，其他的DN节点是处于空闲状态的。

这两个问题暴露了Hadoop 1.0版本的资源协调在处理大规模数据时会有些”力不从心“。而随着数据规模的快速扩大，Hadoop亟需一种更优化的资源协调解决方案，YARN就在这一背景下诞生。

二、YARN的重要角色及概念

1. ResourceManager（RM）

　　　　RM是整个集群的资源管理器，负责整个集群的资源调度和管理。同时也负责与客户端交互，处理客户端的应用请求等。它主要有２个组建构成：

• ①Resource　Scheduler：纯资源调度器，只负责为程序进程调度所需的资源
• ②Applications Manager(ASM)：与具体应用程序打交道，处理程序的请求，具体负责程序的分配

1. Node Manager（ＮＭ)：节点管理器，负责管理自己节点上的资源和使用，于RM交互，上报节点的状态，以便RM调用
2. Application Master(AM)：在DN节点上中，是每个子程序的管理者，负责管理由RM分发的任务，包括任务的资源申请和执行情况
3. Container：资源打包容器，AM向RM申请来的资源的集合，并利用这些资源负责具体执行任务。位于DN节点上。

三、YARN运行流程

　　还是要提一下，YARN作为资源的协调者，本身不提供应用程序和文件数据。应用程序由客户端发起，由Hadoop上层的算法转化成不同的任务，数据文件存储在HDFS上。所以说，YARN只是辅助任务去调用资源来计算这些数据，并不参与到计算中去。

1. 客户端向RM发送应用请求
2. RM根据NM的节点信息选择合适的DN节点
3. RM在选中的DN节点上创建并启动AM，将任务分发给AM
4. AM根据自己的任务情况向RM申请相应的资源
5. RM为AM分配相应的资源
6. AM得到资源后启动对应的资源容器（Container）执行任务并进行监控
7. Conrtainer将任务执行完毕报告给AM
8. AM将任务的执行结果上报给RM
9. RM向Client返回应用的执行结果

现在我们再回顾一下Hadoop 1.0版本的局限性：

• Job Tracker既要调度又要监控，负载过高

　　再YARN中，区别于1.0版本最主要的思想就是将调度和监控功能分离。RM主要负责资源的调度，具体任务监控则由AM来完成。RM只要在节点上启动AM并将任务发给AM就行，不用管任务具体是怎么执行的，当任务完成后由AM向RM报告一个结果就行了。且AM分布在各节点上，不占用RM本身资源，大大减少了RM的工作量，整个系统的稳定性就有了极大的提高。

• 任务按数据需求分配，资源分配不均，效率低下

　　AM在向RM申请资源时，不在局限于本节点的资源，而是由RM根据各节点信息选择合适的节点资源调配给AM使用。换句话说，”AM你有什么需求尽管提，只要我有一定给你（哦吼，霸道总裁既视感）“这个”我“指的就是整个集群了。

YARN的加入使得Hadoop 2.0系统有了一种高效、可靠的处理大规模数据的能力。但老样子，为保持整个Hadoop系统的高可靠性，YARM也需要一套高可靠性机制。

四、YARN的高可靠性

高可靠性，主要就是对整个运行环节中的任一环节的出错情况有一套快速恢复的预案。我们结合YARN的角色看一下每个环节的解决方案

　1、任务执行出错（Container）

• Container作为任务的具体执行者，由任务管理器AM所监控。当Container出错时会向AM发送报告，随后释放自己的资源。AM收到失败报告后会重新启动该任务，一般会选在不同节点

　2、任务管理器出错（AM）

• AM作为节点信息，会周期性的向RM发送心跳信息。当AM出错时，一般会尝试进行重启。重启失败后，RM会发现该AM不可用，则会在其他节点建立一个新的AM，用来接管原AM管理的Container

　３、节点管理器出错（NM）

• 节点管理器管理者整个节点的资源和信息，并与RM建立心跳联系。当NM出现问题，即表示该节点损坏，RM检测到之后，会将该节点从自己的节点池中移除，并将该节点上的进程加载到其他节点上运行

　４、资源管理器出错（RM）

• RM作为整个集群的资源管理器，是YARN最核心的部分，一旦宕机将会丢失一切任务和资源信息。为保障其高可靠性，采取了主备机制。整个集群中会运行多个RM，通过ZooKeeper进行主备选举。主RM运行中的相关信息会保存在ZooKeeper的一个存储区内，当主RM宕机或算坏后，ZooKeeper会立即选举出新的主RM。新的主RM会从ZooKeeper中获取进程的运行信息和节点的信息，来接替主RM的工作

五、总结

　　YARN作为Hadoop的资源协调者，是Hadoop处理大规模数据的保障。在以后学习Hadoop的上层算法中，基本都会涉及到YARN的资源协调。换句话说，YARN为大数据的高效算法提供了优秀的协调机制。