Hadoop 递归映射答案

【问题标题】：Hadoop Recursive MapHadoop 递归映射
【发布时间】：2011-02-10 07:02:07
【问题描述】：

我要求我的映射器在某些情况下可以生成一个新的键/值供另一个映射器处理。有没有理智的方法可以做到这一点？我考虑过编写自己的自定义输入格式（队列？）来实现这一点。有任何想法吗？谢谢！

编辑：我应该澄清一下

方法一

地图步骤 1 (foo1, bar1) -> out1 (foo2, bar2) -> out2 (foo3, bar3) -> (fooA, barA), (fooB, barB) (foo4, bar4) -> (fooC, barC) 减少步骤 1： (out1) -> 好的 (out2) -> 好的 ((fooA, barA), (fooB, barB)) -> 创建地图第 2 步 ((fooC, barC)) -> 也将其发送到地图步骤 2 地图步骤 2： (fooA, barA) -> out3 (fooB, barB) -> (fooD, barD) (fooC, barC) -> out4 减少步骤 2： (out3) -> 好的 ((fooD, barD)) -> 创建地图第 3 步 (out4) -> 好的地图步骤 3：（食物，酒吧）-> out5 减少步骤 3： (out5) -> 好的 - 没有更多的地图步骤。完成的 -

所以它是完全递归的。一些键/值发出输出以减少，一些生成新的键/值进行映射。我真的不知道在给定的运行中我可能会遇到多少 Map 或 Reduction 步骤。

方法二

地图步骤 1 (foo1, bar1) -> out1 (foo2, bar2) -> out2 (foo3, bar3) -> (fooA, barA), (fooB, barB) (foo4, bar4) -> (fooC, barC) (fooA, barA) -> out3 (fooB, barB) -> (fooD, barD) (fooC, barC) -> out4 （食物，酒吧）-> out5 减少步骤 1： (out1) -> 好的 (out2) -> 好的 (out3) -> 好的 (out4) -> 好的 (out5) -> 好的

这个方法会让映射器提供它自己的输入列表。我不确定最终哪种方式更容易实现。

【问题讨论】：

我是否理解正确，不同的输入具有不同的 MR 处理深度？有的需要一个 MR 处理，有的需要链？
是的，完全正确。一个很好的类比是递归目录列表。映射器将获取一个目录，并发出文件。如果我点击另一个目录，我会将其反馈给映射器。
等等，我认为这更像是相反的方式。我的意思是说它类似于一个获取文件并发出它们的映射器。如果其中一个文件恰好是一个目录，它将读取目录的内容，并将每个文件反馈给映射器。

标签： java hadoop mapreduce

【解决方案1】：

通过 Hadoop 进行递归的“方法 1”方式强制您通过 Map 和 reduce 运行每个“递归深度”的完整数据集。这意味着您必须确定这会影响多深，并且您将遭受巨大的性能影响。

你能肯定地说递归深度是有限的吗？

如果是这样，那么我肯定会选择“方法 2”，并以在一次映射器调用中执行所需递归的方式实际构建映射器。它更简单，可以节省大量性能。

【讨论】：

是的，我可以肯定地说递归深度是有限的。我自己更倾向于 Method2 风格。当映射器需要发出更多的映射器输入时，它的计算成本非常高。我想如果我只是递归地提供完全相同的映射器输入，我不会有很好的负载平衡。但我同意 100% 更简单 = 更好
根据使用 Hadoop 的经验，我可以说很多 CPU 时间（我的意思是很多）都用于读取和写入记录。您的“方法 1”执行 3 个 Map-Reduce 步骤，这些步骤必须一遍又一遍地读取和写入所有数据（注意：仅限于需要转到最新步骤的记录是“困难的）。没有实际测试它我'我真的很确定“方法 2”的时间至少是“方法 1”的 3 倍，并且更难实施。就我的 2ct。

【解决方案2】：

使用 oozie [网格工作流定义语言] 将两个 M/R 作业串在一起，第一个只有映射器。 http://yahoo.github.com/oozie

【讨论】：

我可能应该提到我正在使用 Amazon Elastic MapReduce。他们还不支持 oozie :( 但它似乎是一个非常有趣的框架。我没有深入了解文档以查看是否真的可以从中获得递归行为，但我绝对会保留它在雷达上。

【解决方案3】：

据我所知，Hadoop MR 框架在工作开始时正在计划应该执行哪些地图任务，并且还没有准备好让新地图任务动态出现。
我会建议两种可能的解决方案： a）如果您在映射阶段发出另一对 - 将它们馈送到同一个映射器。因此，mapper 将采用其通常的参数，并在处理后查看某种内部本地队列以处理其他对。如果有少量的次要对，它会很好用，并且数据局部性并不那么重要。
b) 如果您确实在处理目录或类似的东西 - 您可以迭代作业包主中的结构，并立即构建您需要的所有拆分。

【讨论】：

是的，我必须恨自己，因为我似乎总是想以非设计的方式使用 MR！好的，所以我考虑过这种方法。在大多数情况下，我希望我需要发出很多对（100 或更少）。虽然在某些情况下，我将不得不发射到数千对。因此，如果有某种方法可以让 Hadoop 选择将我的配对发送到哪里（而不是我的映射器自己提供），我会更好。
我认为这取决于每对的处理成本。可能数千对对于本地映射器来说不是问题。我建议衡量本地映射器处理的影响。
@DavidGruzman 你怎么做 a) 部分？ -> '将它们提供给同一个映射器'。这似乎是一个绝妙的主意！