假设我有15个数据块和两个集群。第一个群集有5个节点，复制因子是1，而第二个群集的复制因子是3.如果我运行我的地图作业，我应该期望地图作业的性能或执行时间有任何变化吗？
换句话说，复制如何影响群集上映射器的性能？
答案 0 :(得分：1)
当JobTracker将作业分配给HDFS上的TaskTracker时，会根据数据的位置将作业分配给特定节点（首选项首先是相同的节点，然后是相同的网络交换机/帧）。通过使用不同的复制因子，您可以限制JobTracker为数据本地分配节点的能力（JobTracker仍将分配任务节点，但没有本地化的好处）。其结果是限制数据本地的TaskTracker节点的数量（任务节点上的数据或同一交换机框架上的数据），从而影响任务工作的性能（减少并行化）。
您的较小群集可能只有一个交换机，因此数据是网络/帧的本地数据，因此您可能遇到的唯一瓶颈将是从一个TaskTracker到另一个TaskTracker的数据传输，因为JobTracker是可能会将作业分配给所有可用的TaskTrackers。
但是对于较大的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％）发现他们的数据缓存在内存中“很大程度上是由于工作负载的重尾性”，因为大多数工作“只访问块的一小部分“。
答案 1 :(得分：1)
任何节点都可以执行您的任务，无论数据是否位于该节点中。 Hadoop将尝试实现数据局部性（首选顺序为：node-local，然后是rack-local，然后是任何节点），但如果不能，那么它将选择任何具有可用计算能力的节点来运行任务。 / p>
性能方面，在典型的多机架安装中，机架本地执行几乎与节点本地一样好，因为在机架上传输数据时会出现瓶颈。但是，对于高端网络设备（即全分割带宽），如果您的计算是机架本地的，则无关紧要。有关详细信息，请阅读this paper。
您可以从拥有更多副本（从而实现更高的数据位置）中获得多少性能提升？不多;最大改进率为5-20％。但是，当您在this和this项目中实施其他基于流行度的复制时，这是一个上限。注意：我不只是弥补那些性能提升数字;它们来自我链接的论文。
由于vanilla Hadoop没有这些机制，我希望你的性能最多提升1-5％。这只是一个猜测，但你可以自己轻松地运行一些测试。这样做的原因是，更多的副本可以提高某些map任务的性能（现在可以使用块的数据本地副本运行），但它不会改善你的shuffle并减少阶段。此外，即使只有一个映射器需要比其余映射器更长的时间，这个映射器将确定整个映射阶段的长度;因此，对于许多工作来说，增加地点可能根本不会改善他们的运行时间。最后，I / O绑定作业可以是map-input IO bound，shuffle IO bound（map output heavy），或者是减少输出IO绑定。只有第一种类型（映射输入IO绑定）才能从本地获益。有关this paper中MapReduce工作负载特征描述的更多详细信息。
如果您对此更感兴趣，还可以阅读this paper，其中它们可以改善映射器的运行时间，但是将所有映射器的输入数据保存在内存中。