MapReduce分布式并行计算框架是一种可用于数据处理的编程模型，可运行由个中语言编写的MapReduce程序：java、Ruby、Python、R、C++等语言。它用于处理超大规模数据的计算，同时具有可并行计算的特性，因此可以将大规模的数据分析任务交给任何一个拥有足够多机器的集群。并采用函数式编程的思想，在各函数之间串行计算（Map执行完毕，才会开始执行Reduce任务）。
简单来说Map将键值对形式的数据重新组合成新的键值对，而reduce函数用来对键值对列表进行汇总。使用的是分而治之的西乡，数据本地化是Mapreduce的核心特征。Mapreduce处理的数据一般位于底层分布式文件系统中，该系统往往将用户的文件切分为若干个block存储到不同的节点上，默认情况下，Mapreduce的每个Task任务处理一个block块。
Map映射和分发、Shuffle分组合并排序、Reduce汇聚和聚合
Mapper负责分，及把复杂的任务分解为若干个简单的任务来处理。简单的任务包含三层定义：
- 数据或计算的规模相对原任务要大大缩小
- 就近原则，及task任务会分配到存放着数据的节点上进行计算（移动计算而不移动数据）
- 这些小任务可以并行计算，彼此之间几乎没有依赖关系
Reducer负责对Map阶段的结果进行汇总。至于需要多少个Reducer，用户可以根据具体问题，通过在mapreduce-site.xml配置文件中对mapred.reduce.tasks的值进行设定（默认为1）。
MapReduce主要阶段：Input、Split、Map、Shuffle、Reduce、Final reduce
MapReduce主要组件：
MapReduce1.0版本：Client、JobTracker、TaskTracker、Task
MapReduce2.0版本：Client、ResourceManager、NodeManager、ApplicationMaster、Container
MapReduce特点：易于编程、良好的扩展性、高容错性
- MapReduce组成：Map阶段并行处理输入数据，Reduce阶段对Map结果进行汇报。
用户只需编写map()和reduce()两个函数，即可完成简单的分布式程序设计 - Shuffle连接Map和Reduce两个阶段：MapTask将数据写到本地磁盘，ReduceTask从每个MapTask上读取一份数据
- 适合离线批处理：MapReduce适合PB级以上海量数据的离线处理。具有很好的容错性和扩展性，适合简单的批处理任务
MapReduce 缺陷
- Map Task输出的数据量（即磁盘IO）大。Map Task将输出的数据写到本地磁盘，输出的数据量越多写入磁盘的数据量就越大，则开销越大，速度就越慢。
- Reduce-Map网络传输的数据量（网络IO）大，浪费了大量的网络资源。
- 容易造成负载不均衡问题。
MapReduce不擅长：
- 实时计算:像MySQL一样，在毫秒级或者秒级内返回结果
- 流式计算:MapReduce的输入数据集是静态的，不能动态变化。自身的设计特点决定了数据源必须是静态的
- DAG计算：多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出
MapReduce1.0
hadoop1.0版本在最顶层包含4个独立的实体：
- Client：提交MapReduce作业的客户端
- JobTracker：协调作业的运行（java应用程序）
是整个MapReduce计算框架中的主服务，相当于集群的管理者，负责整个集群的作业控制和资源管理。
1）作业控制模块：作业生命周期管理，调度作业任务，跟踪进度，为任务提供容错，为任务调度提供决策依据
2）资源管理模块：负责资源管理，跟踪资源消耗和可用性。通过一定的策略，将各节点上的计算资源分配给集群中的任务。 - TaskTracker：加载或关闭任务，定时报告任务状态（java应用程序），运行于各个节点上的服务，负责任务的执行和汇报心跳。
1) 任务执行:从JobTracker端接收并执行各种命令，如:启动任务、提交任务、杀死任务、杀死作业、重新初始化等
2) 汇报心跳:周期性地将所在节点上的各种信息，通过心跳机制汇报给JobTracker。包括节点健康信息、资源使用情况、任务执行进度、任务运行状态等. - 分布式文件系统：HDFS用来在其他实体之间共享作业文件
MapReduce1.0缺点
- 可扩展性差：
JobTracker同时兼备了资源管理和作业控制两个功能，这是整个系统的最大瓶颈，严重制约了集群的扩展性。它在内存中保存用户作业的信息：官方的说法是当他需要管理的节点数超过4000的时候，1.0版本就会导致“表现出一定的不可预测性”。 - 可用性低：
从调度上看，JobTracker的压力过大，容易引发单节点故障，还会因为主控节点压力过大导致性能下降。无论是调度分配，还是监控，还是重启任务，维护计数器总数都全部依赖这个主控节点，造成了过多的资源消耗，当MapReduce job非常多的时候，会造成很大的内存开销
特别用户如果提交了不同类型的分析任务的，比如A用户提交的是一个快速查询的任务，B用户提交的是一个多次迭代长事务的任务。在这种不同类型的任务之间确定是否有计算节点资源空闲，就是一个很头痛的事情。因为迭代的任务会间歇性的调用资源…… - 可靠性差:
JobTracker失效会丢失集群中所有的运行作业，用户需手动重新提交和恢复工作流 - 资源利用率低：
资源无法在多个任务间共享或合理分配，导致无法有效利用各种资源。
以map/reduce task的数目作为资源的表示过于简单。没有考虑到cpu或内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM。且把资源强制划分为map task slot和reduce task slot。如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费。slot介绍： - 无法支持多种计算框架：
Hadoop1.0只支持MapReduce这种离线批处理计算框架，而无法支持内存计算，流式计算和迭代式计算等框架
正是由于Hadoop 1.0存在以上这些弊端，所以Hadoop 2.0推出了资源管理器YARN，有效解决了上述问题。
Hadoop2.0 yarn的引入
对于节点数超过4000的大型集群，mapreduce1.0开始面临着扩展性的瓶颈。1.0版本中JobTracker负责作业调度和任务监视，追踪任务、重启失败或过慢的任务和进行任务等级划分等工作。
- YARN将JobTracker的职能划分多个独立的实体
资源管理器ResourceManager:负责整个集群资源管理，协调与分配
应用管理器ApplicationMaster：管理集群上运行任务的生命周期（每个作业都有一个专用的应用管理器）
这样一来，单点瓶颈的问题就算得到了解决，而且也提高了集群的扩展性。
基本思路是应用服务器与资源管理器协调集群的计算资源（容器containers）：
容器：对应MapReduce1中的任务槽，每个容器都有特定的内存上限。是将资源隔离出来的一种框架，每一个任务对应着一个container，且只能在该Container上运行。
进程：在容器上运行的特定应用程序 - YARN比MapReduce更具有一般性
YARN中的应用主体是一个用户可自定制的部分，因此用户可针对编程模型编写自己的应用主体程序。使得YARN不再像mapreduce 1.x那么死板，不同的YARN应用可以在同一个集群上共存。在hadoop2.x中，实际上MapReduce只是YARN应用的一种形式
Mapreduce2.0
hadoop2.0在最顶层包含5个独立的实体：
- 客户端：提交MapReduce作业
- 资源管理器ResourceManager：
是YARN资源控制框架的中心模块，负责集群上所有资源的统一管理和分配。接收来自NodeManager的汇报，建立ApplicationMaster并派送资源给ApplicationMaster - 节点管理器NodeManager：
是ResourceManager在每个节点上的代理，负责管理容器（container）和监控本节点的资源使用情况（CPU，内存，磁盘和网络），并向ResourceManager提供这些资源使用报告（心跳返回）
资源容器container：
Container是YARN中资源的抽象，它封装了某个节点上一定量的资源（CPU和内存两类资源）。由ResourceManager分配并由NodeManager进行监控和管理，确保应用程序使用的资源不会超过分配给他的资源，YARN中所有的应用都是在container上运行的。ApplicationMaster也在container上运行。 - 应用管理器ApplicationMaster：
负责协调运行MapReduce作业的任务，它和MapReduce任务均在容器container中运行。每个作业都有一个专用的ApplicationMaster，来负责作业的启动、运行和状况监测等 - 分布式文件系统：HDFS用来在其他实体之间共享作业文件
