克里斯托弗·史密斯回答了这个问题，他允许我在这里发帖。
一如既往……”视情况而定”。有一件事你几乎总是可以指望的：以后添加节点并不像从一开始就有节点那样对你有帮助。
当你创建一个hadoop作业时，它会被分成多个任务。这些任务实际上是“工作的原子”。hadoop允许您在创建作业期间调整mapper任务的#和reducer任务的#，但是一旦创建了作业，它就是静态的。任务分配给“插槽”。传统上，每个节点都被配置为具有一定数量的用于Map任务的插槽，以及具有一定数量的用于减少任务的插槽，但您可以对此进行调整。一些较新版本的hadoop不需要将插槽指定为用于map或reduce任务。无论如何，jobtracker会定期将任务分配给插槽。因为这是动态完成的，新节点上线后可以通过提供更多执行任务的插槽来加快作业的处理速度。
这为理解添加新节点的实际情况奠定了基础。很明显，amdahl定律存在一个问题，即拥有比挂起任务更多的插槽完成的任务很少（如果您启用了推测性执行，它确实会有所帮助，因为hadoop会将同一个任务安排在许多不同的节点上运行，这样，如果有空闲资源，速度较慢的节点的任务可以由速度较快的节点完成）。因此，如果您没有用许多map或reduce任务定义作业，那么添加更多节点将不会有多大帮助。当然，每项任务都会带来一些开销，所以你也不想太兴奋。这就是为什么我建议任务大小的指导原则应该是“需要2-5分钟才能执行的任务”。
当然，动态添加节点时，它们还有一个缺点：没有任何本地数据。显然，如果您处于emr管道的起始位置，则没有任何节点包含数据，因此无所谓，但是如果您的emr管道由许多作业组成，早期作业将其结果持久化到hdfs，您将获得巨大的性能提升，因为jobtracker将有利于形成和分配任务，从而使节点具有可爱的数据局部性（这是整个mapreduce设计的核心技巧，可以最大限度地提高性能）。在reducer方面，数据来自其他map任务，因此动态添加的节点与其他节点相比并没有任何劣势。
因此，原则上，动态添加新节点实际上不太可能有助于处理从hdf读取的io绑定map任务。
除了。。。
hadoop有各种各样的秘密来优化性能。一次是在map任务完成/reducer启动之前，它开始将map输出数据传输到reducer。对于Map器生成大量数据的作业来说，这显然是一个关键的优化。当hadoop开始启动传输时，您可以进行调整。不管怎样，这意味着新启动的节点可能处于不利地位，因为现有的节点可能已经具有如此巨大的数据优势。显然，Map器传输的输出越多，缺点就越大。
这才是真正的工作原理。但实际上，很多hadoop作业都让Map器以cpu密集型的方式处理大量数据，但将相对较少的数据输出到reducer（或者它们可能会将大量数据发送到reducer，但reducer仍然非常简单，因此根本不受cpu限制）。通常，作业的reducer任务很少（有时甚至为0），因此即使是额外的节点也会有所帮助，如果您已经为每个未完成的reduce任务提供了reduce槽，那么新节点就无能为力了。新节点也不成比例地帮助处理cpu受限的工作，原因很明显，因此，由于这往往是Map任务多于减少任务，因此人们通常认为这是成功的地方。如果您的Map器是i/o绑定的，并且从网络中提取数据，那么添加新节点显然会增加集群的聚合带宽，因此这在这方面很有帮助，但是如果您的Map任务是i/o绑定的，正在读取HDF，那么最好的做法是拥有更多的初始节点，数据已经分布在HDF上。由于作业结构不良，reducer受到i/o限制的情况并不少见，在这种情况下，添加更多节点会有很大帮助，因为它会再次分割带宽。
当然，这里也有一个警告：对于一个非常小的集群，reducer可以从本地节点上运行的Map器读取大量的数据，添加更多的节点会将更多的数据转移到更慢的网络上。您还可以遇到这样的情况：reducer将大部分时间花在复用来自所有Map器的数据处理上，这些Map器将数据发送给他们（尽管这也是可以调整的）。
如果你问这样的问题，我强烈建议你使用类似amazon提供的karmasphere来分析你的工作。它将使您更好地了解瓶颈所在，以及改进性能的最佳策略。