在我的问题中，我有100TB的数据需要处理。此数据集中的每个文件大约为1MB，并且可以属于我们定义的10,000多个不同“组”中的3个。每组文件需要一起处理，并且组中可以有几个到几百个文件。由于我们有成千上万个这样的群体，我们认为这是MapReduce的一个很好的候选者。
我看到两种可能的方法来设置这项工作（可能还有更多），例如Hadoop：
仅限地图：我们按组归档文件，因此拆分和后续映射是在组级别完成的。由于每个地图作业都有整个组，因此它可以自行进行处理，而且我们不需要减少作业。但我发现这个解决方案存在一些问题。首先，由于文件最多可以存在3个组，因此除了Hadoop的复制因素之外，按组进行归档可能会导致存储开销增加三倍。此外，对这些数据进行归档会降低其在使用不同文件的其他应用程序中的可用性。
仅限降级：据我了解，此范例意味着一个简单的“身份”映射器和一个数据密集型的reducer。在此解决方案中，文件将无序存储在磁盘上，映射器将接收一组要处理的文件。然后映射器将文件读入内存（至少其标题信息）以确定它属于哪些组，然后发出（组，文件）对以减少。然后减速器负责处理组。但是，我担心我们可能会失去数据局部性的好处，或者通过这条路线使数据流量过多而使网络陷入困境。
这两种方法都有效吗？如果是这样，哪个会更受欢迎？具体来说，我觉得我非常了解Map-only解决方案的优缺点，但不是Reduce-only。我不确定“本地数据”如何减少工作量，或者如果在减少任务中执行“繁重工作”被认为是不好的做法。
答案 0 :(得分：0)
两种方法似乎都有效。我想最好的办法是尝试两者。 但是，对于在Hadoop中实现的Map Reduce作业，“Reduce-only”版本似乎更典型，因为框架本身将负责对文件进行分组。
然而，效率严格依赖于必须执行的计算。什么是计算？更具体地说：
您可以一起处理组的元素子集吗？如果是这种情况，您可以使用组合器大大减少网络流量。
你能想到这些团体的不同组织吗？
答案 1 :(得分：0)
出于性能原因，我建议选择仅限映射解决方案而不是仅降低解决方案。
在我的理解中，通过改组机制传递数据是非常计算密集的。它加载CPU（序列化），磁盘（因为所有数据至少存储在磁盘上一次）和网络 - 来传递数据。
在我的估计中，通过非本地HDFS文件加载数据，改组的费用要贵几倍。
考虑到您的数据大小，并考虑到在洗牌过程中数据将增长（由于序列化开销），我还会考虑仅映射解决方案，以避免磁盘空间不足。