Hadoop 创建比我们拥有的节点更多的减速器有意义吗？

因此，具有良好还原阶段的主要思想是良好的分区分布。但例如，我们无法控制它，或者不知道如何做到这一点（我们不知道我们的数据）

大量的reducer是否会增加每个reducer数据分布更好的机会？

---

这个问题的常见做法是什么？

通常使用模散列分区将数据均匀地分布在还原程序中。这意味着（有效地）键的散列除以减缩器的数量，剩余部分是值发送到的减缩器的索引。例如，如果密钥的散列是47269893425623，并且有10个减缩器，47269893425623%10=3，那么第四个减缩器（记住，0索引）将获得该记录

如果您的记录具有热点键，这意味着很大一部分值具有完全相同的键，那么添加减缩器可能不会有帮助（您只会增加开销-所有这些键仍将使用相同的减缩器）

---

如果您没有这种情况，那么添加减速器可能会有所帮助。请记住，映射器和reducer之间有一个网络复制阶段。分解减缩器越多，映射器和减缩器之间需要进行的复制就越多，因此部分工作会变得更慢。

选择减缩器的数量在某些方面更像是一门艺术，而不是一门科学。你只需要尝试不同的东西，看看什么最适合你的工作

总的来说，我看到了几个主要的选择：

• 1-2个减速机——这适用于输出量较小的作业，在这些作业中，只需输出几个文件，即可提高后期处理的效率
• 系统上95%的reduce插槽—这将充分利用集群进行中型和大型MapReduce作业。您希望使用95%，这样您就不会阻止较小的作业完成
• 系统上的插槽减少了190%——这只适用于非常大的作业，不需要经常使用

增加减速器的数量只能起到这么大的作用。从数学意义上讲，假设除了热键之外，所有的键都是均匀分布的。然后，您的reducer分布，给定的热键是100MB，其他的都是100MB（极端）。如果您有两个减速机，您将有大约150MB的减速机1和50MB的减速机2。使用三个减速机，您将有一个133MB（100MB+33MB）的减速机，另外两个33MB。有了100个减速机，你会看到一个有101MB，其余的都有1MB。正如你所看到的，增加减速器的数量并没有多大帮助，但确实有一点帮助。可能还不足以把它摊得那么薄

---

热点不会成为许多工作的问题。默认的分区行为是完全合理的，可以提供相对均匀的分布

---

如果您确实有一个要挤压的热点或一个非常倾斜的数据集，那么您可以编写一个自定义分区器来编写数据所指向的特殊规则。例如，如果您知道有三个键是热点，则可以编写一个分区器，将键1发送到reducer 1，键2发送到reducer 2，键3发送到reducer 3，然后将其他所有内容发送到其他reducer。

“拆分reducer越多，映射器和reducer之间需要进行的复制就越多，所以这部分工作会变慢。”——我不同意这一点。没有发送更多数据。。。同样数量的数据被进一步拆分。如果有什么不同的话，它将使它运行得更快，因为您正在使网络运动更加并行化。