hadoop - 已经分区的输入数据能否改进 hadoop 处理？

Question

我知道在 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

根据我的阅读，我可以使用一个流式作业和两个映射器，每个映射器将吸入两个文件之一，而不是整个文件。这是真的吗？

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

是否可以禁用 Mapper 输出键的排序和分区，让它们自由地飞向 reducer？

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

Answer 1

虽然对于上面显示的文件您将获得 2 个映射器，但不能保证总是如此。映射器的数量取决于从输入数据创建的 InputSplits 的数量。如果您的文件很大，您可能有多个映射器。

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

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

HTH