2

我知道在 mapper 和 reducer 之间的中间步骤中，hadoop 会在到达 reducer 的途中对数据进行排序和分区。

由于我正在处理映射器输入中已经分区的数据，有没有办法利用它并可能加速中间处理，因此不会再进行排序或分组？

添加一些细节：

当我在 S3 上存储数据时，假设我的存储桶中只有两个文件。第一个文件将存储用户 id 的下半部分的记录，另一个文件将存储用户 id 的上半部分的值。每个文件中的数据不一定要排序，但可以保证与用户相关的所有数据都位于同一个文件中。

如：

\mybucket\file1
\mybucket\file2

File1 content:
User1,ValueX
User3,ValueY
User1,ValueZ
User1,ValueAZ

File2 content:
User9,ValueD
User7,ValueB
User7,ValueD
User8,ValueB

根据我的阅读，我可以使用一个流式作业和两个映射器，每个映射器都会吸收两个文件中的一个，但会吸收整个文件。这是真的？

接下来，假设映射器只会输出一个唯一的 Key 一次，关联的值是该 Key 的出现次数。（我意识到这更像是一个减速器的责任，但只是为了我们这里的例子）

是否可以禁用 Mapper 中这些输出键的排序和分区，并让它们自由飞到减速器？

或者再举一个例子：想象一下我所有的输入数据只包含每个唯一键的一行，我不需要在 reducer 的最终输出中对这些数据进行排序。我只想散列每个键的值。我可以在减速器之前禁用该排序和分区步骤吗？

4

1 回答 1

0

尽管对于上面显示的文件，您将获得 2 个映射器，但不能保证始终如此。映射器的数量取决于从输入数据创建的 InputSplit 的数量。如果您的文件很大，您可能拥有多个映射器。

分区只是一种告诉哪个键/值去哪个reducer的方法。如果禁用它，那么您要么需要其他方法来执行此操作，否则最终会导致性能下降，因为减速器的输入将是不均匀的。一个特定的减速器可能会获得所有输入，或者一个特定的减速器可能会获得零输入。我在这里看不到任何性能提升。当然，如果您认为您的自定义分区器更适合这种情况，您绝对可以这样做。但是跳过分区对我来说听起来不合逻辑。默认的分区行为取决于它hash本身。在映射器发出其输出键后，将对其进行哈希处理，以找出哪一组键/值对进入哪个减速器。

如果您的数据已经排序并且您想跳过 MR 作业中的排序阶段，您可能会发现为响应此JIRA提供的补丁很有用。问题尚未结束，但它肯定会帮助您入门。

高温高压

于 2013-06-25T22:31:28.827 回答