MapReduce介绍

MapReduce和YARN技术原理

1.MapReduce概述
1.1.MapReduce基于Google发布的MapReduce论文设计开发，用于大规模数据集（大于1TB）的并行计算，具有如下特点：
1.2.易于编程：程序员仅需描述做什么，具体怎么做交由系统的执行框架处理。
1.3.良好的扩展性：可通过添加节点以扩展集群能力。
1.4.高容错性：通过计算迁移或数据迁移等策略提高集群的可用性与容错性。
1.5.当某些节点发生故障时，可以通过计算迁移或数据迁移在其他节点继续执行任务，保证任务执行成功。
1.6.MapReduce是一个基于集群的高性能并行计算平台（Cluster Infrastructure）。
1.7.MapReduce是一个并行计算与运行软件框架（Software Framework）。
1.8.MapReduce是一个并行程序设计模型与方法（Programming Model & Methodology）。
2.YARN概述
2.1.Apache Hadoop YARN (Yet Another Resource Negotiator，另一种资源协调者) 是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
3.MapReduce过程详解(1)
3.1.YARN是Hadoop2.0中的资源管理系统，它是一个通用的资源管理模块，可为各类应用程序提供资源管理和调度功能。
4.MapReduce过程详解(2)
4.1.在启动MapReduce之前，确保待处理的文件放在HDFS上面。
4.2.MapReduce应用将请求提交给RM，由RM创建对应的Job，一个应用对应一个Job（jobID形如，job_201431281420_0001）。
4.3.Job提交前，先将待处理的文件进行分片（Split）。MR框架默认将一个块（Block）作为一个分片。客户端应用可以重定义块与分片的映射关系
4.4.Job提交给RM，RM根据NM的负载在NM集群中挑选合适的节点调度AM，AM负责Job任务的初始化并向RM申请资源，由RM调度合适的NM启动Container, Container来执行Task。
4.5.Map的输出放入一个环形内存缓冲区，当缓冲区数据溢出时，需将缓冲区中的数据写入到本地磁盘，写入本地磁盘之前通常需要做如下处理：
4.6.1.分区（Partition）—默认采用Hash算法进行分区，MR框架根据Reduce Task个数来确定分区个数。具备相同Key值的记录最终被送到相同的Reduce Task来处理。
4.7.2.排序（Sort）—将Map输出的记录排序，例如将(’Hi’,’1’),(‘Hello’,’1’)重新排序为(‘Hello’,’1’), (’Hi’,’1’)。
4.8.3.组合(Combine)—这个动作MR框架默认是可选的。例如将(’Hi’,’1’), (’Hi’,’1’),(‘Hello’,’1’), (Hello’,’1’)进行合并操作为(’Hi’,’2’), (‘Hello’,’2’)。
4.9.4.合并(Spill)—Map Task在处理后会产生很多的溢出文件(spill file)，这时需将多个溢出文件进行合并处理，生成一个经过分区和排序的Spill File（MOF:MapOutFile）。为减少写入磁盘的数据量，MR支持对MOF进行压缩后再写入。
4.10.通常在Map Task任务完成MOF输出进度到3%时启动Reduce，从各个Map Task获取MOF文件。前面提到Reduce Task个数由客户端决定，Reduce Task个数决定MOF文件分区数。因此Map Task输出的MOF文件都能找到相对应的Redcue Task来处理
4.11.前面提到的MOF文件是经过排序处理的。当Reduce Task接收的数据量不大时，则直接存放在内存缓冲区中，随着缓冲区文件的增多，MR后台线程将它们合并成一个更大的有序文件，这个动作是Reduce阶段的Merge操作，过程中会产生许多中间文件，最后一次合并的结果直接输出到用户自定义的Reduce函数。
4.12.分片的必要性：MR框架将一个分片和一个Map Tast对应，即一个Map Task只负责处理一个数据分片。数据分片的数量确定了为这个Job创建Map Task的个数。
4.13.Application Master(AM)负责一个Application生命周期内的所有工作。包括：与RM调度器协商以获取资源；将得到的资源进一步分配给内部任务（资源的二次分配）；与NM通信以启动/停止任务；监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
4.14.ResourceManager(RM) 负责集群中所有资源的统一管理和分配。它接收来自各个节点（NodeManager）的资源汇报信息，并根据收集的资源按照一定的策略分配给各个应用程序。
4.15.NodeManager（NM）是每个节点上的代理，它管理Hadoop集群中单个计算节点，包括与ResourceManger保持通信，监督Container的生命周期管理，监控每个Container的资源使用（内存、CPU等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）。
4.16.MR组件在FI中只有jobhistoryserver实例，它只是存储任务的执行记录，执行列表，没有它，也可以运行任务。但是无法查询任务的详细信息。
4.17.Reduce阶段的三个过程：
4.18.Copy：Reduce Task从各个Map Task拷贝MOF文件。
4.19.Sort：通常又叫Merge，将多个MOF文件进行合并再排序。
4.20.Reduce：用户自定义的Reduce逻辑。
5.Shuffle机制
5.1.Shuffle的定义：Map阶段和Reduce阶段之间传递中间数据的过程，包括Reduce Task从各个Map Task获取MOF文件的过程，以及对MOF的排序与合并处理。
6.典型程序WordCount举例
6.1.假设要分析一个大文件A里每个英文单词出现的个数，利用MapReduce框架能快速实现这一统计分析。分析过程如PPT所展示的内容。
6.2.第一步：待处理的大文件A已经存放在HDFS上，大文件A被切分的数据块A.1、A.2、A.3分别存放在Data Node #1、#2、#3上。
6.3.第二步：WordCount分析处理程序实现了用户自定义的Map函数和Reduce函数。WordCount将分析应用提交给RM，RM根据请求创建对应的Job，并根据文件块个数按文件块分片，创建3个 MapTask 和 3个Reduce Task，这些Task运行在Container中。
6.4.第三步：Map Task 1、2、3的输出是一个经分区与排序（假设没做Combine）的MOF文件，记录形如表所示。
6.5.第四步：Reduce Task从 Map Task获取MOF文件，经过合并、排序，最后根据用户自定义的Reduce逻辑，输出如表所示的统计结果。
7.YARN的组件架构
7.1.在图中有两个客户端向YARN提交任务，蓝色表示一个任务流程，棕色表示另一个任务流程。
7.2.首先client提交任务，ResourceManager接收到任务，然后启动并监控起来的第一个Container,也就是App Mstr。
7.3.App Mstr通知nodemanager管理资源并启动其他container。
7.4.任务最终是运行在Container当中。
7.5.ResourceManager 负责集群资源统一管理和计算框架管理，主要包括调度与应用程序管理。
7.6.调度器：根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。
7.7.应用程序管理器：负责管理整个系统中的所有应用程序，包括应用程序提交，与调度器协商资源，启动并监控AppMaster运行状态。
7.8.NodeManager节点资源管理监控和容器管理，RM是系统中将资源分配给各个应用的最终决策者。
7.9.AppMaster各种计算框架的实现（例如MRAppMaster）向ResourceManager申请资源，通知NodeManager管理相应的资源。
7.10.Container YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU等。
8.MapReduce On YARN任务调度流程
8.1.步骤1：用户向YARN 中提交应用程序， 其中包括ApplicationMaster 程序、启动ApplicationMaster 的命令、用户程序等。
8.2.步骤2：ResourceManager 为该应用程序分配第一个Container， 并与对应的NodeManager 通信，要求它在这个Container 中启动应用程序的ApplicationMaster 。
8.3.步骤3：ApplicationMaster 首先向ResourceManager 注册， 这样用户可以直接通过ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
8.4.步骤4：ApplicationMaster 采用轮询的方式通过RPC 协议向ResourceManager 申请和领取资源。
8.5.步骤5：一旦ApplicationMaster 申请到资源后，便与对应的NodeManager 通信，要求它启动任务。
8.6.步骤6：NodeManager 为任务设置好运行环境（包括环境变量、JAR 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
8.7.步骤7：各个任务通过某个RPC 协议向ApplicationMaster 汇报自己的状态和进度，以让ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通
8.8.过RPC 向ApplicationMaster 查询应用程序的当前运行状态。
8.9.步骤8　应用程序运行完成后，ApplicationMaster 向ResourceManager 注销并关闭自己。
9.YARN HA方案
9.1.YARN中的ResourceManager负责整个集群的资源管理和任务调度，YARN高可用性方案通过引入冗余的ResourceManager节点的方式，解决了ResourceManager 单点故障问题。
9.2.ResourceManager的高可用性方案是通过设置一组Active/Standby的ResourceManager节点来实现的。与HDFS的高可用性方案类似，任何时间点上都只能有一个ResourceManager处于Active状态。当Active状态的ResourceManager发生故障时，可通过自动或手动的方式触发故障转移，进行Active/Standby状态切换。
9.3.在未开启自动故障转移时，YARN集群启动后，管理员需要在命令行中使用YARN rmadmin命令手动将其中一个ResourceManager切换为Active状态。当需要执行计划性维护或故障发生时，则需要先手动将Active状态的ResourceManager切换为Standby状态，再将另一个ResourceManager切换为Active状态。
9.4.开启自动故障转移后，ResourceManager会通过内置的基于ZooKeeper实现的ActiveStandbyElector来决定哪一个ResouceManager应该成为Active节点。当Active状态的ResourceManager发生故障时，另一个ResourceManager将自动被选举为Active状态以接替故障节点。
9.5.当集群的ResourceManager以HA方式部署时，客户端使用的“YARN-site.xml”需要配置所有ResourceManager地址。客户端（包括ApplicationMaster和NodeManager）会以轮询的方式寻找Active状态的ResourceManager。如果当前Active状态的ResourceManager无法连接，那么会继续使用轮询的方式找到新的ResourceManager。
9.6.YARN中的ResourceManager负责整个集群的资源管理和任务调度，YARN高可用性方案通过引入冗余的ResourceManager节点的方式，解决了ResourceManager 单点故障问题。
9.8.备RM升主后，能够恢复故障发生时上层应用运行的状态。当启用ResourceManager Restart时，重启后的ResourceManager就可以通过加载之前Active的ResourceManager的状态信息，并通过接收所有NodeManager上container的状态信息重构运行状态继续执行。这样应用程序通过定期执行检查点操作保存当前状态信息，就可以避免工作内容的丢失。状态信息需要让Active/Standby的ResourceManager都能访问。当前系统提供了三种共享状态信息的方法：通过文件系统共享（FileSystemRMStateStore）、通过LevelDB数据库共享（LeveldbRMStateStore）或通过ZooKeeper共享（ZKRMStateStore）。这三种方式中只有ZooKeeper共享支持Fencing机制。Hadoop默认使用ZooKeeper共享。
9.9.在YARN中，ApplicationMaster(AM)与其他Container类似也运行在NodeManager上（忽略未管理的AM）。AM可能会由于多种原因崩溃、退出或关闭。如果AM停止运行，ResourceManager(RM)会关闭ApplicationAttempt中管理的所有Container，包括当前任务在NodeManager(NM)上正在运行的所有Container。RM会在另一计算节点上启动新的ApplicationAttempt。
9.10.不同类型的应用希望以多种方式处理AM重新启动的事件。MapReduce类应用目标是不丢失任务状态，但也能允许一部分的状态损失。但是对于长周期的服务而言，用户并不希望仅仅由于AM的故障而导致整个服务停止运行。
9.11.YARN支持在新的ApplicationAttempt启动时，保留之前Container的状态，因此运行中的作业可以继续无故障的运行。
10.YARN APPMaster容错机制
10.1.在YARN中，ApplicationMaster(AM)与其他Container类似也运行在NodeManager上（忽略未管理的AM）。AM可能会由于多种原因崩溃、退出或关闭。如果AM停止运行，ResourceManager(RM)会关闭ApplicationAttempt中管理的所有Container，包括当前任务在NodeManager(NM)上正在运行的所有Container。RM会在另一计算节点上启动新的ApplicationAttempt。
10.2.不同类型的应用希望以多种方式处理AM重新启动的事件。MapReduce类应用目标是不丢失任务状态，但也能允许一部分的状态损失。但是对于长周期的服务而言，用户并不希望仅仅由于AM的故障而导致整个服务停止运行。
10.3.YARN支持在新的ApplicationAttempt启动时，保留之前Container的状态，因此运行中的作业可以继续无故障的运行。
11.资源管理
11.1.当前YARN支持内存和CPU两种资源类型的管理和分配。
11.2.每个NodeManager可分配的内存和CPU的数量可以通过配置选项设置（可在YARN服务配置页面配置）。
11.3.Yarn.nodemanager.resource.memory-mb
11.4.Yarn.nodemanager.vmem-pmem-ratio
11.5.Yarn.nodemanager.resource.cpu-vcore
11.6.Yarn.nodemanager.resource.memory-mb表示用于当前NodeManager上可以分配给容器的物理内存的大小，单位：MB。必须小于NodeManager服务器上的实际内存大小。
11.7.Yarn.nodemanager.vmem-pmem-ratio表示为容器设置内存限制时虚拟内存跟物理内存的比值。容器分配值使用物理内存表示的，虚拟内存使用率超过分配值的比例不允许大于当前这个比例。
11.8.Yarn.nodemanager.resource.cpu-vcore表示可分配给container的CPU核数。建议配置为CPU核数的1.5-2倍。
12.资源分配模型
12.1.调度器维护一群队列的信息。用户可以向一个或者多个队列提交应用。
12.2.每次NM心跳的时候，调度器根据一定的规则选择一个队列，再在队列上选择一个应用，尝试在这个应用上分配资源。
12.3.调度器会优先匹配本地资源的申请请求，其次是同机架的，最后是任意机器的。
12.4.当任务提交上来，首先会声明提交到哪个队列上，调度器会分配队列，如果没有指定则任务运行在默认队列。
12.5.队列是封装了集群资源容量的资源集合，占用集群的百分比例资源。
12.6.队列分为父队列，子队列，任务最终是运行在子队列上的。父队列可以有多个子队列。
12.7.调度器选择队列上的应用，然后根据一些算法给应用分配资源。
13.容量调度器的介绍
13.1.容量调度器使得Hadoop应用能够共享的、多用户的、操作简便的运行在集群上，同时最大化集群的吞吐量和利用率。
13.2.容量调度器以队列为单位划分资源，每个队列都有资源使用的下限和上限。每个用户可以设定资源使用上限。管理员可以约束单个队列、用户或作业的资源使用。支持作业优先级，但不支持资源抢占。
14.容量调度器的特点
14.1.容量保证：管理员可为每个队列设置资源最低保证和资源使用上限，所有提交到该队列的应用程序共享这些资源。
14.2.灵活性：如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，当该队列有新的应用程序提交，则其他队列释放的资源会归还给该队列。
14.3.支持优先级：队列支持任务优先级调度（默认是FIFO）。
14.4.多重租赁：支持多用户共享集群和多应用程序同时运行。为防止单个应用程序、用户或者队列独占集群资源，管理员可为之增加多重约束。
14.5.动态更新配置文件：管理员可根据需要动态修改配置参数，以实现在线集群管理。
15.容量调度器的任务选择
15.1. 调度时，首先按以下策略选择一个合适队列：
15.2.资源利用量最低的队列优先，比如同级的两个队列Q1和Q2，它们的容量均为30，而Q1已使用10，Q2已使用12，则会优先将资源分配给Q1。
15.3.最小队列层级优先，例如：QueueA与QueueB.childQueueB，则QueueA优先。
15.4.资源回收请求队列优先。
15.5. 然后按以下策略选择该队列中一个任务：
15.6.按照任务优先级和提交时间顺序选择，同时考虑用户资源量限制和内存限制。
16.队列资源限制 (1)
16.1.队列的创建是在多租户页面，当创建一个租户关联YARN服务时，会创建同名的队列。比如先创建QueueA,QueueB两个租户，即对应YARN两个队列。
17.队列资源限制 (2)
17.1.队列的资源容量（百分比），有default、QueueA、QueueB三个队列，每个队列都有一个[队列名].capacity配置：
17.2.Default队列容量为整个集群资源的20%。
17.3.QueueA队列容量为整个集群资源的10%。
17.4.QueueB队列容量为整个集群资源的10%，后台有一个影子队列root-default使队列之和达到100% 。
17.5.在集群的Manager页面点击“租户管理”》“动态资源计划”》“资源分布策略”可以看到下图页面，可配置各队列资源容量。
17.6.影子队列：是不对外呈现的一个队列。以XX-default为名字，目的是为了使同级的队列容量之和不够一百时，将剩余容量值赋予此队列（容量调度器要求同级队列容量和要为100）。
18.队列资源限制 (3)
18.1.共享空闲资源
18.2.由于存在资源共享，因此一个队列使用的资源可能超过其容量（例如QueueA.capacity），而最大资源使用量可通过参数限制。
18.3.如果某个队列任务较少，可将剩余资源共享给其他队列，例如QueueA的maximum-capacity配置为100，假设当前只有QueueA在运行任务，理论上QueueA可以占用整个集群100%的资源。
19.用户限制和任务限制
19.1.用户限制和任务限制的参数可通过“租户管理”>“动态资源计划”>“队列配置”进行配置。
20.用户限制
20.1.每个用户最低资源保障（百分比）：
20.2.任何时刻，一个队列中每个用户可使用的资源量均有一定的限制，当一个队列中同时运行多个用户的任务时，每个用户的可使用资源量在一个最小值与最大值之间浮动，其中，最大值取决于正在运行的任务数目，而最小值则由minimum-user-limit-percent决定。
20.3.例如，设置队列A的这个值为25，即Yarn.scheduler.capacity.root.QueueA.minimum-user-limit-percent=25，那么随着提任务的用户增加，队列资源的调整如下：
20.4.queue容量的倍数，用来设置一个user可以获取更多的资源。 Yarn.scheduler.capacity.root.QueueD.user-limit-factor=1。默认值为1，表示一个user获取的资源容量不能超过queue配置的capacity，无论集群有多少空闲资源，最多不超过maximum-capacity。
20.5.每个用户最多可使用的资源量（所在队列容量的倍数）：
21.任务限制
21.1.最大活跃任务数：
21.2.整个集群中允许的最大活跃任务数，包括运行或挂起状态的所有任务，当提交的任务申请数据达到限制以后，新提交的任务将会被拒绝。默认值10000。
21.3.每个队列最大任务数：
21.4.对于每个队列，可以提交的最大任务数，以QueueA为例，可以在队列配置页面配置，默认是1000，即此队列允许最多1000个活跃任务。
21.5.每个用户可以提交的最大任务数：
21.6.这个数值依赖每个队列最大任务数。根据上面的数据， QueueA最多可以提交1000个任务，那么对于每个用户而言，可以向QueueA提交的最大任务数为1000* 用户最低资源保障率（假设25%）* 用户可使用队列资源的倍数(假设1)
21.7.用户最低资源保障率：Yarn.scheduler.capacity.root.QueueA.minimum-user-limit-percent。
21.8.用户可使用队列资源的倍数：Yarn.scheduler.capacity.root.QueueA.user-limit-factor。
22.查看队列信息
22.1.队列的信息可以通过YARN webUI进行查看，进入方法是“服务管理”>“YARN”>“ResouceManager（主）”>“Scheduler”。
23.增强特性 - YARN动态内存管理
23.1.动态内存管理可用来优化NodeManager中Containers的内存利用率。任务在运行过程中可能产生多个Container。
23.2.当前，当单个节点上的Container超过Container运行内存大小时，即使节点总的配置内存利用还很低，NodeManager也会终止这些Containers。这样就会经常使用户作业失败。
23.3.动态内存管理特性在当前是一个改进，只有当NodeManager中的所有Containers的总内存使用超过了已确定的阈值，NM总内存阈值的计算方法是Yarn.nodemanager.resource.memory-mb10241024*Yarn.nodemanager.dynamic.memory.usage.threshold，单位GB，那么那些内存使用过多的Containers才会被终止。
23.4.举例，假如某些Containers的物理内存利用率超过了配置的内存阈值，但所有Containers的总内存利用率并没有超过设置的NodeManager内存阈值，那么那些内存使用过多的Containers仍可以继续运行
24.增强特性 - YARN基于标签调度
24.1.在没有标签调度之前，任务提交到哪个节点上是无法控制的，会根据一些算法及条件，集群随机分配到某些节点上。而标签调度可以指定任务提交到哪些节点上。
24.2.比如之前需要消耗高内存的应用提交上来，由于运行在那些节点不可控，任务可能运行在普通性能的机器上。
24.3.Label based scheduling是一种调度策略。该策略的基本思想是：用户可以为每个nodemanager标注一个标签，比如high-memory，high-IO等进行分类，以表明该nodemanager的特性；同时，用户可以为调度器中每个队列标注一个标签，即队列与标签绑定，这样，提交到某个队列中的作业，只会使用标注有对应标签的节点上的资源，即任务实际运行在打有对应标签的节点上。
24.4.将耗内存消耗型的任务提交到绑定了high-memry的标签的队列上，那么任务就可以运行在高内存机器上。