我知道默认的块大小是64M，分割是64M， 那么对于小于64M的文件，当节点数从1增加到6时，只有一个节点要做拆分，所以速度不会提高？是对的吗？ 如果它是一个128M的文件，那么将有2个节点与2个分割相关，速度快于1个节点，如果有超过3个节点，速度不会增加，是吗？
我不知道我的理解是否正确。谢谢你的评论！
答案 0 :(得分：0)
您假设一个大文件可以拆分开头，但情况并非如此。
如果您的文件小于块大小，添加更多节点将永远不会增加处理时间，它只会有助于复制和总群集容量。
否则，您的理解似乎是正确的，但我认为最新的默认值实际上是128 MB，而不是64
答案 1 :(得分：0)
以下是您的查询的答案
我知道默认的块大小是64M，
在hadoop版本1.0中，默认大小为64MB，在版本2.0中，默认大小为128MB。通过在配置文件dfs.block.size中设置参数hdfs-site.xml的值，可以覆盖默认块大小。
拆分为64M，
不必要，因为块大小与分割大小不同。 Read this post更清晰。对于正常的wordcount示例程序，我们可以安全地假设分割大小大约与块大小相同。
那么对于小于64M的文件，当节点数从1增加到6时，只有一个节点与拆分相关，所以速度不会提高？是吗？
是的，你是对的。如果文件大小实际上小于块大小，则它将由一个节点处理，并且将节点从1增加到6可能不会影响执行速度。但是，您必须考虑推测执行的情况。在推测性执行的情况下，即使是较小的文件也可以同时由2个节点处理，从而提高了执行速度。
从Yahoo Dev KB link开始，推测执行解释如下：
推测执行：
Hadoop系统的一个问题是 将任务划分为多个节点，可能会有一些缓慢 节点对程序的其余部分进行速率限制。例如，如果一个节点 有一个慢速磁盘控制器，然后它可能只读取其输入 所有其他节点的速度的10％。所以99个地图任务已经完成了 完成后，系统仍在等待最终的地图任务检查 in，这比其他所有节点都要长得多。
通过强制任务彼此独立运行，个人 任务不知道他们的输入来自何处。任务信任Hadoop 平台，只提供适当的输入。因此，同样的 输入可以多次并行处理，以便利用 机器能力的差异。因为工作中的大部分任务都是 即将结束，Hadoop平台将安排冗余副本 剩下的任务跨越几个没有其他节点的节点 努力工作。此过程称为推测执行。什么时候 任务完成后，他们向JobTracker宣布这一事实。任何 完成任务的副本首先成为最终副本。如果是其他 副本正在推测性地执行，Hadoop告诉TaskTrackers 放弃任务并丢弃他们的产出。然后减速器收到 他们从Mapper成功完成的输入，首先。
默认情况下启用推测执行。你可以禁用 通过设置，为映射器和缩减器的推测执行
mapred.map.tasks.speculative.execution和mapred.reduce.tasks.speculative.executionJobConf选项为false， 分别使用旧API，而对于较新的API，您可以考虑更改mapreduce.map.speculative和mapreduce.reduce.speculative。