我正在阅读原始的MapReduce论文。我的理解是，当处理数百GB的数据时，传输如此多数据的网络带宽可能是MapReduce作业的瓶颈。对于映射任务，我们可以通过在已经包含任何给定拆分数据的工作线程上调度映射任务来减少网络带宽，因为从本地磁盘读取不需要网络带宽。
然而，洗牌阶段似乎是一个巨大的瓶颈。归约任务可能会从所有映射任务接收中间键/值对，并且几乎所有这些中间键/值对都将通过网络进行流式传输。
当处理数百GB或更多的数据时，是否有必要使用组合器来获得高效的MapReduce作业？
组合器起着重要作用，如果它可以适应这种情况，它就像一个本地化简器，所以它不会发送所有数据，而是只发送几个值或局部聚合值，但组合器不能在所有情况下都应用。
如果归约函数既是可交换的又是关联的，那么它可以用作合路器。
就像在中位数的情况下一样，它不起作用.
组合器不能在所有情况下使用。
还有其他参数可以调整，例如：
当映射发出输出时，它直接不会进入磁盘，它会进入 100 MB 循环缓冲区，当填充 80% 时，它会将记录溢出到磁盘中。
因此，您可以增加缓冲区大小并增加脱粒保持值，在这种情况下溢出会更少。
如果有这么多溢出，那么溢出将合并为一个我们可以玩溢出因子的文件。
有一些线程将数据从本地磁盘复制到化简器 jvm，以便可以增加它们的数量。
压缩可用于中级和最终级。
因此，Combiner不是唯一的解决方案，也不会在所有情况下使用。
假设映射器正在发出（单词，计数）。如果你不使用组合器，那么如果映射器有单词abc100次，那么化简器必须拉（abc，1）100次假设（单词，计数）的大小是7个字节。如果没有合并器，化简器必须拉取7*100字节的数据，而作为合路器，化简器只需要拉动7字节的数据。此示例仅说明合并器如何减少网络流量。注意：这是一个模糊的例子，只是为了使理解更简单。