HDFS中的数据块大小，为啥是64MB？

Posted 2023-02-16

【中文标题】HDFS中的数据块大小，为啥是64MB？

【英文标题】：data block size in HDFS, why 64MB?HDFS中的数据块大小，为什么是64MB？

【发布时间】：2013-10-28 17:17:25

【问题描述】：

HDFS/Hadoop 的默认数据块大小为 64MB。磁盘中的块大小一般为4KB。

64MB 块大小是什么意思？ ->是不是说从磁盘读取的最小单位是64MB？

如果是，这样做有什么好处？-> 便于连续访问 HDFS 中的大文件？

我们可以使用磁盘的原始 4KB 块大小来做同样的事情吗？

【参考方案1】：

64MB 块大小是什么意思？

块大小是文件系统可以存储的最小数据单元。如果您存储一个 1k 或 60Mb 的文件，它将占用一个块。一旦你越过 64Mb 的边界，你就需要第二个块。

如果是，这样做有什么好处？

HDFS 旨在处理大文件。假设您有一个 1000Mb 的文件。对于 4k 块大小，您必须发出 256,000 个请求才能获取该文件（每个块 1 个请求）。在 HDFS 中，这些请求通过网络传输并带来大量开销。每个请求都必须由名称节点处理以确定可以找到该块的位置。那是很大的流量！如果您使用 64Mb 块，请求数会减少到 16 个，从而显着降低 Name Node 上的开销和负载成本。

【讨论】：

感谢您的回答。假设块大小为 4KB，文件以连续块的形式存储在磁盘中。为什么我们不能使用 1 个请求检索 1000 MB 的文件？我知道目前可能 HDFS 不支持这种访问方法。但是这种访问方式有什么问题呢？

In the case of small files, lets say that you have a bunch of 1k files, and your block size is 4k. That means that each file is wasting 3k, which is not cool. - 对于 HDFS，情况并非如此。假设文件是​​ 100MB，那么块是 64MM 和 36BM。通常最后一个块的大小会更小，除非文件是 64MB 的倍数。

@user1956609 不，1Mb 的文件不会占用 64Mb 的磁盘空间。

这个答案是完全错误的。 “块”或“块大小”的含义取决于文件系统，对于 HDFS，它确实不是意味着它可以存储的最小单元，它是名称节点引用的最小单元。并且块通常顺序存储在物理磁盘上，这使得读取和写入块的速度很快。对于小文件，块大小无关紧要，因为无论如何它们都会小于块大小并存储为较小的块。因此，更大的块大小通常更好，但必须权衡所需的数据量和映射器分布。

@DavidOngaro 说块大小是名称节点引用的最小单位是正确的......我的解释有点过于简单化了。不过，我不确定为什么这会使答案“完全错误”。

【参考方案2】：

它更多地与 HDD（硬盘驱动器）的磁盘寻道有关。随着时间的推移，与磁盘吞吐量相比，磁盘寻道时间并没有太大进展。因此，当块大小较小（导致块过多）时，会出现过多的磁盘寻道，效率不高。随着我们从 HDD 到 SDD 的进步，磁盘寻道时间没有多大意义，因为它们是 SSD 中的移动部件。

另外，如果有太多的块，它会使名称节点紧张。请注意，名称节点必须将整个元数据（关于块的数据）存储在内存中。在 Apache Hadoop 中，默认块大小为 64 MB，在 Cloudera Hadoop 中，默认为 128 MB。

【讨论】：

所以您的意思是 64MB 块读取的底层实现没有分解为从磁盘读取的许多 4KB 块？磁盘是否支持一次读取 64MB？如果问题不清楚，请随时要求我澄清。谢谢。

如果 64MB HDFS 块会被拆分成多个 4KB 块，那么使用 64MB HDFS 块有什么意义呢？

减少节点服务器的负载。更少的跟踪块 = 更少的请求和更少的内存跟踪块。

那么就顺序访问而言，块大小为 64 或 128 真的没有优势吗？由于每个块都可能被拆分为多个本机文件系统块？

@Basil Paul，这是一个非常好的问题。目的是从底层文件系统中获取连续的块。在生产设置中，HDFS 拥有自己的卷，因此获得连续块不是问题。如果您与其他存储（如 mapreduce 临时数据等）混合使用，则会出现问题。我不确定它是如何精确管理的。您可能需要打开代码并查看它是如何管理的。

【参考方案3】：

以下是《Hadoop：权威指南》第 3 版一书的解释(p45)。

为什么 HDFS 中的块这么大？

HDFS 块比磁盘块大，原因是 最小化寻道的成本。通过使一个块足够大，时间 从磁盘传输数据的时间可能明显长于 寻找块开始的时间。因此转移的时间 由多个块组成的大文件在磁盘传输中运行 率。

快速计算表明，如果寻道时间约为 10 毫秒，并且 传输速率为 100 MB/s，以使寻道时间为 传输时间，我们需要使块大小在 100 MB 左右。这 默认值实际上是 64 MB，尽管许多 HDFS 安装使用 128 MB 块。这个数字将随着转移继续向上修正 速度随着新一代磁盘驱动器的推出而提高。

