input - MapReduce 中输入分割的主要原因是什么？

Question

在 MapReduce papers描述了输入文件被划分为M个输入分割。我知道 Hadoop 中的 HDFS 自动分区为 64 MB 的 block (默认)，然后将这些 block 复制到集群中的其他几个节点以提供容错能力。我想知道 HDFS 中的文件分区是否意味着上述 MapReduce 论文中描述的输入拆分。容错能力是这种 split 的单一原因还是有更重要的原因？

如果我在没有分布式文件系统的节点集群上使用 MapReduce(数据仅位于具有通用文件系统的本地磁盘上)，会怎样？我需要在映射阶段之前分割本地磁盘上的输入文件吗？

感谢您的回答。

Answer 1

想添加一些缺失的概念(这对我来说很困惑)

<小时/><小时/>

HDFS

文件存储为 block (故障/节点容错)。 block 大小(64MB-128MB)64MB。因此文件被分为 block ， block 存储在集群上的不同节点上。正在通过复制因子(默认=3)复制 block 。

映射缩减

已经存储在HDFS中的文件在逻辑上被分为INPUT-SPLITS。分割大小可以由用户设置

Property name           Type   Default value

<小时/>

mapred.min.split.size   int     1
mapred.max.split.sizea  long    Long.MAX_VALUE.

然后通过以下公式计算分割大小:

ma​​x(minimumSize, min(maximumSize, blockSize))

注意::拆分是合乎逻辑的

<小时/><小时/>

希望现在能回答您的问题

 I'd like to know if this partitioning of files in HDFS means the input splitting described in mentioned MapReduce papers. 

不，HDFS block 和 Map-Reduce 分割并不是一回事。

Is fault tolerance single reason of this splitting or are there more important reasons?

不，分布式计算才是原因。

And what if I have MapReduce over cluster of nodes without distributed file system (data only on local disks with common file sytem)? Do I need to split input files on local disk before map phase?

在你的情况下，我猜，是的，你将必须分割映射阶段的输入文件，并且你还必须分割中间输出(来自映射器)以进行减少阶段。其他问题:数据一致性、容错、数据丢失(在hadoop中=1%)。

Map-Reduce 是为分布式计算而设计的，因此在非分布式环境中使用 Map-Reduce 没有什么用处。

谢谢