BlockSize与大数据

Question

每个人都知道Hadoop对小文件的处理很差，因为它必须使用映射器的数量。但是大文件呢，它比块大小稍微大一点。

例如，假设hdfs块大小为128 an，hadoop接收126 an至130 an之间的文件。

126 to和128 to之间的文件适合存储在hadoop中，但是对于129 to 130 to的文件，hadoop需要2个映射器才能读取这些文件吗？如何在hadoop中处理这个问题，以克服hdfs块更大的事实？

(预先谢谢:)

Answer 1

一旦你越过128 you边界，你需要第二个街区。

例如，文件130 as将显示为两个块:第一个128块和第二个文件其余部分

HDFS用于处理大型文件。假设您有一个1000 say文件。使用4k块大小，您必须发出256,000个请求才能获得该文件(每个块1个请求)。在HDFS中，这些请求会穿越网络并带来大量开销。每个请求都必须由名称节点处理，以确定在哪里可以找到该块。交通太拥挤了！如果使用64 16块，请求的数量将减少到16次，大大降低了节点名称的开销和加载成本。

Answer 2

我认为您对HDFS和mapreduce之间的关系有一个误解。HDFS是底层文件系统，mapreduce是计算框架。HDFS本身根本不使用mapreduce框架来进行操作。Mapreduce作业使用HDFS作为文件系统，用于查找它的jars、编写临时处理数据、将文件拉到处理中或任何其他文件操作。映射器/还原器的数量是在作业提交时设置的，由提交作业的mapreduce客户端决定。

如果有一个500 map的文件被分割成4个128 map的块，并且希望运行一个word count mapreduce作业，该作业读取一个文件并输出每个出现的单词的计数，然后使用4个映射器和2个减法器运行它，那么每个映射任务都将处理4x128MB块中的一个。作业将与HDFS namenode对话以请求文件，namenode将响应构建文件所需的所有块，并给出块的位置。映射阶段将从它们的数据节点读取这些文件，并在处理后生成4个文件(例如，part 0000、part 0001、part 0002、part 0003)，减少阶段将对每个文件中的单词进行排序和汇总，并给出它的最终输出。

，您不需要仅仅因为您的文件大于块大小而使块更大。这违背了分布式文件系统或现有任何文件系统的目的。HDFS (以及我使用过的所有文件系统)可以有一个8GB文件--它仍然会将其分解为128 an块，或者您设置的块大小。