我不从Google File Systems Paper为什么小文件会在Google文件系统中创建热点？
一个小文件由少数块，也许只是一个明白这一点。如果许多客户端 正在访问相同的文件，则存储这些块的大块服务器可能会成为热点。
小文件有什么区别？许多客户访问的大文件是否可能导致问题？
我想过/阅读以下内容： -
一些后续文本可以帮助澄清：
然而，热点做开发时，政府飞行服务队首次使用 通过批处理队列系统：一个可执行文件被写入GFS 作为一个单一的然后在数百台机器 上同时启动。存储这个 可执行文件的少数大块服务器被数百个并发请求超载。 我们通过存储具有较高复制因子的此类可执行文件 以及通过使批处理队列 系统错开应用程序启动时间来解决此问题。长期的解决方案是允许客户在这种情况下从其他 客户读取数据。
如果1000个客户端要同时读取一个小文件，则拥有其唯一块的N个块服务器将同时接收1000个/ N个请求。这突如其来的负载是热点意味着什么。
大文件不会被给定客户端一次全部读取（毕竟它们很大）。相反，他们将加载文件的某些部分，对其进行处理，然后转到下一部分。
在分片（MapReduce，Hadoop）方案中，工作人员可能根本就不会读取相同的块; N中的一个客户端将读取文件的1/N块，与其他客户端不同。
即使在非分片场景下，实际上客户端也不会完全同步。他们可能最终都会读取整个文件，但随机访问模式，以便统计上没有热点。或者，如果他们确实按顺序读取它们，由于工作负载的差异，它们会不同步（除非您有意地同步客户机......但不这样做）。
即使有很多客户端，由于大型文件带来的工作性质，大型文件的热点也会减少。这不是保证，这是我认为你在你的问题中说，但实际上分布式客户端不会在多块文件的每个块上串联工作。
说大量的客户访问同一台服务器上的不同文件，它会成为一个热点吗？ （我基本上想知道访问硬盘的相同区域是否会导致问题，还是由于负载增加） –
它从来没有正式定义过，但术语热点通常用于指任何导致高的单个对象加载。所以“这个文件/大块/香蕉/鞋子是一个热点”只是意味着“这件事导致了比平常更高的负荷”。因此，具有恰好位于同一块服务器上的块的不同文件不仅会被视为热点 - 这只是系统上的常规加载。 – GManNickG
热点问题并不一定是一回事，也许机器的网络接口过载，也许机器上的带宽跟不上请求等等。记住，这个块服务器正在所有想要它的块的客户机之间共享，所以热点可能只是“这个块远离其他块访问需要太多的“
“在这种情况下，1000个客户端访问每个块服务器的1/100的文件，因此每个块服务器不可避免地最终获得1000个请求。”你能更多地在这里扩展你的想法吗？如果客户端访问文件的1/100，则每个客户端只会联系百分之一的大块服务器。这篇论文的想法是，对于大文件，访问模式实际上是跨块服务器的随机分布*，但不是一次全部*。 – GManNickG
@GManNickG一个大文件存储在100个块服务器中。 1000个客户端需要该特定文件。他们最终都将需要来自100个大块服务器的数据。所以每个chunkserver都会最终为1000个客户提供服务。即使有一个随机分布，每个文件所做的单个请求都不会等于一个小文件产生的负载吗？ 更重要的是大文件的部分存储在不同的块服务器？ –
Gotcha。在你的场景中，所有的块服务器最终都会服务1000次，是的，但是瞬时负载会更低。 1000个客户端同时向单个服务器请求数据是一个热点，如果客户端不仅仅是同时连接每个数据块服务器，而是超过100个数据块服务器的1000个客户端意味着您的任何服务器上的即时负载更低。然而，我相信这篇论文的重点是，在实际应用中，并不是所有的客户端都会读完整个文件，在这种情况下，chunkserver只处理（例如）一个请求。 – GManNickG