2

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

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

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

  2. Reduce-only：据我了解，这种范式意味着一个简单的“身份”映射器和一个数据密集型化简器。在这个解决方案中，文件将无序地存储在磁盘上，并且映射器将接收一组要处理的文件。然后映射器将文件读入内存（至少是它的头信息）以确定它属于哪些组，然后发出要减少的（组，文件）对。然后，reducer 将负责处理这些组。然而，我担心我们可能会失去数据本地化的好处，或者通过这条路线让网络因过多的数据流量而陷入困境。

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

4

2 回答 2

0

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

但是，效率严格取决于必须执行的计算。计算是什么？进一步来说：

  1. 你能一起处理一个组的元素的一个子集吗？如果是这种情况，您可以使用组合器来大大减少网络流量。

  2. 你能想到不同的团体组织吗？

于 2012-12-02T18:48:05.210 回答
0

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

于 2012-12-02T22:38:17.233 回答