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

EN

谢谢大家的意见。我已经对这个话题做了一些研究，并分享了我的发现。

1. 任何静态数字都是幻数。我建议块阈值为:堆内存( gb) x1百万* comfort_%age (比方说50%)

为什么？经验法则: 1gb的1M块，Cloudera 1

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

对于100万个小文件:堆需要= (1M + 1M) x300b=572 of <==，比经验法则要小得多。

1. 较高的块计数可能表明两者都有。namenode声明使用的堆容量。

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

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

要查找小文件，请执行hdfs -blocks \ grep“总计块(验证)：”它将返回如下内容:总块(验证)：2402 (avg )。块大小325594 B)小于1mb的<==

1. 是。如果文件的大小< dfs.blocksize，则该文件是小的。
2. ​
   • 每个文件在磁盘上接受一个新的数据块，尽管块大小接近文件大小。这么小的街区。
   • 对于每一个新文件，inode类型对象都会被创建(150 B)，因此需要占用名称节点的堆内存。

​

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

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

1

第一个假设是错误的，因为数据节点没有在内存中维护数据文件结构，所以名称节点的任务是跟踪内存中的文件系统( INodes)。因此，小文件实际上会导致名称节点更快地耗尽内存(因为需要更多的元数据来表示相同数量的数据)，而且执行速度将受到影响，因为Mapper是每个块创建的。

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