在MapReduce papers 中描述了输入文件被划分为 M 个输入拆分。我知道 Hadoop 中的 HDFS 会自动分区为 64 MB（默认）的块，然后将这些块复制到集群中的几个其他节点以提供容错。我想知道 HDFS 中文件的这种分区是否意味着提到的 MapReduce 论文中描述的输入拆分。容错是这种分裂的单一原因还是有更重要的原因？
如果我在没有分布式文件系统的节点集群上使用 MapReduce（数据仅在具有通用文件系统的本地磁盘上）怎么办？我需要在映射阶段之前在本地磁盘上拆分输入文件吗？
感谢您的回答。
【问题讨论】：
想补充一些缺失的概念（ans 让我很困惑）
HDFS
文件存储为块（故障/节点容差）。块大小（64MB-128MB）64MB。所以一个文件被分成块，块存储在集群上的不同节点上。一个块被复制因子复制（默认=3）。
Map-Reduce
已经存储在HDFS中的文件在逻辑上分为INPUT-SPLITS。 分割大小可以由用户设置
Property name Type Default value
mapred.min.split.size int 1
mapred.max.split.sizea long Long.MAX_VALUE.
然后通过公式计算分割大小：
max(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 块和 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?
在您的情况下，我猜，是的，您必须为 Map Phase 拆分输入文件，并且您还必须为 Reduce Phase 拆分中间输出（来自 Mapper）。 其他问题：数据一致性、容错性、数据丢失（在hadoop中=1%）。
Map-Reduce 是为分布式计算而设计的，因此在非分布式环境中使用 Map-Reduce 是没有用的。
谢谢
【讨论】：
I'd like to know if this partitioning of files in HDFS means the input splitting described in mentioned MapReduce papers.
不，MapReduce 中的输入拆分是为了在 reduce 阶段利用多个处理器的计算能力。映射器接收大量数据并将数据拆分为逻辑分区（大多数时间由程序员自定义映射器实现指定）。然后，这些数据会进入各个节点，在这些节点中，称为 reducer 的独立进程会执行数据处理，最后对结果进行整理。
Is fault tolerance single reason of this splitting or are there more important reasons?
不，这不是这样做的唯一原因。您可以将其与文件系统级别的块大小进行比较，以确保将数据传输到块中、按块压缩数据以及分配 I/O 缓冲区。
【讨论】：