在不同的机器组上运行 Mappers 和 Reducers答案

【问题标题】：Running Mappers and Reducers on different Groups of machines在不同的机器组上运行 Mappers 和 Reducers
【发布时间】：2014-05-26 08:33:18
【问题描述】：

我们有一个不错的、大型的、复杂的 elastic-mapreduce 作业，它对 Mapper、Collector 和 Reducer 的硬件限制大相径庭。

问题是：对于映射器，我们需要大量的轻量级机器来并行运行多个映射器（一切都很好）；收集器更需要内存，但给他们每个 6GB 的峰值堆应该还是可以的。 . .但是，问题是减速器。当其中一个启动时，它将占用大约 32-64GB 的空间进行处理。

结果我们得到一个循环类型的任务死亡，因为一个盒子的全部内存被消耗了，这导致一个映射器和减速器都在其他地方重新启动。

最简单的方法是，如果我们能以某种方式指定一种方法，让 reducer 在不同的“组”（少数几个巨大的盒子）上运行，同时让映射器/收集器在较小的盒子上运行。这也可以显着节省成本，因为我们真的不应该根据减速器的需求来调整映射器运行的节点。

另一种方法是“分解”作业，以便有一个可以旋转的第二个集群来处理映射器收集器的输出——但是，这显然是“次优的”。

所以，问题是：

有没有办法指定映射器或化简器将要“分组”的内容在 Elastic MapReduce 和/或 Hadoop 上运行？
有没有办法阻止减速器在所有映射器完成之前启动？
是否有人对如何解决此问题有其他想法？

干杯！

【问题讨论】：

选项 2 是。您可以让 reducer 等到整个映射阶段完成。
关于如何实现这一点的任何提示？

标签： hadoop amazon-web-services elastic-map-reduce mapper reducers

【解决方案1】：

在 Hadoop MapReduce 作业期间，Reducers 会在所有 Mapper 完成后开始运行。 Map 阶段的输出在分区发生之前被打乱和排序，以决定哪个 Reducer 接收哪些数据。因此，Reducers 在 Shuffle/Sort 阶段结束后（映射器完成后）开始运行。

【讨论】：

似乎不是这样：linkmapred.reduce.slowstart.completed.maps The amount of maps tasks that should complete before reduce tasks are attempted. Not waiting long enough may cause “Too many fetch-failure” errors in attempts. 但是，我发现我们正在尝试的东西有细微差别——Combiner，尽管它作为 Mapper 任务的一部分运行/内存，作为 Reducer 的日志——这就是我们现在正在研究的部分。
@David mapred.reduce.slowstart.completed.maps 表示在 Reduce 阶段开始之前应达到的阈值。需要注意的是，Reduce 阶段进一步由 3 个步骤组成：shuffle、sort 和 reduce。 shuffle 步骤可以在所有 Mapper 完成之前开始，因为它意味着通过网络将数据发送到潜在的 Reducer。然而，排序和归约步骤仅在所有映射器完成后才开始。至于使用组合器，您应该谨慎，因为它可能会产生一些间接成本。仅在必要时使用它，您的工作不应该依赖它。
感谢您提供更多信息。我们已经设法通过使用它来解决它 - 所以一项工作有效。我们的另一项工作也有类似的问题——但对于映射器：每个映射器都必须加载一个 AI，这需要大约 32GB-48GB 的 RAM 才能运行。我们真正需要做的是能够限制映射器，以便每个节点一次运行不超过一个（看起来每个节点运行 8 个（大概 1 个/核心））。那么，有没有办法将运行 per node 的映射器限制为一个特定的数字（在我们的例子中是 1（尽管我们会使其可配置）。
@DavidBeveridge 我认为您要做的是将 mapred.tasktracker.map.tasks.maximum 设置为 1。
是的！事实证明，问题在于 EC2 覆盖/忽略了我们在作业中的设置（我们的设置会显示在日志中，但直到我们直接更改 .xml 文件，任何更改才会生效）。谢谢你的帮助。哦，顺便说一句，我们发现了不对称机器的技巧——当 Reducer 完成时，原始作业类在 Master 本身上启动另一个进程——我们可以把它变成一个巨大的机器（i2.4xl 或类似的），但要保持工人适度（m2.4xl）。