当jobtracker将作业分配给hdfs上的tasktracker时，将根据数据的位置将作业分配给特定节点（首选项是先相同节点，然后相同网络交换机/帧）。通过使用不同的复制因子，您限制了jobtracker将本地节点分配给数据的能力（jobtracker仍将分配任务节点，但没有本地性的好处）。这样做的效果是限制tasktracker节点的数量，这些节点都是数据的本地节点（要么是任务节点上的数据，要么是同一交换帧上的数据），从而影响任务的性能（减少并行化）。
较小的集群可能只有一个交换机，因此数据是网络/帧的本地数据，因此您可能遇到的唯一瓶颈是从一个tasktracker到另一个tasktracker的数据传输，因为jobtracker可能会将作业分配给所有可用的tasktracker。
但是对于更大的hadoop集群，复制因子=1将限制数据本地的tasktracker节点的数量，从而能够有效地对数据进行操作。
有几篇论文支持数据局部性，http://web.eecs.umich.edu/~michjc/papers/tandon_hpdic_minimizeremoteaccess.pdf，你引用的这篇论文也支持数据局部性，http://assured-cloud-computing.illinois.edu/sites/default/files/pid1974767.pdf，还有这个， http://www.eng.auburn.edu/~xqin/pubs/hcw10.pdf （它测试了一个5节点集群，与op相同）。
本文引用了数据局部性的显著优点，http://grids.ucs.indiana.edu/ptliupages/publications/investigationdatalocalityinmapreduce_ccgrid12_submitted.pdf，并观察到复制因子的增加提供了更好的局部性。
注意，本文声称网络吞吐量和本地磁盘访问（8%）之间的差别很小，http://www.cs.berkeley.edu/~ganesha/disk-irrelevant_hotos2011.pdf，但报告了本地内存访问与磁盘或网络访问之间性能的数量级差异。此外，文章还引用了一大部分作业（64%）在内存中找到缓存的数据，“很大程度上是由于工作负载的重尾特性”，因为大多数作业“只访问一小部分块”。

编辑：我的答案的这一部分已经过时了，因为另一个答案被编辑了：“另一个答案并不完全正确。”这是为了解决复制品越少=平行性越少的错误含义。我剩下的答案（下面）仍然适用。
任何节点都可以执行任务，而不管数据是否位于该节点中。hadoop将尝试实现数据局部性（首选顺序是：node local，然后rack local，然后any node），但如果不能实现，它将选择任何具有可用计算能力的节点来运行任务。
性能方面，在典型的多机架安装中，机架本地的性能几乎与节点本地一样好，因为在机架间传输数据时会出现瓶颈。然而，使用高端网络设备（即全二等分带宽），那么您的计算是否是机架本地的就不重要了。有关这方面的更多细节，请阅读本文。
通过使用更多的副本（从而实现更高的数据局部性），您可以期望有多大的性能改进？不多；最大改善5-20%。但当您在this和this项目中实现其他基于流行度的复制时，这是一个上限。注：我并不是仅仅弥补了那些绩效改善数字；它们来自我链接的文件。
由于vanilla hadoop没有这些机制，我希望您的性能最多提高1-5%。这只是一个大概的猜测，但你可以很容易地运行一些测试自己。这样做的原因是，更多的副本可以提高某些Map任务（现在可以使用块的数据本地副本运行的任务）的性能，但不会改善无序排列和减少阶段。此外，即使只有一个Map器比其他Map器需要更长的时间，这个Map器也将决定整个Map阶段的长度；因此，对于许多工作来说，增加本地性很可能根本不会改善它们的运行时间。最后，i/o绑定的作业可以是map input io绑定、shuffle io绑定（map output heavy）或reduce output io绑定。只有第一种类型（map input io-bound）会受益于局部性。本文将详细介绍mapreduce工作负载特性。
如果您对此感兴趣，还可以阅读本文，其中改进了Map器的运行时间，但将所有Map器的输入数据都存储在内存中。