hadoop - MapReduce:Map-only 还是 Reduce-only？

Question

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

我看到了两种可能的方法来使用类似 Hadoop 的东西来设置这个作业(也许还有更多):

1. Map-only:我们按组归档文件，因此拆分和后续映射是在组级别完成的。由于每个 map 作业都有整个组，它可以自己进行处理，我们不需要 reduce 作业。但是我看到这个解决方案有几个问题。首先，由于文件最多可以存在于 3 个组中，因此除了 Hadoop 的复制因子之外，按组归档可能会导致我们的存储开销增加三倍。此外，像这样归档数据会降低它在以不同方式处理文件的其他应用程序中的可用性。

2. Reduce-only:据我了解，这种范式意味着一个简单的“身份”映射器和一个数据密集型缩减器。在此解决方案中，文件将无序存储在磁盘上，映射器将接收一组文件进行处理。映射器然后将文件读入内存(至少是它的头信息)以确定它属于哪个组，然后发出(组，文件)对以减少。然后，reducer 将负责处理这些组。但是，我担心走这条路我们可能会失去数据局部性的优势，或者因数据流量过大而使网络陷入困境。

两种方法都有效吗？如果是这样，那将是首选？具体来说，我觉得我非常了解 Map-only 解决方案的优缺点，但不是 Reduce-only 的优缺点。我不确定“本地数据”如何减少作业，或者在 reduce task 中执行“繁重的工作”是否被认为是不好的做法。

Answer 1

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