1、执行架构
2、Master 数据结构
Master 持有一些数据结构，它存储每一个 Map 和 Reduce 任务的状态（空闲、工作中或完成)，以及 Worker机器(非空闲任务的机器)的标识。
Master 就像一个数据管道，中间文件存储区域的位置信息通过这个管道从 Map 传递到 Reduce。因此，对于每个已经完成的 Map 任务，master 存储了 Map 任务产生的 R 个中间文件存储区域的大小和位置。当 Map任务完成时，Master 接收到位置和大小的更新信息，这些信息被逐步递增的推送给那些正在工作的 Reduce 任务。
3、容错
3.1 work故障
1、master ping不通，则表示为失败；
2、work失败，master将任务调度到其他work执行。
3、work失败的时候map已经完成，但是map输出的文件存储在该work节点上，因此reduce还是无法读取的，因此map的work失败，整个任务要么直接失败，要么重新启动别的work执行
3.2 master故障
1、master失败，可以使用checkpoint文件进行恢复，由于只有一个 master 进程，master 失效后再恢复是比较麻烦的
2、master失败以后，客户端检测到失败重启mr任务（当前的实现方式）
3.3 在失效方面的处理机制（临时文件重命名）
我们依赖对 Map 和 Reduce 任务的输出是原子提交的来完成这个特性。每个工作中的任务把它的输出写到私有的临时文件中。每个 Reduce 任务生成一个这样的文件，而每个 Map 任务则生成 R 个这样的文件（一个 Reduce 任务对应一个文件，一个Map生成R个临时文件，hadoop则会合并成一个文件）。当一个 Map 任务完成的时，worker 发送一个包含 R 个临时文件名的完成消息给 master。如果 master 从一个已经完成的 Map 任务再次接收到到一个完成消息，master 将忽略这个消息；否则，master 将这 R 个文件的名字记录在数据结构里。当 Reduce 任务完成时，Reduce worker 进程以原子的方式把临时文件重命名为最终的输出文件。
如果同一个 Reduce 任务在多台机器上执行（推测执行的情况），针对同一个最终的输出文件将有多个重命名操作执行。我们依赖底层文件系统提供的重命名操作的原子性来保证最终的文件系统状态仅仅包含一个 Reduce 任务产生的数据。
4 存储位置
文件就近分配mr任务，减少网络带宽
5、任务粒度
map阶段对输出文件进行拆分，Reduce一般可以手动指定，一个Reduce输出一个文件。
6、备用任务
推测执行，map reduce中，有些执行时间比较长的，如果是因为服务器资源分配问题导致慢的，其中备用任务还是很有效果的，但是如果是数据倾斜导致的，那么备用任务时无济于事的；
推测执行虽然会浪费一些资源，但是当遇到执行时间比较成的任务，推测执行比失败重试要快44%
7、一些技巧
7.1 自定义分区函数
7.2 给定分区中，中间 key/value pair 按照 key 值增量顺序处理，与读取该分区文件一直？
7.3 combiner 函数
7.4 自定义reader，不一定只读取文件，可以自定义reader读取内存，读取网络数据
7.5 在某些情况下，MapReduce 的使用者发现，如果在 Map 或 Reduce 操作过程中增加辅助的输出文件会比较省事。我们依靠程序 writer 把这种“副作用”变成原子的和幂等的。通常应用程序首先把输出结果写到一个临时文件中，在输出全部数据之后，在使用系统级的原子操作 rename 重新命名这个临时文件。
7.6 跳过损坏的记录：用户程序 bug 导致系统 crash，worker 向 master 发送记录序号，多次发生后，master 可标记跳过这条记录
7.7 计数器：可以自定义计数器，系统也会有自定义计数器可用
