-1

我有大约 100TB 的数据，其中每个数据（元素）的大小约为 1MB。我也有 N 个区域，由从数据中提取的 M 个元素组成。每个元素最多出现在 3 个区域中。一个区域内的 M 个元素必须互相关成一个 MxM 相关矩阵。我不确定 M 的平均大小，但它可以从小到 5 到大到几百不等。

在我们当前的实现中，我们产生线程来处理每个区域，并通过 NFS 读取文件来获取单个元素。事实证明，该解决方案受 I/O 限制，我们现在正在研究将数据和计算一起分布的方法。乍一看，MapReduce 似乎很适合这个问题，但我对范式还不够熟悉，无法确定。

假设我选择了 Hadoop。我的第一个想法是将数据作为块放入 HDFS，尝试使每个块尽可能地由来自同一区域的元素组成。然后每个 Map 任务将被赋予一组元素并发出（区域，元素）对。然后每个 Reduce 任务将获取一个区域的所有元素并执行互相关。但是，当然，我不确定这种直观的，也许是幼稚的方法是否是 MapReduce 的合理使用。

一方面，我不确定这里的数据/计算位置。我认为，一般来说，某些 Map 任务正在处理的数据很可能位于同一个节点上。但对于 Reduce 任务也是如此吗？

例如，如果我从我的 Map 任务中发出一个指向文件中某个位置的值，那么 Reduce 任务在同一节点上运行的机会是否很大？在 Map 阶段将数据读入内存，然后以某种序列化形式发出 1MB 元素会更好吗？这不会导致 RAM 中的所有 100TB 数据或复制到中间文件吗？

那么，这是 MapReduce 的一个很好的候选者，还是我应该在别处寻找解决方案？这对 MapReduce 来说是一个好问题，但却是一个糟糕的解决方案吗？提前感谢您的任何见解。

4

1 回答 1

0

对我来说，这听起来像是你试图不必要地添加减速器。假设 N 足够大，我会尝试以下操作：将每个区域（整个数据集的 1/N）插入映射器并在那里计算互相关矩阵。由于这里的 reducer 实际上并不是必需的，因此您可以完全忽略它并直接写出 map-phase 的结果。在 MapReduce 中，繁重的工作通常是在 map 阶段完成的，在这种情况下，如果您只寻找 M 个互相关矩阵，听起来就不需要 reducer。

我认为，一般来说，某些 Map 任务正在处理的数据很可能位于同一个节点上。但对于 Reduce 任务也是如此吗？

一般reduce任务需要将数据（即map任务的结果）传递给它们，然后才能对其进行操作。在将数据传递给减速器之前尽可能地压缩数据以最小化网络流量是一个好主意。

于 2012-12-02T06:15:57.653 回答