在Hadoop中读取文件时的寻道次数()？

Question

我想确保我的概念是正确的：

在Hadoop the Definite中有这样的说法：“设计文件系统的目标总是减少寻道的数量，而不是要传输的数据量。”在这个声明中，作者指的是Hadoop逻辑块的“寻道()”，对吗？

我在想，无论Hadoop块大小有多大(64MB或128MB或更大)，底层文件系统(例如ext3/fat)必须执行的物理块(通常是4KB或8KB)的寻道数量将是相同的，无论Hadoop块大小如何。

示例:为了保持数字简单，假设底层文件系统块大小为1MB。我们想读取一个128MB大小的文件。如果Hadoop数据块大小为64MB，则文件占用2个数据块。当阅读时，有128个搜索。如果Hadoop数据块大小增加到128MB，则文件系统执行的寻道次数仍为128。在第二种情况下，Hadoop将执行1次查找，而不是2次。

我的理解正确吗？

如果我是正确的，那么通过增加数据块大小来显著提高性能只会对非常大的文件产生影响，对吧？我在想，对于大小在1~GB范围内的文件，将寻道数量从~20个寻道(64MB数据块大小)减少到~10个寻道(128MB数据块大小)应该没有太大区别，对吧？

Answer 1

您认为增加文件系统数据块大小将提高性能，这一点是正确的。Linux要求块大小小于或等于页面大小。x86页面大小限制为4K；因此，即使文件系统可以支持更大的块大小，您可以使用的最大块大小也是4K。大块大小和页面大小的性能优势是显著的:减少读/写系统调用，减少旋转延迟和寻道(不要开始考虑SSD)，更少的上下文切换，改进的缓存局部性，更少的TLB未命中，等等。

我根据我们的磁盘使用模式对各种块大小的好处进行了分析建模，在某些情况下，还预测了磁盘子系统带来的数量级改进。这将把性能瓶颈转移到其他地方。

您是正确的，可以获得显著的性能提升。不幸的是，控制这种改进的某个工程师看不到大于4K的页面大小的价值。他嘲笑那些需要高性能的企业用户，他们的工作负载在大型设备上基本上是同构的，而在台式机或笔记本电脑系统上交互运行的异构工作负载对高性能并不重要。