Hadoop数据节点：为什么有一个神奇的数字＆＃34;对于数据块的阈值？

Question

专家，

我们可能会看到我们的块计数在我们的hadoop集群中增长。 ＆＃34;太多＆＃34;块会产生一些后果，例如数据节点的堆需求增加，执行速度下降，GC更多等。当块数超过某个阈值时，我们应该注意＃34;

1. 我看到过阈值的不同静态数字，例如200,000或500,000 - ＆＃34; magic＆＃34;数字。它不应该是节点内存的函数（以字节为单位的Java堆的Java堆大小）吗？

其他有趣的相关问题：

1. 高块数表示什么？ 一个。太多的小文件？ 湾用完了？ 是（a）还是（b）？如何区分两者？

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

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

4. 效果更多是GC，降低执行速度等。如何量化＆＃34;高块数的影响？

提前感谢

Answer 1

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

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

Answer 2

感谢大家的投入。我对这个主题做了一些研究并分享了我的发现。

1. 任何静态数字都是幻数。我建议块阈值的数量为：堆内存（以gb为单位）×1百万* comfort_％年龄（比如说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）＆lt; ==小于1mb

1. 是肯定的。如果文件的大小<1，则文件很小。 dfs.blocksize。
2. • 每个文件在磁盘上占用一个新数据块，但块大小接近文件大小。如此小块。
   • 对于每个新文件，创建inode类型对象（150B），因此对名称节点的堆内存施加压力

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

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

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