Hadoop数据节点：为什么数据块的阈值有一个神奇的“数字”？

Question

专家，

我们可能会看到我们的块数在我们的 hadoop 集群中增加。 “太多”块会导致数据节点堆需求增加、执行速度下降、GC 更多等后果。当块数超过某个“阈值”时，​​我们应该注意。

1. 我已经看到了不同的阈值静态数字，例如 200,000 或 500,000——“神奇”数字。它不应该是节点内存的函数（Java Heap Size of DataNode in Bytes）吗？

其他有趣的相关问题：

1. 高块数表示什么？ 一种。小文件太多？ 湾。容量不足？ 是（a）还是（b）？如何区分两者？

2. 什么是小文件？文件大小小于块大小（dfs.blocksize）？

3. 每个文件是否在磁盘上占用一个新数据块？还是与新文件关联的元数据有问题？

4. 影响是更多的 GC，降低执行速度等。如何“量化”高块数的影响？

提前致谢

Answer 1

感谢大家的意见。我已经对该主题进行了一些研究并分享了我的发现。

1. 任何静态数字都是幻数。我建议块阈值的数量为：堆内存（以 gb 为单位）x 100 万 *comfort_%age（比如 50%）

为什么？ 经验法则：1M 块 1gb，Cloudera [1]

namenode 实际所需的堆内存量要低得多。 所需堆 =（块数 + inode（文件 + 文件夹））x 对象大小（150-300 字节 [1]）

对于 100 万个小文件：所需堆 = (1M + 1M) x 300b = 572mb

1. 高块数可能同时表明两者。 namenode UI 说明使用的堆容量。

例如， http://namenode:50070/dfshealth.html#tab-overview 9,847,555 个文件和目录，6,827,152 个块 = 16,674,707 个文件系统对象。 堆内存使用 5.82 GB 的 15.85 GB 堆内存。最大堆内存为 15.85 GB。

** 注意，使用的堆内存仍然高于 16,674,707 个对象 x 300 字节 = 4.65gb

要找出小文件，请执行 hdfs fsck -blocks | grep "总块数（已验证）：" 它会返回如下内容： 总块（已验证）：2402（平均块大小 325594 B）

1. 是的。如果文件大小 ，则文件很小
2. • 每个文件在磁盘上占用一个新数据块，尽管块大小接近文件大小。这么小的街区。
   • 对于每一个新文件，都会创建一个inode类型的对象（150B），所以要强调name node的堆内存

对名称和数据节点的影响： 小文件会给名称节点和数据节点带来问题： 命名节点： - 拉低文件数量的上限，因为它需要将每个文件的元数据保留在内存中 - 重启时间过长，因为它必须从本地磁盘上的缓存中读取每个文件的元数据

数据节点： - 大量的小文件意味着大量的随机磁盘 IO。 HDFS 专为大文件而设计，并受益于顺序读取。

[1]https://www.cloudera.com/documentation/enterprise/5-8-x/topics/admin_nn_memory_config.html

Answer 2

您的第一个假设是错误的，因为 Data 节点不维护内存中的数据文件结构，因此 Name 节点的工作是跟踪内存中的文件系统（循环到 INode）。所以小文件实际上会导致你的 Name 节点更快地耗尽内存（因为需要更多的元数据来表示相同数量的数据）并且执行速度会受到影响，因为 Mapper 是按块创建的。

1. 要回答您的第一个问题，请查看：Namenode file quantity limit
2. 执行以下命令：hadoop fs -du -s -h。如果您看到第一个值（表示所有文件的平均文件大小）远小于配置的块大小，那么您将面临小文件的问题。要检查您是否空间不足：hadoop fs -df -h
3. 是的，可以小得多。有时，如果文件太大，则需要额外的块。一旦该块被保留给某个文件，它就不能被其他文件使用。
4. 该块不会在磁盘上保留超出其实际存储数据所需的空间，它是施加限制的名称节点上的元数据。
5. 正如我之前所说，对于相同数量的数据，需要执行更多的映射器任务。由于映射器是在新的 JVM 上运行的，所以 GC 不是问题，但为处理少量数据而启动它的开销是问题。