3

所以主要认为良好的减少阶段是良好的分区分布。但是例如我们无法控制它，或者不知道该怎么做（我们不知道我们的数据）。

大量的 reducer 是否会增加每个 reducer 数据分布更好的机会？这个问题的常见做法是什么？

4

2 回答 2

1

数据通常使用模散列分区在 reducer 之间均匀分布。这意味着（有效地）键的哈希除以reducer 的数量，余数是值被发送到的reducer 的索引。例如，如果你的 key 的哈希是 47269893425623，并且你有 10 个 reducer，47269893425623 % 10 = 3，那么第 4 个 reducer（记住，0-indexed）获取该记录。

如果您的记录有热点键，这意味着大部分值具有完全相同的键，那么添加减速器可能无济于事（您只会增加开销 - 所有这些键仍将转到同一个减速器）。

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

于 2012-06-14T19:57:24.700 回答
0

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

一般来说，我看到几个主要选项：

  • 1-2个reducer——这对于输出量很少的工作很有用，只需要输出几个文件就可以使后期处理更加高效
  • 系统上 95% 的 reduce 槽——这将充分利用您的集群来处理中型和大型 MapReduce 作业。您想使用 95%，这样您就不会阻止较小的工作完成。
  • 系统上 190% 的 reduce 槽——这仅适用于非常大的作业，不需要太频繁地使用。

增加减速器的数量只会有很大帮助。在数学意义上，假设您的所有密钥都是均匀分布的，除了hotkey. 然后，给定的减速器分布hotkey是 100MB，其他一切都是 100MB（极端）。如果您有两个减速器，则大约有 150MB 的减速器 1 和 50MB 的减速器 2。使用三个减速器，您将拥有 1 个 133MB（100MB + 33MB）的减速器，另外两个 33MB。如果有 100 个 reducer，你会看到一个 101MB，其余的都是 1MB。如您所见，增加减速器的数量并没有太大帮助，但确实有一点帮助。可能还不足以真正将它传播得那么薄。

Hotspots are not going to be a problem for many jobs. The default partitioning behavior is completely reasonable for giving you a relatively even spread.

If you do have a hotspot that you are trying to squash or a very skewed data set, you can write a custom partitioner to write special rules for which reducer the data goes to. For example, if you know you have three keys that are hot spots, you can write a partitioner that sends key1 to reducer 1, key2 to reducer 2, key3 to reducer 3, then sends everything else to other reducers.

于 2012-06-14T20:03:42.950 回答