我有大约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来说这是一个很好的问题，但这是一个糟糕的解决方案吗？提前感谢任何见解。
答案 0 :(得分：0)
对我来说，这听起来像是在尝试不必要地添加减速器。假设N足够大，我会尝试以下方法：将每个区域（整个数据集的1 / N）插入映射器并计算那里的互相关矩阵。由于此处的reducer实际上并不是必需的，因此可以完全忽略它并直接写出map-phase的结果。在MapReduce中，繁重的提升通常在地图阶段进行，在这种情况下，如果你只是在寻找M个互相关矩阵，那么听起来似乎并不需要减速器。
我认为，一般来说，某些Map任务处理的数据可能位于同一节点上。但是Reduce任务也是如此吗？
通常，reduce任务需要将数据（即map任务的结果）传递给它们才能对它们进行操作。最好在将数据传递给reducer之前尽可能地压缩数据，以最大限度地减少网络流量。