MapReduce: Map-only 还是 Reduce-only？答案

【问题标题】：MapReduce: Map-only or Reduce-only?MapReduce: Map-only 还是 Reduce-only？
【发布时间】：2012-12-02 18:34:14
【问题描述】：

在我的问题中，我有 100TB 的数据要处理。该数据集中的每个文件大约为 1MB，最多可以属于我们定义的 10,000 多个不同“组”中的 3 个。每组文件都需要一起处理，一个组中可以有几个到几百个文件。由于我们有成千上万个这样的组，我们认为这是 MapReduce 的一个很好的候选者。

我看到了两种可能的方法来设置这项工作（也许还有更多），比如 Hadoop：

仅映射：我们按组归档文件，因此拆分和后续映射在组级别完成。由于每个 map 作业都有整个组，它可以自己处理，我们不需要 reduce 作业。但我看到这个解决方案存在一些问题。首先，由于文件最多可以存在 3 个组中，因此除 Hadoop 的复制因子外，按组归档可能会导致我们的存储开销增加三倍。此外，像这样归档数据会降低其在以不同方式处理文件的其他应用程序中的可用性。
Reduce-only：据我了解，这种范式意味着一个简单的“身份”映射器和一个数据密集型化简器。在这个解决方案中，文件将无序地存储在磁盘上，并且映射器将接收一组要处理的文件。然后映射器将文件读入内存（至少是它的头信息）以确定它属于哪些组，然后发出要减少的（组，文件）对。然后，reducer 将负责处理这些组。但是，我担心走这条路可能会失去数据本地化的好处，或者由于过多的数据流量而使网络陷入困境。

这两种方法都有效吗？如果是这样，哪个会更受欢迎？具体来说，我觉得我非常了解 Map-only 解决方案的优缺点，但不是 Reduce-only。我不确定“本地数据”reduce 作业是怎样的，或者在 reduce 任务中执行“繁重”任务是否被认为是不好的做法。

【问题讨论】：

同样的问题，最后你选择了哪种方式？

标签： hadoop mapreduce hdfs

【解决方案1】：

出于性能原因，我建议选择仅映射解决方案而不是仅减少解决方案。
据我了解，通过改组机制传递数据的计算量非常大。它同时加载 CPU（序列化）、磁盘（因为所有数据都至少存储在磁盘上一次）和网络 - 以传递数据。
在我的估计中，改组比通过非本地 HDFS 文件加载数据要贵几倍。
考虑到您的数据大小，并考虑到在洗牌期间数据会增长（由于序列化开销），我还会考虑仅映射解决方案，以免超出磁盘空间。

【讨论】：

太棒了，这肯定回答了我关于将数据处理卸载到减速器的成本的问题。听起来，一般来说，您想尝试在映射器中完成大部分工作，对吗？
没错。我总是喜欢在映射器上执行大部分工作，并尽量减少传递给减速器的数据。

【解决方案2】：

这两种方法似乎都有效。我想最好的办法是两者都尝试。但是，在我看来，“仅 Reduce”版本对于在 Hadoop 中实现的 Map Reduce 作业更为典型，因为框架本身将负责对文件进行分组。

但是，效率严格取决于必须执行的计算。计算是什么？更具体地说：

您能同时处理组中元素的子集吗？如果是这种情况，您可以使用组合器来大大减少网络流量。
你能想出不同的团体组织吗？

【讨论】：

我们实际上总共有超过 10,000 个组，但每个文件最多可以分为 3 个组（即这些组不是数据的分区，存在一些重叠）。所以理论上我们可以一次处理所有超过 10,000 个组。在这种情况下执行的计算是波形数据的互相关，因此我们可以沿着相关矩阵的对角线进一步划分组。
组合器听起来很有趣，但我对函数式编程还不够熟悉，无法了解如何应用它来减少网络流量。你能详细说明一下吗？感谢您的帮助！
嗯，在 Hadoop 中，每个映射器都分配了至少等于单个文件或文件块的工作量，遵循数据局部性原则。组合器是一个后映射器函数，它在给定节点上的映射器输出的对上执行。这是一种就地减少操作（通常）减少传输的数据量，因为它是在减少操作减少数据大小的假设下就地（在内存中）完成的。在此处查看有关 wourdcount 组合器的示例：wiki.apache.org/hadoop/HadoopMapReduce
啊，有道理。不幸的是，对于这个应用程序，即使我创建了偏相关矩阵，即使组中的一个元素丢失，我仍然需要保留数据。但绝对要记住这一点，谢谢。