我知道在mapper和reducer之间的中间步骤中，hadoop会在到减速器的路上对数据进行排序和分区。
由于我在输入映射器时处理已经分区的数据，是否有办法利用它并可能加速中间处理，因此不再进行排序或分组？
添加一些细节：
当我在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
根据我的阅读，我可以使用流媒体作业和两个映射器，每个映射器将吸入两个文件中的一个，但整个文件。这是真的吗？
接着， 假设映射器只输出一次唯一的密钥，相关的值是该密钥的出现次数。 （我意识到它更多是减速器的责任，但仅仅是我们这里的例子）
是否可以禁用Mapper对这些输出键的排序和分区，让它们自由地飞向reducer？
或者举另一个例子： 想象一下，我的所有输入数据只包含每个唯一键的一行，我不需要在reducer的最终输出中对这些数据进行排序。我只想为每个键哈希值。我可以在reducer之前禁用那个排序和分区步骤吗？
答案 0 :(得分：0)
虽然对于上面显示的文件，您将获得2个映射器，但始终无法保证。映射器的数量取决于从输入数据创建的InputSplits的数量。如果你的文件很大，你可能有多个地图制作者。
分区只是一种告诉哪个键/值到哪个reducer的方法。如果你禁用它，那么你需要一些其他方法来做到这一点，否则你最终会降低性能，因为减速器的输入将是不均衡的。特定的reducer可能会获得所有输入，或者特定的reducer可能会获得零输入。我在这里看不到任何性能提升。当然，如果您认为您的自定义分区程序更适合这种情况，那么您肯定可以这样做。但跳过分区对我来说听起来不合逻辑。默认分区行为取决于hash本身。在映射器发出其输出键之后进行散列以找出哪组键/值对转到哪个reducer。
如果您的数据已经排序并且您想跳过MR作业中的排序阶段，您可能会发现响应此JIRA提供的补丁非常有用。问题尚未结束，但它肯定会帮助您入门。
HTH