不过，这个论点不应太过分。映射任务 MapReduce 通常一次只在一个块上运行，所以如果你也有 任务少（少于集群中的节点），您的作业运行速度会变慢 否则他们就做不到。

【讨论】：

是否可以存储多个小文件（例如文件大小为 1KB）并将其存储在单个 64MB 块中？如果我们可以在一个块中存储多个小文件 - 如何读取块中的第 n 个文件 - 是否将文件指针查找到特定的 nth file 偏移位置 - 或者它会在读取第 n 个文件之前跳过 n-1 个文件内容？

【参考方案4】：

HDFS 的设计最初受到 Google 文件系统 (GFS) 设计的启发。这是原始 GFS 论文中所述的大块大小的两个原因（关于 GFS 术语与 HDFS 术语的注释 1：块 = 块，块服务器 = 数据节点，主节点 = 名称节点；注释 2：粗体格式是我的）：

大块大小提供了几个重要的优势。 第一，它减少了客户端与主节点交互的需要，因为对同一个块的读取和写入只需要向主节点发出一次初始请求以获取块位置信息。这种减少对于我们的工作负载尤其重要，因为应用程序主要是按顺序读取和写入大文件。 [...] 第二，由于在大块上，客户端更有可能在给定块上执行许多操作，它可以通过保持与块服务器的持久 TCP 连接来减少网络开销延长的时间。第三，它减少了存储在主服务器上的元数据的大小。这允许我们保留元数据 在内存中，这反过来又带来了我们将在第 2.6.1 节中讨论的其他优势。

最后，我应该指出current default size in Apache Hadoop 是 128 MB（参见 dfs.blocksize）。

【参考方案5】：

如果块大小设置为小于 64，整个集群中会出现大量块，这会导致 NameNode 管理大量元数据。 由于每个块都需要一个 Mapper，所以会有很多 Mapper，每个 Mapper 处理一段数据，效率不高。

【讨论】：

我同意（1），但不同意（2）。框架可以（默认情况下）让每个映射器处理多个数据块。

每个映射器处理一个拆分，而不是一个块。此外，即使为映射器分配了 N 个块的拆分，拆分的结尾也可能是部分记录，从而导致记录读取器（这是特定于每个记录读取器的，但通常适用于 Hadoop 附带的记录读取器）从下一个块中读取记录的其余部分。关键是映射器经常跨越块边界。

【参考方案6】：

Hadoop 选择 64MB 的原因是因为 Google 选择了 64MB。 Google 选择 64MB 的原因是因为 Goldilocks 的争论。

拥有更小的块大小会导致寻道开销增加。

具有适度较小的块大小使映射任务运行得足够快，以至于调度它们的成本与运行它们的成本相当。

具有明显更大的块大小会开始降低可用的读取并行度，并最终可能难以在任务本地调度任务。

参见 Google 研究出版物：MapReduce http://research.google.com/archive/mapreduce.html

【讨论】：

我的回答中已经提到了这一点。最好将 cmets 添加到我的答案中，而不是发布对先前答案几乎没有增加的答案。

【参考方案7】：

在正常的操作系统中，块大小为 4K，在 hadoop 中为 64 Mb。 因为为了便于维护 Namenode 中的元数据。

假设我们在 hadoop 中只有 4K 的块大小，并且我们试图将 100 MB 的数据加载到这个 4K 中，那么这里我们需要越来越多的 4K 块。而namenode需要维护所有这些4K的元数据块。

如果我们使用 64MB 的块大小，那么数据将仅加载到两个块中（64MB 和 36MB）。因此元数据的大小会减小。

结论： 为了减轻 namenode HDFS 的负担，更喜欢 64MB 或 128MB 的块大小。块的默认大小在 Hadoop 1.0 中为 64MB，在 Hadoop 2.0 中为 128MB。

【参考方案8】：

在 HDFS 中，块大小控制复制去集群的级别。块大小越小，您的块就越均匀地分布在 DataNode 中。块大小越大，您的数据在集群中的分布可能越不均匀。

那么选择更大的块大小而不是一些小的值有什么意义呢？虽然理论上数据的平均分布是一件好事，但块大小过低有一些明显的缺点。 NameNode 的容量是有限的，因此拥有 4KB 块大小而不是 128MB 意味着还要存储 32768 倍的信息。 MapReduce 还可以通过在更多 NodeManager 和更多 CPU 内核上启动更多 map 任务来从均匀分布的数据中获益，但在实践中，由于无法执行顺序、缓冲读取以及每个 map 任务的延迟，理论上的好处将丢失。

【讨论】：

来自“MapReduce 也可以通过在更多 NodeManager 和更多 CPU 内核上启动更多 map 任务来从均匀分布的数据中获益”——意味着 map reduce 任务应用于大量数据？

我无法清楚地将您带到这里“但在实践中，由于无法执行顺序缓冲读取以及每个映射任务的延迟，理论上的好处将会丢失”。你能详细说明一下吗？