mapper和reducer的划分###
mapper的数量等于输入文件被划分成的分块数，这取决于输入文件的大小以及文件块的大小。一个map操作只处理一个输入分片。运行作业的客户端通过调用getSplits()计算分片，然后将它们发送到jobtracker，jobtracker使用其存储位置信息来调度map任务从而在tasktracker上处理这些分片数据。一般默认分片大小就是块的大小，分片的大小由以下公式计算：
max(minimumSize，min(maximumSize，blockSize))
在默认情况下：minimumSize < blockSize < maximumSize
可以通过调整maximumSize和minimumSize来控制分片大小。
reducer的最优个数与集群中可用的reducer任务槽数有关，总槽数由集群中节点数与每个节点的任务槽数相乘得到。一个常用的方法是设置reducer的个数比总槽数稍微少一点，给reducer任务留点余地(容忍一些错误发生而不需要延长作业的运行时间)，如果reduce任务很大，比较明智的做法是使用更多的reducer，使任务粒度更小，从而使任务失败不至于显著影响作业执行时间。
但是map和reduce的数量也不能过多，数量过多虽然可以提高任务并行度，但是太多的map和reduce也会导致整个hadoop框架因为过度的系统资源开销而使任务失败。所以用户在提交map/reduce作业时应该在一个合理的范围内，这样既可以增强系统负载匀衡，也可以降低任务失败的开销。
reduce在运行时往往需要从相关map端复制数据到reduce节点来处理，因此相比于map任务。reduce节点资源是相对比较缺少的，同时相对运行较慢，正确的reduce任务的个数应该是0.95或者1.75 *（节点数 ×mapred.tasktracker.tasks.maximum参数值）。如果任务数是节点个数的0.95倍，那么所有的reduce任务能够在 map任务的输出传输结束后同时开始运行。如果任务数是节点个数的1.75倍，那么高速的节点会在完成他们第一批reduce任务计算之后开始计算第二批 reduce任务，这样的情况更有利于负载均衡。同时需要注意增加reduce的数量虽然会增加系统的资源开销，但是可以改善负载匀衡，降低任务失败带来的负面影响。
mapreduce的输入输出格式###
一个被指定为输入路径的目录，其内容不会被递归处理，事实上，这个目录只包含文件，如果包含子目录，也会被解释为文件，从而产生错误，处理的方法是：使用一个文件glob或一个过滤器根据命名模式限定选择目录下的文件；另一种方法是将mapred.input.dir.recursive设置为true从而强制对输入目录进行递归的读取。
FileInputFormat会使用一个默认的过滤器来排除隐藏文件，如果设置了过滤器，它会在默认过滤器的基础上进行过滤，即自定义过滤器只能看到非隐藏文件。
WholeFileInputFormat
将整个文件读为一条记录
NLineInputFormat
可以设置每个mapper收到的输入行数，一般来说，对少量输入行执行map任务是比较低效的（任务初始化的额外开销造成的）
MultipleInputs
输入多个数据源行格式不同的数据文件，可以指定不同的Mapper处理对应的文件
MultipleOutput
可以根据键值将数据写到多个文件