为什么小文件会在 Google 文件系统中产生热点？

Question

我从Google 文件系统论文中不明白这一点

一个小文件由少量块组成，也许只有一个。如果许多客户端访问同一个文件，存储这些块的块服务器可能会成为热点。

小文件有什么区别？许多客户端访问的大文件是否同样有可能导致问题？

我想过/阅读以下内容：-

• 我假设（如果我错了，请纠正我）大文件块存储在不同的块服务器上，从而分配负载。在这种情况下，假设 1000 个客户端从每个块服务器访问文件的 1/100。所以每个 chunkserver 最终都会不可避免地收到 1000 个请求。（这与 1000 个客户端访问单个小文件不同。服务器收到 1000 个小文件请求或 1000 个大文件部分请求）
• 我读了一些关于稀疏文件的内容。小文件根据文件填满一个块或几个块。因此，据我所知，不会重建小文件，因此我已将其排除为热点的可能原因。

Answer 1

一些随后的文字可以帮助澄清：

然而，当 GFS 首次被批处理队列系统使用时，热点确实出现了：一个可执行文件作为单个块文件写入 GFS，然后同时在数百台机器上启动。存储此可执行文件的少数chunkserver 被数百个同时请求过载。我们通过以更高的复制因子存储此类可执行文件以及使批处理队列系统错开应用程序启动时间来解决此问题。一个潜在的长期解决方案是允许客户端在这种情况下从其他客户端读取数据。

如果 1000 个客户端要同时读取一个小文件，那么 N 个持有其唯一块的块服务器将同时收到 1000 / N 个请求。这种突然的负载就是热点的意思。

大文件不会被给定的客户端一次全部读取（毕竟，它们很大）。相反，他们将加载文件的某些部分，对其进行处理，然后转到下一部分。

在分片（MapReduce、Hadoop）场景中，worker 甚至可能根本不会读取相同的块；N 个客户端中的一个客户端将读取文件的 1/N 个块，与其他客户端不同。

即使在非分片场景中，实际上客户端也不会完全同步。他们可能最终都会读取整个文件，但采用随机访问模式，因此在统计上没有热点。或者，如果他们确实按顺序读取它，由于工作负载的差异，他们将不同步（除非您有意同步客户端......但不要这样做）。

因此，即使有很多客户端，由于大文件所需要的工作性质，大文件的热点也较少。不能保证，这就是我认为您在问题中所说的，但实际上分布式客户端不会在多块文件的每个块上协同工作。