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）。