MapReduce

MapReduce

参考：https://www.cnblogs.com/wcwen...
http://zheming.wang/blog/2015...
https://www.ibm.com/developer...
http://www.cnblogs.com/yurunm...

本文结构：

1. MapReduce模型说明
2. MapReduce1与MapReduce2对比
3. Yarn架构
4. Yarn运行流程

MapReduce模型说明

MapReduce模型基于“映射”与“归约”的思想，把一堆杂乱无章的数据按照某种特征归纳起来，然后处理并得到最后的结果。Map面对的是杂乱无章的互不相关的数据，它解析每个数据，从中提取出key和value，也就是提取了数据的特征。经过MapReduce的Shuffle阶段之后，在Reduce阶段看到的都是已经归纳好的数据了，在此基础上我们可以做进一步的处理以便得到结果。在hadoop的不同版本中有MapReduce1与MapReduce2(Yarn),这两种都是基于MapReduce模型构建的分布式计算框架。MapReduce编程思想，用于解决一些大问题可以被分解为许多子问题的场景，且这些子问题相对独立，将这些子问题并行处理完后，大问题也就被解决。

MapReduce过程

参考：https://blog.csdn.net/u010697...

Spill过程

MapReduce Shuffle可优化方向

• 压缩：对数据进行压缩，减少写读数据量；
• 减少不必要的排序：并不是所有类型的Reduce需要的数据都是需要排序的，排序这个nb的过程如果不需要最好还是不要的好；
• 内存化：Shuffle的数据不放在磁盘而是尽量放在内存中，除非逼不得已往磁盘上放；当然了如果有性能和内存相当的第三方存储系统，那放在第三方存储系统上也是很好的；这个是个大招；
• 网络框架：netty的性能据说要占优了；
• 本节点上的数据不走网络框架：对于本节点上的Map输出，Reduce直接去读吧，不需要绕道网络框架。

MapReduce1与MapReduce2对比

hadoop1.x版本中的MapReduce，主要由jobTracker与TaskTracker来完成MapReduce任务，jobTracker主要进行集群资源监控与任务调度工作，taskTracker分布在每个节点上执行由jobTracker指派的任务与监控本机资源，这种架构在mapreduce任务非常多时会出现如下问题：

1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
2. JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3. 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
4. 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
5. 源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
6. 从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。

当hadoop2.x版本重新设计mapreduce框架时，mapreduce2(Yarn)的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。

Yarn架构

YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件构成,总体上仍然是master/slave结构，在整个资源管理框架中，resourcemanager为master，nodemanager是slave。Resourcemanager负责对各个nademanger上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。

ResourceManager

RM是一个全局的资源管理器，集群中真正工作的只有一个，通过active与standby的namenode来进行HA,负责整个系统的资源管理和分配，包括处理客户端请求、启动/监控APP master、监控nodemanager、资源的分配与调度。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。

1. 调度器：根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。
2. 应用程序管理器：负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

ApplicationMaster

管理YARN内运行的应用程序的每个实例,经过ResourceManager分配资源后，运行于某一个Slave节点的Container中，具体做事情的Task，同样也运行与某一个Slave节点的Container中,AM主要功能为：

1. 数据切分
2. 为应用程序申请资源并进一步分配给内部任务
3. 任务监控与容错
4. 负责协调来自resourcemanager的资源，并通过nodemanager监视容易的执行和资源使用情况。

NodeManager（NM）

Nodemanager整个集群有多个，负责每个节点上的资源和使用。主要功能为：

1. 单个节点上的资源管理和任务
2. 处理来自于resourcemanager的命令
3. 处理来自域app master的命令
4. 管理着抽象容器，这些抽象容器代表着一些特定程序使用针对每个节点的资源。
5. 定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态（cpu和内存等资源）

Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。目前为止，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离。主要功能有：

1. 对task环境的抽象
2. 描述一系列信息
3. 任务运行资源的集合（cpu、内存、io等）
4. 任务运行环境

Yarn的运行流程

1. Client请求Resource Manager运行一个Application Master实例（step 1）；
2. Resource Manager选择一个Node Manager，启动一个Container并运行Application Master实例（step 2a、step 2b）；
3. Application Master根据实际需要向Resource Manager请求更多的Container资源（step 3）；
4. Application Master通过获取到的Container资源执行分布式计算（step 4a、step 4b）。