我在1.1GB文件上多次运行Hadoop MapReduce，使用不同数量的映射器和还原器（例如，1个映射器和1个还原器，1个映像器和2个还原器、1个映射程序和4个还原器…）
Hadoop安装在具有超线程的四核机器上。
以下是按最短执行时间排序的前5个结果：
+----------+----------+----------+
| time | # of map | # of red |
+----------+----------+----------+
| 7m 50s | 8 | 2 |
| 8m 13s | 8 | 4 |
| 8m 16s | 8 | 8 |
| 8m 28s | 4 | 8 |
| 8m 37s | 4 | 4 |
+----------+----------+----------+
编辑
1-8减速器和1-8映射器的结果：column=映射器数行=减速器数量
+---------+---------+---------+---------+---------+
| | 1 | 2 | 4 | 8 |
+---------+---------+---------+---------+---------+
| 1 | 16:23 | 13:17 | 11:27 | 10:19 |
+---------+---------+---------+---------+---------+
| 2 | 13:56 | 10:24 | 08:41 | 07:52 |
+---------+---------+---------+---------+---------+
| 4 | 14:12 | 10:21 | 08:37 | 08:13 |
+---------+---------+---------+---------+---------+
| 8 | 14:09 | 09:46 | 08:28 | 08:16 |
+---------+---------+---------+---------+---------+
（1）当我有8个映射器时，程序运行速度看起来会稍微快一点，但为什么随着减少器的数量，程序会变慢？（例如，8mappers/2减速器比8mappers/8减速器快）
（2）当我只使用4个映射器时，速度会慢一点，因为我没有使用其他4个内核，对吧？
映射器和还原器的最佳数量与很多事情有关。
主要目标是在使用的CPU功率、传输的数据量（在映射器中，在映射器和减速器之间，以及在减速器之外）和磁盘"磁头移动"之间取得平衡。
如果mapreduce作业中的每项任务都能"以最小的磁盘头移动"读取/写入数据，则其效果最佳。通常被描述为"顺序读/写"。但是，如果任务是CPU绑定的，那么额外的磁盘头移动不会影响作业。
在我看来，在这种特定的情况下，你有
- 一个完成相当多CPU周期的映射器（即，更多的映射器使它运行得更快，因为CPU是瓶颈，磁盘可以跟上提供输入数据的步伐）
- 一种几乎不执行CPU周期并且主要受IO约束的减速器。这导致使用单个减速器时，您仍然受CPU约束，而使用4个或更多减速器时似乎受IO约束。因此，4个减速器会导致磁盘磁头移动过多
处理这种情况的可能方法：
首先做你所做的：做一些测试运行，看看在给定这个特定作业和你的特定集群的情况下，哪个设置表现最好。
然后你有三个选项：
- 接受你的处境
- 将负载从CPU转移到磁盘或其他方式
- 获得更大的集群：更多的CPU和/或更多的磁盘
转移负载的建议：
-
如果CPU绑定并且所有CPU都已满负荷，则降低CPU负荷：
- 检查代码中是否存在不必要的CPU周期
- 切换到"较低CPU影响"的压缩编解码器：即从GZip切换到Snappy或切换到"无压缩"
- 调整工作中映射器/减速器的数量
-
如果IO绑定，并且您还有一些CPU容量：
- 启用压缩：这会使CPU的工作更加困难，并减少磁盘必须做的工作
- 尝试使用各种压缩编解码器（我建议使用Snappy或Gzip……我经常使用Gzip）
- 调整工作中映射器/减速器的数量
引用"Hadoop明确指南，第3版"，第306页
因为MapReduce作业通常I/O绑定，拥有比处理器更多的任务以变得更好是有意义的利用
超额订阅量取决于作业的CPU利用率运行，但一个好的经验法则是使的因子在一到两之间更多任务（计算映射和减少任务）。
上面引用的一个处理器相当于一个逻辑核心。
但这只是理论上的，很可能每个用例都不同，就像Niels的详细解释一样，需要进行一些测试。