第三个问题：
你可以玩方块大小。
默认情况下，如果不在Hadoop1.x中配置块大小，则为64MB
hadoop 2.x它的128 mb
假设您有一个1 gb的文件，如果块大小是64 mb，那么在默认情况下，如果您为输入拆分大小配置了任何东西，那么您的输入拆分大小将等于块大小，这样16个64 mb的拆分将在1 gb中存在，并且每个拆分对应的1个Map器意味着16个Map器将为1 gb的数据调用
如果您将块大小更改为128 mb，那么8Map器将用于256mb块大小4，而512 mb块大小2Map器将使用类似的方式。
第二个问题：复制因子可以提高map-reduce任务性能，因为如果数据可以正确复制，那么任务跟踪器可以直接在块上运行，否则它将不得不从其他节点复制该块，这将使用网络带宽，从而降低性能。
第一个查询：
一旦任何一个作业在该作业结束时完成，它就有了所有的统计信息，比如使用了多少Map器和多少缩减器，写入了多少字节，执行了多长时间，并且它有所有的细节。

@纳马纳木，
查询1：
如果您使用的是一个单独的驱动程序类，那么您可以使用java定时器来通过在两个类之间添加主代码来了解所花的时间 long start = System.currentTimeMillis(); 以及 long stop = System.currentTimeMillis(); 所花的时间是 (stop-start)/1000 秒。
查询3：当您使用hadoop jar myfile.jar通过命令行执行一个作业时，最终您将找到所有属性，如Map器编号、还原器、输入组、还原组以及所有其他信息。

第一个查询
我不确定cmd语法，但您可以在作业完成后使用javaapi本身。如：

job.waitForCompletion(false);
if(job.isSuccessful()){
   System.out.println("completionTime :" 
    + (job.getFinishTime() - job.getStartTime())/1000 + "s");
}

第二个查询
它会影响工作绩效。因为现在作业不能像复制因子为3时那样充分利用数据的局部性。数据必须传输到插槽可用的TaskTracker，从而导致更多的网络io和性能下降。
第3个查询
Map器的数目总是等于输入的数目。正统的方法是写一个习惯 InputFormat 它将根据指定的条件溢出数据文件。假设你有一个1gb的文件&你想要5个Map器，就让 InputFormat 在200mb上执行spilts（在默认的64MB块大小上，这将消耗3个以上的块）。
另一方面，使用默认的inputformat，并在提交作业之前手动将文件拆分为所需的Map程序数。为此，约束条件是每个子文件的大小应小于或等于块大小。因此，对于5个Map器，您最多可以使用5*64=320mb的文件大小。
第三种改变blocksize的方法可以在没有这些麻烦的情况下解决问题，但根本不可取。因为每次都需要重新启动集群。
更新
对于第三个查询，最简单，也最可能是最好的解决方案是使用 mapred.max.split.size 每个作业的配置。要为1gb文件运行5个Map，请在提交作业之前执行以下操作：

conf.set("mapred.max.split.size", "209715200"); // 200*1024^2 bytes

很简单，哈。还有另外一个属性 mapred.min.split.size ，但我还是有点搞不懂它的用途。这篇文章可能在这方面对你有所帮助。
相反，你也可以利用 -D 运行作业时的选项。如：

hadoop jar job.jar com.test.Main -Dmapred.map.max.split.size=209715200

注意：这些属性在hadoop2.5.0中被弃用。看看你是否在用它。