在我的问题中，我有100 TB的数据要处理。这个数据集中的每个文件大约有1mb，可以属于我们定义的10000多个不同“组”中的3个。每个文件组都需要一起处理，一个组中可以有几个到几百个文件。因为我们有数以万计这样的小组，我们认为这是一个很好的候选人mapreduce。
我看到了两种可能的方法来使用hadoop之类的工具设置此作业（可能还有更多）：
仅Map：我们按组归档文件，因此拆分和后续Map是在组级别完成的。因为每个map作业都有整个组，所以它可以自己进行处理，我们不需要reduce作业。但我发现这个解决方案有几个问题。首先，由于文件最多可以存在于3个组中，因此按组归档可能会导致存储开销增加三倍，此外还有hadoop的复制因子。此外，像这样归档数据会使它在其他处理不同文件的应用程序中的可用性降低。
reduce only：据我所知，这个范例意味着一个简单的“身份”Map器和一个数据密集型的reducer。在这个解决方案中，文件将无序地存储在磁盘上，Map程序将接收一组要处理的文件。然后Map程序将文件读入内存（至少是它的头信息），以确定它属于哪些组，然后发出（组，文件）对进行缩减。然后，减速机将负责处理这些组。然而，我担心走这条路可能会失去数据局部性的好处，或者让网络陷入太多数据流量的泥潭。
两种方法都有效吗？如果是的话，哪一个会更好？具体地说，我觉得我非常了解map-only解决方案的优缺点，但不是reduce-only。我不确定“数据本地”reduce jobs是什么，或者在reduce任务中做“繁重的工作”是否被认为是不好的做法。