hadoop - 在 Hadoop 中读取文件时的 seeks() 次数？

Question

我想确保我正确理解了这个概念:

在 Hadoop 权威指南中指出:“设计文件系统的目标始终是减少与要传输的数据量相比的查找次数。”在此声明中，作者指的是 Hadoop 逻辑 block 的“seeks()”，对吗？

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

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

我的理解正确吗？

如果我是正确的，只有在非常大的文件中才会观察到通过增加 block 大小来显着提高性能，对吗？我认为对于大小在 1~GB 范围内的文件，将搜索次数从~20 次搜索(64MB block 大小)减少到~10 次搜索(128MB block 大小)应该不会有太大区别，对吧？

Answer 1

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

我根据我们的磁盘使用模式对各种 block 大小的好处进行了分析建模，并在某些情况下预测了磁盘子系统的数量级改进。这会将性能瓶颈转移到别处。

您是正确的，可以显着提高性能。不幸的是，控制此类改进的某位工程师认为页面大小大于 4K 没有任何值(value)。他 mock 那些需要高性能的企业用户，这些用户需要在大型机上从大部分同质的工作负载中获得高性能，并专注于在高性能不重要的台式机或笔记本电脑系统上以交互方式运行的异构工作负载。