集群的优化
1、合理分配map和reduce任务的数量（单个节点上map任务、reduce任务的最大数量）
2、其他配置
io.file.buffer.size
hadoop访问文件的IO操作都需要通过代码库。因此，在很多情况下，io.file.buffer.size都被用来设置缓存的大小不论是对硬盘或者是网络操作来讲，较大的缓存都可以提供更高的数据传输，但这也就意味着更大的内存消耗和延迟
这个参数要设置为系统页面大小的倍数，以byte为单位，默认值是4KB，一般情况下，可以设置为64KB（65536byte）
dfs.balance.bandwidthPerSec
HDFS平衡器检测集群中使用过度或者使用不足的DataNode，并在这些DataNode之间移动数据块来保证负载均衡，如果不对平衡操作进行带宽限制，那么它会很快就会抢占所有的网络资源，不会为Mapreduce作业或者数据输入预留资源
参数dfs.balance.bandwidthPerSec定义了每个DataNode平衡操作所允许的最大使用带宽，这个值的单位是byte，这是很不直观的，因为网络带宽一般都是用bit来描述的。因此，在设置的时候，要先计算好。DataNode使用这个参数来控制网络带宽的使用，但不幸的是，这个参数在守护进程启动的时候就读入，导致管理员没办法在平衡运行时来修改这个值
dfs.block.size 默认128M
dfs.block.size的单位是byte，默认值是67108864 (64MB)。对于很多情况来说，134217728 (128MB)更加合适
对于一个Mapreduce作业（尤其是用子类FileInputFormat定义输入格式的作业），对文件的每个数据块会启用一个map任务来处理
这就意味这数据块的大小显著地影响Mapreduce作业的效率
dfs.datanode.du.reserved 保留空间 用于mapreduce使用 默认为0
当DataNode向NameNode汇报可用的硬盘大小的时候，它会把所有dfs.data.dir所列出的可用的硬盘大小总和发给NameNode
由于mapred.local.dir经常会跟DataNode共享可用的硬盘资源，因为我们需要为Mapreduce任务保留一些硬盘资源。dfs.datanode.du.reserved
定义了每个dfs.data.dir所定义的硬盘空间需要保留的大小，以byte为单位。默认情况下，该值为0.也就意味着HDFS可以使用每个数据硬盘的所有空间
节点硬盘资源耗尽时就会进入读模式。因此，建议每个硬盘都为map任务保留最少10GB的空间，如果每个Mapreduce作业都会产生大量的中间结果
或者每个硬盘空间都比较大（超过2TB），那么建议相应的增大保留的硬盘空间
dfs.namenode.handler.count
NameNode有一个工作线程池用来处理客户端的远程过程调用及集群守护进程的调用。处理程序数量越多意味着要更大的池来处理来自不同DataNode的并发心跳以及客户端并发的元数据操作。对于大集群或者有大量客户端的集群来说，通常需要增大参数dfs.namenode.handler.count的默认值10。设置该值的一般原则是将其设置为集群大小的自然对数乘以20，即20logN，N为集群大小
如果该值设的太小，明显的状况就是DataNode在连接NameNode的时候总是超时或者连接被拒绝，但NameNode的远程过程调用队列很大时远程过程调用延时就会加大。症状之间是相互影响的，很难说修改dfs.namenode.handler.count就能解决问题，但是在查找故障时，检查一下该值的设置是必要的
dfs.datanode.failed.volumes.tolerated
当DataNode的任何一个本地磁盘出故障时，它的默认行为认定整个DataNode失效。在一个中到大型的集群中，硬盘故障是相当常见的，所以这种行为不是最优的。一个 DataNode的丢失会导致一些数据块备份数下降，因此，NameNode会命令其他DataNode复制这些丢失的数据块来增加被附属。参数dfs.datanode.failed.volumes.tolerated 定义整个DataNode声明失败前允许多少个硬盘出现故障
很多人会问，为什么不能容忍所有磁盘失效的情况，这样就可以把整个DataNode的失效推迟到没有任何可工作的硬盘为止
对于一个永久的时间窗口来说，这看上去很合理的，但是实际上，对于所以的磁盘来说，管理员对于磁盘故障的处理都会早于由于正常磨损而出现的故障。只有一种情况例外，所以的硬盘在一个极短的时间内全部出现故障，这种异常情况需要立即调查。在实践中快速的磁盘故障通常意味着驱动控制器或者某些部件故障。正因为罕见，但如果磁盘在短时间内开始出现一连串故障，最好的办法就是立即隔离。先把整个集群设置为不可用，直到找到失败的原因为止。参数dfs.datanode.failed.volumes.tolerated默认值为0，也就意味着只要有一个磁盘出现故障就会导致整个DataNode不可用，管理员可以增大该值来保证在出现部分磁盘故障时，DataNode仍能持续运行，但是需要保持谨慎的是，在极短的时间范围内出现一个或者两个磁盘故障表明一个更大的问题存在
fs.trash.interval
用户经常会意外删除文件。HDFS支持回收站功能，这类似于大多数操作系统的回收站，当这个功能被启用文件被移到用户的HDFS主目录中一个名为.Trash目录中，来保留被删除的文件，而不是立即彻底删除。fs.trash.interval定义.Trash目录下文件被永久删除前保留的时间。在文件被从HDFS永久删除前，用户可以*地把文件从该目录下移出来并立即还原。默认值是0说明垃圾回收站功能是关闭的。要清楚，回收站功能不是万能的，推迟删除意味着要文件所占据的空间仍不可用，除非它被永久删除。用户可以通过运行hadoop fs -expunge命令。或者干脆等待指定的时间来明确回收站清空。可以在hadoop fs -rm命令通过指定-skipTrash参数来跳过回收站从而立即删除文件
3、map的优化
io.sort.mb 默认为100M
map任务产生中间数据默认会先放到内存中 当大小达到上面设置的值会进行spill根据需要调整改参数 适当增大 减少spill的次数
io.sort.spill.percent 一般不做调整
spill时占比 默认为0.8
io.sort.factor 默认为10
在map任务计算完成后会有一个merge操作 默认为10 即最多10个spill文件合并,如果spill大于10个会分多次merge,合理的设置该参数可以减少merge次数
min.num.spill.for.combine（default 3）
当job中设定了combiner，并且spill数最少有3个的时候，那么combiner函数就会在merge产生结果文件之前运行
如果spill过多的时候 合适的设置该值 可以减少spill前的数据,减少合并时的数据
mapred.compress.map.output(default false)
也就是说map的中间，无论是spill的时候，还是最后merge产生的结果文件，都是可以压缩的
压缩的好处在于，通过压缩减少写入读出磁盘的数据量,中间结果非常大，磁盘速度成为map执行瓶颈的job，尤其有用
该参数采用的是cpu换io(解压缩) ,一般来说都会是磁盘io产生瓶颈 ,所以通常可以设置为true
mapred.map.output.compression.codec( default org.apache.hadoop.io.compress.DefaultCodec)
采用map中间结果压缩的情况下，用户还可以选择压缩时采用哪种压缩格式进行压缩
现在hadoop支持的压缩格式有：GzipCodec，LzoCodec，BZip2Codec，LzmaCodec等压缩格式
通常来说，想要达到比较平衡的cpu和磁盘压缩比，LzoCodec比较适合。但也要取决于job的具体情况
4、reduce的优化
reduce 分成三个阶段的 分别为copy->sort->reduce
由于job的每一个map都会根据reduce(n)数将数据分成map 输出结果分成n个partition,所以map的中间结果中是有可能包含每一个reduce需要处理的部分数据的，所以，为了优化reduce的执行时间，hadoop中是等job的第一个map结束后,所有的reduce就开始尝试从完成的map中下载该reduce对应的partition部分数据，这个过程就是通常所说的shuffle，也就是copy过程
mapred.reduce.parallel.copies（default 5） 每个reduce并行下载map结果的最大线程数
每个只会有5个并行的下载线程在从map下数据，如果一个时间段内job完成的map有100个或者更多,那么reduce也最多只能同时下载5个map的数据
所以这个参数比较适合map很多并且完成的比较快的job的情况下调大，有利于reduce更快的获取属于自己部分的数据
mapred.reduce.copy.backoff（default 300秒） reduce下载线程最大等待时间(秒)
reduce的每一个下载线程在下载某个map数据的时候，有可能因为那个map中间结果所在机器发生错误或者中间结果的文件丢失，或者网络瞬断等等情况，这样reduce的下载就有可能失败，所以reduce的下载线程并不会无休止的等待下去，当一定时间后下载仍然失败，那么下载线程就会放弃这次下载,并在随后尝试从另外的地方下载，如果集群环境的网络本身是瓶颈，那么用户可以通过调大这个参数来避免reduce下载线程被误判为失败的情况。不过在网络环境比较好的情况下，没有必要调整。通常来说专业的集群网络不应该有太大问题，所以这个参数需要调整的情况不多
io.sort.factor
Reduce将map结果下载到本地时，同样也是需要进行merge的，所以io.sort.factor的配置选项同样会影响reduce
进行merge时的行为，当发现reduce在shuffle阶段iowait非常的高的时候，就有可能通过调大这个参数来加大一次merge时
的并发吞吐，优化reduce效率
mapred.job.shuffle.input.buffer.percent（default 0.7） 用来缓存shuffle数据的reduce task heap百分比
Reduce在shuffle阶段对下载来的map数据，并不是立刻就写入磁盘的，而是会先缓存在内存中，然后当使用内存达到一定量的时候才刷入磁盘,这个内存大小的控制就不像map一样可以通过io.sort.mb来设定了，而是通过另外一个参数来设置，也就是说，如这个参数其实是一个百分比，意思是说，shuffile在reduce内存中的数据最多使用内存量为：0.7 × maxHeap of reduce task果该reduce task的最大heap使用量（通常通过mapred.child.java.opts来设置，比如设置为-Xmx1024m）的一定比例用来缓存数据，如果reduce的heap由于业务原因调整的比较大，相应的缓存大小也会变大，这也是为什么reduce用来做缓存的参数是一个百分比，而不是一个固定的值了
mapred.job.shuffle.merge.percent（default 0.66） 缓存的内存中多少百分比后开始做spill操作
如果下载速度很快，很容易就把内存缓存撑大，那么调整一下这个参数有可能会对reduce的性能有所帮助
mapred.job.reduce.input.buffer.percent（default 0.0） sort完成后reduce计算阶段用来缓解数据的百分比
当reduce将所有的map上对应自己partition的数据下载完成后，就会开始真正的reduce计算阶段（中间有个sort阶段通常时间非常短，几秒钟就完成了，因为整个下载阶段就已经是边下载边sort，然后边merge的）当reduce task真正进入reduce函数的计算阶段的时候，有一个参数也是可以调整reduce的计算行为，由于reduce计算时肯定也是需要消耗内存的，而在读取reduce需要的数据时，同样是需要内存作为buffer，这个参数是控制，需要多少的内存百分比来作为reduce读已经sort好的数据的buffer百分比，默认情况下为0也就是说，默认情况下，reduce是全部从磁盘开始读处理数据,如果这个参数大于0，那么就会有一定量的数据，被缓存在内存并输送给reduce，当reduce计算逻辑消耗内存很小时，可以分一部分内存用来缓存数据，反正reduce的内存闲着也是闲着
mapred.reduce.slowstart.completed.maps（map完成多少百分比时，开始shuffle）
当map运行慢，reduce运行很快时，如果不设置mapred.reduce.slowstart.completed.maps会使job的shuffle时间变的很长，map运行完很早就开始了reduce，导致reduce的slot一直处于被占用状态,这个值是和“运行完的map数除以总map数”做判断的，当后者大于等于设定的值时，开始reduce的shuffle。所以当map比reduce的执行时间多很多时，可以调整这个值（0.75,0.80,0.85及以上）
下面从map流程里描述一下map中各个参数的作用： 没有reduce
1、当map task开始运算，并产生中间数据时，其产生的中间结果并非直接就简单的写入磁盘。这中间的过程比较复杂，并且利用到了
内存buffer来进行已经产生的部分结果的缓存，并在内存buffer中进行一些预排序来优化整个map的性能。每一个map都会对应存
在一个内存buffer（MapOutputBuffer），map会将已经产生的部分结果先写入到该buffer中，这个buffer默认是100MB大小，但
是这个大小是可以根据job提交时的参数设定来调整的，该参数即为：io.sort.mb。当map的产生数据非常大时，并且把io.sort.mb
调大，那么map在整个计算过程中spill的次数就势必会降低，map task对磁盘的操作就会变少，如果map tasks的瓶颈在磁盘上，
这样调整就会大大提高map的计算性能
2、map在运行过程中，不停的向该buffer中写入已有的计算结果，但是该buffer并不一定能将全部的map输出缓存下来，当map输出
超出一定阈值（比如100M），那么map就必须将该buffer中的数据写入到磁盘中去，这个过程在mapreduce中叫做spill。map并
不是要等到将该buffer全部写满时才进行spill，因为如果全部写满了再去写spill，势必会造成map的计算部分等待buffer释放空间的
情况。所以，map其实是当buffer被写满到一定程度（比如80%）时，就开始进行spill。这个阈值也是由一个job的配置参数来控
制，即io.sort.spill.percent，默认为0.80或80%。这个参数同样也是影响spill频繁程度，进而影响map task运行周期对磁盘的读写
频率的。但非特殊情况下，通常不需要人为的调整。调整io.sort.mb对用户来说更加方便。
3、当map task的计算部分全部完成后，如果map有输出，就会生成一个或者多个spill文件，这些文件就是map的输出结果。map在正
常退出之前，需要将这些spill合并（merge）成一个，所以map在结束之前还有一个merge的过程。merge的过程中，有一个参数
可以调整这个过程的行为，该参数为：io.sort.factor。该参数默认为10。它表示当merge spill文件时，最多能有多少并行的stream
向merge文件中写入。比如如果map产生的数据非常的大，产生的spill文件大于10，而io.sort.factor使用的是默认的10，那么当
map计算完成做merge时，就没有办法一次将所有的spill文件merge成一个，而是会分多次，每次最多10个stream。这也就是说，
当map的中间结果非常大，调大io.sort.factor，有利于减少merge次数，进而减少map对磁盘的读写频率，有可能达到优化作业的
目的
4、当job指定了combiner的时候，我们都知道map介绍后会在map端根据combiner定义的函数将map结果进行合并。运行combiner
函数的时机有可能会是merge完成之前，或者之后，这个时机可以由一个参数控制，即min.num.spill.for.combine（default 3），
当job中设定了combiner，并且spill数最少有3个的时候，那么combiner函数就会在merge产生结果文件之前运行。通过这样的方
式，就可以在spill非常多需要merge，并且很多数据需要做conbine的时候，减少写入到磁盘文件的数据数量，同样是为了减少对磁
盘的读写频率，有可能达到优化作业的目的
5、减少中间结果读写进出磁盘的方法不止这些，还有就是压缩。也就是说map的中间，无论是spill的时候，还是最后merge产生的结
果文件，都是可以压缩的。压缩的好处在于，通过压缩减少写入读出磁盘的数据量。对中间结果非常大，磁盘速度成为map执行瓶
颈的job，尤其有用。控制map中间结果是否使用压缩的参数为：mapred.compress.map.output(true/false)。将这个参数设置为
true时，那么map在写中间结果时，就会将数据压缩后再写入磁盘，读结果时也会采用先解压后读取数据。这样做的后果就是：写
入磁盘的中间结果数据量会变少，但是cpu会消耗一些用来压缩和解压。所以这种方式通常适合job中间结果非常大，瓶颈不在
cpu，而是在磁盘的读写的情况。说的直白一些就是用cpu换IO。根据观察，通常大部分的作业cpu都不是瓶颈，除非运算逻辑异常
复杂。所以对中间结果采用压缩通常来说是有收益的
6、当采用map中间结果压缩的情况下，用户还可以选择压缩时采用哪种压缩格式进行压缩，现在hadoop支持的压缩格式有：
GzipCodec，LzoCodec，BZip2Codec，LzmaCodec等压缩格式。通常来说，想要达到比较平衡的cpu和磁盘压缩比，LzoCodec
比较适合。但也要取决于job的具体情况。用户若想要自行选择中间结果的压缩算法，可以设置配置参数：
mapred.map.output.compression.codec=org.apache.hadoop.io.compress.DefaultCodec或者其他用户自行选择的压缩方式。