Hadoop技术疑问：小文件增节点是否提速？分片理解是否正确？

嘿，我来帮你把这两个Hadoop的疑问理清楚～

问题1：待处理文件小于64M时，增加集群节点数量是否会影响处理速度？ #

不会有明显的速度提升，甚至可以说基本没影响。原因在于Hadoop默认的split size和block size（这里是64M）是一致的，当文件小于64M时，整个文件只会被划分为一个split。而MapReduce的Map任务数量是由split数量决定的，所以只会启动一个Map任务来处理这个文件。

不管你把集群节点从1加到多少，这个唯一的Map任务只会运行在某一个节点上，其他节点根本没机会参与这个文件的处理。额外的节点不仅帮不上忙，甚至可能因为集群调度的微小 overhead 带来一点点不必要的消耗，但整体处理速度不会有提升。

问题2：关于文件分片与节点处理的理解是否正确？ #

你的理解大部分是对的，但有一个小细节需要修正：

• 对于小于64M的文件：完全正确，不管节点数从1增至6，都只有单个节点上的一个Map任务在处理，速度不会有任何提升。
• 对于128M的文件：它会被拆分为2个64M的split，对应2个Map任务，可以分配给2个不同的节点并行处理，这时候速度确实比单节点快。但你说“节点数超3个后速度不再提升”是不准确的——实际上当节点数≥2的时候，速度的提升就已经达到上限了。因为总共只有2个Map任务，最多只能占用2个节点的资源，哪怕你有10个节点，剩下的节点也不会参与这个任务的Map阶段。只有当Reduce阶段存在较大开销，且Reduce任务数量可以利用更多节点时，才可能有进一步的提升，但如果是纯Map型任务，节点数超过2就不会再提速了。

内容的提问来源于stack exchange，提问作者Menkot