mapreduce角色：
Mapreduce 作业(我们称为job)是客户端需要执行的一个工作单元
它包括 输入数据及mapreduce程序及配置信息
Hadoop将这个作业分为map任务及reduce任务
有两类节点控制着作业执行过程，一个jobtracker和若干个tasktracker
- Jobtracker 通过调度tasktracker上运行的任务来协调所有运行在系统上的作业
- Tasktracker在运行任务时同时将运行进度报告发送给jobtracker
Jobtracker由此纪录每项业务作业任务的整体进度情况，如果其中一个失败，jobtracker可以在另一个tasktracker节点上重新调度该任务
解释：
一个项目经理和若干工程师
项目经理协调所有项目进度和分配任务
工程师接收任务并完成，同时定时发送周报
项目经理掌握项目整体进度，如果一个工程师接收了A任务确因为种种原因无法完成，会把这个项目分配给另外一名工程师
Mapreduce的分片机制
HADOOP 将mapreduce的输入数据划分成等长的小数据块，称为输入分片（input split）
HADOOP 为每个分片构建一个map任务，并由该任务来运行用户自定义的map函数
拥有许多分片，意味着处理每个分片所需的时间少于处理整个输入数据的时间。
因此如果我们并行处理每个碎片，那么整个处理过程将获得更好得负载均衡
如果分片被切的更细，负载均衡的会更高
另一方面，如果分片切得太小，那么管理分片的总时间和构建map任务的总时间将决定整个作业的执行时间。
针对大多数作业来说，一个合理的分片大小趋近于HDFS的一个块大小，默认是64M，（不过可以针对集群调整这个默认值或者针对新建的每个文件）
Map的本地数据优化
Hadoop在存储有输入数据（HDFS中的数据）的节点上运行map任务，可以获得最佳性能，这就是我们所说的“”数据本地优化“”，（data locality optimization），因此它无需使用宝贵的集群带宽资源
但是对于一个map任务的输入来说，存储有某个HDFS数据备份的三个节点可能正在运行其他map任务
此时作业调度需要在三个备份中的某个数据寻求同个机架中空闲的机器来运行该map任务。
仅仅在非常偶然的情况下（几率很小），会使用其他机架中的机器运行该map任务，这将导致机架与机架之间的网络传输
注意：上面我们说了三个可能性，就在如上这段话中，要自己整理并搞透彻
map最佳分片的大下应该与块大小相同
现在我们应该清楚为什么最佳分片的大下应该与块大小相同：如果分片跨越两个数据块，对于任何一个HDFS节点来说，基本不可能恰好同时存储了这两个数据块，因此分片中的部分数据需要通过网络传输到map任务节点，与使用本地数据运行整个map相比，这种方法效率太低
Map任务将其输出写入本地磁盘，而非hdfs
Map任务将其输出写入本地磁盘，而非hdfs。这是为什么？因为map的输出是中间结果：
该中间结果由reduce任务处理后才会产生最终输出结果
而且一旦输出结果，map的输出结果就可以删除，因此如果把它存储在HDFS中实现备份，难免小题大做。如果该节点运行map任务在将map中间结果传送给reduce任务之前失败，hadoop将在另一个节点重新运行这个map任务以再次构建map中间结果
(所以这个map任务的进度是依赖于最慢的那个---木桶理论)
Reduce任务并不具备数据本地化的优势，原因是---单个reduce任务的输入通常来自于所有mapper的输出。在本例中我们仅有一个reduce任务，其输入是所有map的输出。
因此排过序的map输出需要通过网络传输发送到所有运行reduce任务的节点，数据在reduce端合并，然后由用户定义的reduce函数处理
Reduce的输出直接存在hdfs中
一个mapreduce任务的完整数据流
以上是我在互连网上找到的关于mapreduce最详细的注解：
我们要数图书馆中的所有书。你数1号书架，我数2号书架。这就是“Map”。我们人越多，数书就更快。
现在我们到一起，把所有人的统计数加在一起。这就是“Reduce”。
前面我们介绍了mapreduce的工作模式，但是是由谁来控制mapreduce来完成上面整个mapreduce作业呢？
在hadoop的mapreduce里有两种主要的后台程序：jobtracker和tasktracker。
Jobtracker与Tasktracker：
Jobtracker是主线程，它负责接受客户作业提交，调度任务到工作节点上运行，并提供诸如监控工作节点状态及任务进度管理功能。
Jobtracker：
一个mapreduce集群只有一个jobtracker，一般运行在稳定性高的硬件上，因为主节点一旦出现问题就会导致所有正在运行的作业同时失败。
当一个作业·提交的时候，组成作业的每一个任务信息都会被存储在jobtracker的内存中。
在一个活跃的集群中，可能会同时运行若干个由多个任务组成的作业，这种情况下这些任务信息会占用一大部分内存，所以对jobtracker内存的监控是很主要的。
Tasktracker
Tasktracker通过周期性的心跳来通知jobtracker其当前的健康状况及状态
每一次心跳包含了可用的map和reduce任务数目、占用的数目以及运行中的任务的详细信息
在每一个工作节点上永远只有一个tasktracker。**Tasktracker和datanode运行在同一个物理机器上，从而使得每一个物理机器即是一个计算节点，同时也是一个存储节点。
Tasktracker工作节点出错：
当jobtracker在一段时间内（可配置）收不到tasktracker的心跳，它会认为该tasktracker失效而且曾经在该tasktracker运行过的任务都会被认为失败
这些任务会被重新调度到别的tasktracker上运行；而客户应用程序完全不知道这些内部错误，只会感觉到作业的执行变慢了
Jobtracker出错是更加严重的事情
假如jobtracker出错，那么其当前运行的作业的内部状态信息会被丢失，即使jobtracker马上恢复了，所有正在运行的任务都将认为是失败。这实际上意味着对mapreducev1来说，jobtracker是有单点故障的
Mapreduce v1的两个缺点：
首先单个集群就一个jobtracker，没有HA
另外jobtracker的内存限制太明显
比如雅虎的一个用于支持多系统的超过4000个节点的Hadoop集群，该团队发现单一的jobtracker需要太多的资源，另外jobtracker的单点失效问题给这个庞大集群造成了极大的不稳定性，因此YARN应用而生,我们常称为mapreduce V2 版本
