Map端的调优属性
io.sort.mb int 100 排序Map输出是所使用内存缓冲区的大小，以MB为单位
io.sort.record.percent float 0.05 用作存储Map输出记录边界的io.sort.mb的比例，剩余的空间存储Map输出记录本身
io.sort.spill.percent float 0.8 Map输出内存缓冲和用来开始磁盘溢出写过程的记录边界索引，是两者使用比例的阀值
io.sort.factor boolean false 排序文件时，一次最后合并的流数，这个属性也在Reduce端使用，将阀值增加到100是很常用的
mapred.compress.map.output 压缩Map的输出
mapred.map.out.compression.codec class org.apache.hadoop.io.compress.DefaultCodec 用于Map输出的压码编码解码
min.num.spills.for.combinar int 3 运行Combinar所需要的最小溢出写文件数
tasktracker.http.threads int 40 每个TaskTracker工作的线程数，用于将Map输出到Reduce这是集群范围的设置，不能有单个作业来设置
Reduce端的调优属性
mapred.reduce.parallel.copies int 5 每个Reduce并行下载Map结果的最大线程数
mapred.reduce.copy.backoff int 300 Reduce下载线程最大等待时间(in sec)
io.sort.factor int 10 同上
mapred.job.shuffle.input.buffer.percent float 0.7 用来缓存Shuffle数据的reduce task heap百分比
mapred.job.shuffle.merge.percent float 0.66 缓存的内存中多少百分比后开始做merge操作
mapred.job.reduce.input.buffer.percent float 0.0 sort完成后Reduce计算阶段用来缓存数据的百分比
2压缩
第一阶段 是否可以分片的压缩（bzip2）。
第二阶段 shuffle的数据应该选择速度比较快的压缩（snappy）
第三阶段 reduce放磁盘就可以使用较高的压缩比节省磁盘空间（bzip2）
(1) Gzip 压缩
优点：压缩率比较高，而且压缩/解压速度也比较快； hadoop 本身支持，在应用中处理gzip 格式的文件就和直接处理文本一样；大部分 linux 系统都自带 gzip 命令，使用方便.
缺点：不支持 split。
应用场景： 当每个文件压缩之后在 130M 以内的（1 个块大小内），都可以考虑用 gzip压缩格式。 例如说一天或者一个小时的日志压缩成一个 gzip 文件，运行 mapreduce 程序的时候通过多个 gzip 文件达到并发。 hive 程序， streaming 程序，和 java 写的 mapreduce 程序完全和文本处理一样，压缩之后原来的程序不需要做任何修改。
?
(2) Bzip2 压缩
优点：支持 split；具有很高的压缩率，比 gzip 压缩率都高； hadoop 本身支持，但不支持 native；在 linux 系统下自带 bzip2 命令，使用方便。
缺点：压缩/解压速度慢；不支持 native。
应用场景： 适合对速度要求不高，但需要较高的压缩率的时候，可以作为 mapreduce 作业的输出格式； 或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持 split，而且兼容之前的应用程序（即应用程序不需要修改）的情况。
?
(3) Lzo 压缩
优点：压缩/解压速度也比较快，合理的压缩率；支持 split，是 hadoop 中最流行的压缩格式；可以在 linux 系统下安装 lzop 命令，使用方便。
缺点：压缩率比 gzip 要低一些； hadoop 本身不支持，需要安装；在应用中对 lzo 格式的文件需要做一些特殊处理（为了支持 split 需要建索引，还需要指定 inputformat 为 lzo 格式）。
应用场景： 一个很大的文本文件，压缩之后还大于 200M 以上的可以考虑，而且单个文件越大， lzo 优点越越明显。
?
(4) Snappy 压缩
优点：高速压缩速度和合理的压缩率。
缺点：不支持 split；压缩率比 gzip 要低； hadoop 本身不支持，需要安装；
应用场景： 当 Mapreduce 作业的 Map 输出的数据比较大的时候，作为 Map 到 Reduce的中间数据的压缩格式；或者作为一个 Mapreduce 作业的输出和另外一个 Mapreduce 作业的输入。
调大reducer
reducer过都多会导致小文件
reducer过少会导致job运行失败，和数据倾斜。
hive 早期1个 0.14版本 reducer处理数据是1G，如果有10G则会有10个
hive 后期1个 reducer处理的数据是256M，如果有10G则会有40个
N = min(参数2，总输入参数参数量/参数1)
减少reducer数据倾斜
reducer 数据倾斜。
reducer 合理 有利于治理数据倾斜。
5增大扇形缓冲区
100M 调整200M
小文件
1:reducer过都多会导致小文件，reducer过多是应为map key太多，合理使用自定义分区器
1：小文件太多，回导致NN主挂掉，备启动时候加载太多的小文件 起不来，一个blk大概200字节
2：太多的maptask 会导致进程太多 资源消耗
3：大量的磁盘io
4：解决小文件，自定义分区器patitions
5：namenode 加载文件到内存压力
MapReduce 2.0 容错性
1）MRAppMaster容错性
一旦运行失败，由YARN的ResourceManager负责重新启动，最多重启次数可由用户设置，默认是2次。一旦超过最高重启次数，则作业运行失败。
2）Map Task/Reduce
Task Task周期性向MRAppMaster汇报心跳；一旦Task 挂掉，则MRAppMaster将为之重新申请资源，并运行之。最多重新运行次数可由用户设置，默认4 次。
6、mapreduce推测执行算法及原理（☆☆☆☆☆）
1）作业完成时间取决于最慢的任务完成时间
一个作业由若干个Map 任务和Reduce 任务构成。因硬件老化、软件Bug 等，某些任务可能运行非常慢。
典型案例：系统中有99%的Map任务都完成了，只有少数几个Map老是进度很慢，完不成，怎么办？
2）推测执行机制
发现拖后腿的任务，比如某个任务运行速度远慢于任务平均速度。为拖后腿任务启动一个备份任务，同时运行。谁先运行完，则采用谁的结果
3）不能启用推测执行机制情况
（1）任务间存在严重的负载倾斜；
（2）特殊任务，比如任务向数据库中写数据。
4）算法原理
假设某一时刻，任务T的执行进度为progress，则可通过一定的算法推测出该任务的最终完成时刻estimateEndTime。另一方面，如果此刻为该任务启动一个备份任务，则可推断出它可能的完成时刻estimateEndTime`,于是可得出以下几个公式：
estimateEndTime=estimatedRunTime+taskStartTime
estimatedRunTime=(currentTimestamp-taskStartTime)/progress
estimateEndTime`= currentTimestamp+averageRunTime
其中，currentTimestamp为当前时刻；taskStartTime为该任务的启动时刻；averageRunTime为已经成功运行完成的任务的平均运行时间。这样，MRv2总是选择（estimateEndTime- estimateEndTime·）差值最大的任务，并为之启动备份任务。为了防止大量任务同时启动备份任务造成的资源浪费，MRv2为每个作业设置了同时启动的备份任务数目上限。
推测执行机制实际上采用了经典的算法优化方法：以空间换时间，它同时启动多个相同任务处理相同的数据，并让这些任务竞争以缩短数据处理时间。显然，这种方法需要占用更多的计算资源。在集群资源紧缺的情况下，应合理使用该机制，争取在多用少量资源的情况下，减少作业的计算时间。