谷歌GFS文件系统：大规模数据处理的关键设计

需积分: 33 41 浏览量更新于2024-07-21 收藏 356KB DOCX 举报

"《The Google File System》中文版论文深入探讨了Google在面对大规模数据密集型应用时所设计和实现的一种分布式文件系统——GFS。本文强调了GFS在低成本通用硬件基础上提供灾难冗余能力的重要性，确保了高可用性和高性能服务。尽管GFS的目标与传统分布式文件系统相似，但其设计的独特之处在于对Google特定应用场景和技术环境的深入了解，这使其与早期设计有所不同。文章详细介绍了GFS如何处理组件失效的常态，将之视为设计中的核心考量。由于系统由成百上千台廉价设备组成，每个组件的故障都可能随时发生。GFS通过设计一个能够应对这些常见问题的系统，确保了其高度的容错性和可伸缩性。此外，GFS不仅被广泛应用于Google内部的数据存储和处理，还用于大型数据集的研究和开发，单个集群能提供数百TB的存储空间并支持数百个客户端。论文的核心内容包括文件系统接口的扩展，系统设计的多方面讨论，以及针对小规模性能测试和实际生产环境中性能表现的分析。作者特别关注了关键术语，如容错、可伸缩性、数据存储和集群存储，这些都是GFS设计的核心要素。这篇论文提供了深入理解GFS设计理念、架构和实际应用的视角，展示了如何在挑战性的技术环境下构建一个高效、可靠的分布式文件系统。对于理解和研究分布式计算和存储技术的读者来说，这是一篇不可多得的资料。"

即便是需要支持更大的文件系统，为 Master 服务器增加额外内存的费用是很少的，而通过增加有限的费用，我们就能够把元数据全部保存在内存

里，增强了系统的简洁性、可靠性、高性能和灵活性。

2.6.2 Chunk 位置信息

Master 服务器并不保存持久化保存哪个 Chunk 服务器存有指定 Chunk 的副本的信息。Master 服务器只是在启动的时候轮询 Chunk 服务器以获取

这些信息。Master 服务器能够保证它持有的信息始终是最新的，因为它控制了所有的 Chunk 位置的分配，而且通过周期性的心跳信息监控 Chunk

服务器的状态。

最初设计时，我们试图把 Chunk 的位置信息持久的保存在 Master 服务器上，但是后来我们发现在启动的时候轮询 Chunk 服务器，之后定期轮询

更新的方式更简单。这种设计简化了在有 Chunk 服务器加入集群、离开集群、更名、失效、以及重启的时候，Master 服务器和 Chunk 服务器数据

同步的问题。在一个拥有数百台服务器的集群中，这类事件会频繁的发生。

可以从另外一个角度去理解这个设计决策：只有 Chunk 服务器才能最终确定一个 Chunk 是否在它的硬盘上。我们从没有考虑过在 Master 服务器

上维护一个这些信息的全局视图，因为 Chunk 服务器的错误可能会导致 Chunk 自动消失(比如，硬盘损坏了或者无法访问了)，亦或者操作人员可

能会重命名一个 Chunk 服务器。

2.6.3 操作日志

操作日志包含了关键的元数据变更历史记录。这对 GFS 非常重要。这不仅仅是因为操作日志是元数据唯一的持久化存储记录，它也作为判断同步

操作顺序的逻辑时间基线（alex 注：也就是通过逻辑日志的序号作为操作发生的逻辑时间，类似于事务系统中的 LSN）。文件和 Chunk，连同它

们的版本(参考 4.5 节)，都由它们创建的逻辑时间唯一的、永久的标识。

操作日志非常重要，我们必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。否则，即使 Chunk 本身没

有出现任何问题，我们仍有可能丢失整个文件系统，或者丢失客户端最近的操作。所以，我们会把日志复制到多台远程机器，并且只有把相应的

日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操作请求。Master 服务器会收集多个日志记录后批量处理，以减少写入磁盘和复

制对系统整体性能的影响。

Master 服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。为了缩短 Master 启动的时间，我们必须使日志足够小（alex 注：

即重演系统操作的日志量尽量的少）。Master 服务器在日志增长到一定量时对系统状态做一次 Checkpoint(alex 注：Checkpoint 是一种行为，一

种对数据库状态作一次快照的行为)，将所有的状态数据写入一个 Checkpoint 文件（alex 注：并删除之前的日志文件）。在灾难恢复的时候，

Master 服务器就通过从磁盘上读取这个 Checkpoint 文件，以及重演 Checkpoint 之后的有限个日志文件就能够恢复系统。Checkpoint 文件以压缩

B-树形势的数据结构存储，可以直接映射到内存，在用于命名空间查询时无需额外的解析。这大大提高了恢复速度，增强了可用性。

由于创建一个 Checkpoint 文件需要一定的时间，所以 Master 服务器的内部状态被组织为一种格式，这种格式要确保在 Checkpoint 过程中不会阻

塞正在进行的修改操作。Master 服务器使用独立的线程切换到新的日志文件和创建新的 Checkpoint 文件。新的 Checkpoint 文件包括切换前所有

的修改。对于一个包含数百万个文件的集群，创建一个 Checkpoint 文件需要 1 分钟左右的时间。创建完成后，Checkpoint 文件会被写入在本地和

远程的硬盘里。

Master 服务器恢复只需要最新的 Checkpoint 文件和后续的日志文件。旧的 Checkpoint 文件和日志文件可以被删除，但是为了应对灾难性的故障

（alex 注：catastrophes，数据备份相关文档中经常会遇到这个词，表示一种超出预期范围的灾难性事件），我们通常会多保存一些历史文件。

Checkpoint 失败不会对正确性产生任何影响，因为恢复功能的代码可以检测并跳过没有完成的 Checkpoint 文件。

2.7 一致性模型

GFS 支持一个宽松的一致性模型，这个模型能够很好的支撑我们的高度分布的应用，同时还保持了相对简单且容易实现的优点。本节我们讨论

GFS 的一致性的保障机制，以及对应用程序的意义。我们也着重描述了 GFS 如何管理这些一致性保障机制，但是实现的细节将在本论文的其它

部分讨论。

2.7.1 GFS 一致性保障机制

剩余22页未读，继续阅读

zhaoliang1133

粉丝: 26
资源: 34

谷歌GFS文件系统：大规模数据处理的关键设计

The Google File System中文版.docx

The Google File System中文版

google file system 论文中文翻译版

Google_file_system-论文-中文版

Google文件系统(Google_File_System)论文中文版

Google-File-System中文版_1.0.zip

Google File System论文中文版：大规模数据处理与分布式设计

谷歌Bigtable File-System MapReduce论文

谷歌三驾马车中文版 google file system+mapreduce+bigtable中文版

Google-File-System中文版

最新资源