Paper | The Google File System(2003)

Mon, 10 Aug 2026 00:00:00 +0000

The Google File System(2003)

ABSTRACT 摘要

我们设计并实现了一个可扩展的分布式文件系统——Google File System（GFS），用于大型分布式数据密集型应用。它运行在廉价的通用硬件之上，具有容错能力，并能为大量客户端提供极高的聚合性能。

尽管 GFS 与以往的分布式文件系统在许多目标上大体一致，但我们的设计源于对应用负载以及技术环境（包括现状与预判）的观察，这些观察与早期文件系统的一些假设存在显著差异。这促使我们重新审视传统的设计选择，并探索截然不同的设计方向。

该文件系统已成功满足我们的存储需求。它在 Google 内部被广泛部署，作为我们服务的数据生成与处理平台，同时也服务于需要大规模数据集的研发工作。迄今为止，最大的集群通过分布在 1000 多台机器上的数千张磁盘，提供了数百 TB 的存储空间，并同时供数百个客户端并发访问。

在本论文中，我们将展示旨在支持分布式应用的文件系统接口扩展，探讨我们设计的诸多细节，并报告微基准测试以及实际应用中的性能测量数据。

1 INTRODUCTION 介绍

我们设计并实现了 Google 文件系统（Google File System，简称 GFS），以满足 Google 日益增长的数据处理需求。GFS 与以往的分布式文件系统有着许多共同的目标，例如高性能、可扩展性、可靠性和高可用性。然而，它的设计是由我们对当前及预期的应用负载和技术环境的若干关键观察所驱动的，这些观察体现出了与早期文件系统设计假设的显著不同。我们重新审视了传统的设计选择，并在设计空间中探索了截然不同的方向。

第一，组件故障是常态，而非例外。 该文件系统由数百甚至数千台由廉价通用部件构建的存储机器组成，并由数量相当Client（客户端）机器进行访问。组件的数量和质量实际上保证了在任何给定时刻都会有一些部件无法正常工作，且有些故障是无法恢复的。我们观察到了由应用程序 Bug、操作系统 Bug、人为失误，以及硬盘、内存、连接线、网络和电源故障所导致的问题。因此，持续监控、错误检测、容错机制和自动恢复必须成为系统不可分割的一部分。

第二，按照传统标准，文件是巨大无比的。 几个 GB 大小的文件非常普遍。每个文件通常包含许多应用程序对象（例如网页文档）。当我们日常处理包含数十亿对象、且快速增长的数 TB 级数据集时，即便文件系统能够支持，管理数十亿个 KB 级别大小的文件也会变得非常笨重。因此，诸如 I/O 操作和块大小（blocksize）等设计假设与参数必须被重新审视。

第三，大多数文件是通过追加新数据而非覆盖现有数据来进行修改的。 文件内部的随机写入实际上几乎不存在。文件一旦写入，就只会被读取，且通常是顺序读取。各种各样的数据都具备这些特征。有些可能构成数据分析程序扫描的大型存储库；有些可能是正在运行的应用持续产生的数据流；有些可能是归档数据；还有些可能是在一台机器上产生并在另一台机器上处理（无论是同时还是稍后）的中间结果。考虑到巨型文件上的这种访问模式，追加（append）操作成为了性能优化和原子性保证的焦点，而客户端的数据块缓存（caching）则失去了吸引力。

第四，联合设计（co-designing）应用程序和文件系统 API，能够通过增加灵活性来提升整个系统的效益。 例如，我们放宽了 GFS 的一致性模型，在不给应用程序增加繁重负担的前提下，极大地简化了文件系统。我们还引入了原子追加（atomic append）操作，以便多个客户端可以并发地向同一个文件追加数据，而无需它们之间进行额外同步。这些内容将在本论文后文中更详细地讨论。

目前我们部署了多个用于不同用途的 GFS 集群。其中最大的集群拥有 1000 多个存储节点、超过 300 TB 的磁盘存储空间，并持续受到来自不同机器上的数百个客户端的高强度访问。

2 DESIGN OVERVIEW 设计概览

2.1 Assumptions 假设