mapreduce性能调优（多层面：调度、配置、程序），持续工作

一，调度器的考量（目前自带两种调度器）：

Capacity Scheduler：

@ numSlotsOccupied：正在running的task占用的slot总数，注意，在Capacity Scheduler中，running task与slot不一定是一一对应的，每个task可获取多个slot，这主要是因为该调度支持内存资源调度，某个task可能需要多个slot包含的内存量。 
Hadoop自带的Capacity Scheduler能够调度大内存任务，原理是：默认情况下每个slot对应一个内存量，当用户提交作业时，需配置一个task需要的内存量，然后两个值相除取丄整便得到了一个task对应的slot数。如：你提交了一个作业，告诉调度器一个task要使用4GB内存，而默认情况下一个slot对应2GB内存，则没运行一个你的task，会使用2个slot。

JobInProcess.java类中定义了两个变量：

volatile int numSlotsPerMap = 1;

volatile int numSlotsPerReduce = 1;

 计算能力调度器（Capacity Scheduler）与公平调度器(Fair Scheduler)对比

（1） 相同点

@ 均支持多用户多队列，即：适用于多用户共享集群的应用环境

@ 单个队列均支持优先级和FIFO调度方式

@ 均支持资源共享，即某个queue中的资源有剩余时，可共享给其他缺资源的queue

（2） 不同点

@ 核心调度策略不同。 计算能力调度器的调度策略是，先选择资源利用率低的queue，然后在queue中同时考虑FIFO和memory constraint因素；而公平调度器仅考虑公平，而公平是通过作业缺额体现的，调度器每次选择缺额最大的job（queue的资源量，job优先级等仅用于计算作业缺额）。

@ 内存约束。计算能力调度器调度job时会考虑作业的内存限制，为了满足某些特殊job的特殊内存需求，可能会为该job分配多个slot；而公平调度器对这种特殊的job无能为力，只能杀掉这种task。

二，配置参数

io.sort.mb

当map的产生数据非常大时，并且把io.sort.mb调大，那么map在整个计算过程中spill的次数就势必会降低，map task对磁盘的操作就会变少，如果map tasks的瓶颈在磁盘上，这样调整就会大大提高map的计算性能

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对磁盘的读写频率，有可能达到优化作业的目的。

mapred.compress.map.output(true/false)

。将这个参数设置为true时，那么map在写中间结果时，就会将数据压缩后再写入磁盘，读结果时也会采用先解压后读取数据。这样做的后果就是：写入磁盘的中间结果数据量会变少，但是cpu会消耗一些用来压缩和解压。所以这种方式通常适合job中间结果非常大，瓶颈不在cpu，而是在磁盘的读写的情况。说的直白一些就是用cpu换IO。根据观察，通常大部分的作业cpu都不是瓶颈，除非运算逻辑异常复杂。所以对中间结果采用压缩通常来说是有收益的。

mapred.map.output.compression.codec

当采用map中间结果压缩的情况下，用户还可以选择压缩时采用哪种压缩格式进行压缩，现在hadoop支持的压缩格式有：GzipCodec，LzoCodec，BZip2Codec，LzmaCodec等压缩格式。通常来说，想要达到比较平衡的cpu和磁盘压缩比，LzoCodec比较适合

三，程序优化

1，尽量使用合适的combiner减少map过程中间数据写磁盘量

2，使用压缩机制