谷歌gfs论文中文版.docx

摘要
我们设计并实现了Google文件系统，一个面向分布式数据密集型应用的、可伸缩的分布式文件系统。虽然运行在廉价的日用硬件设备上，但是它依然了提供容错功能，为大量客户机提供了很高的总体性能。
虽然与很多之前的分布式文件系统有很多相同目标，但是，我们的设计已经受应用的负载情况和技术环境影响，现在以及可预见的将来都反映出，我们的设计和早期的分布式文件系统的设想有了显著的分离。这让我们重新审视了传统文件系统在设计上的选择，探索彻底不同的设计点。
GFS成功满足了我们的存储需求。其作为存储平台被广泛的部署在Google内部，该平台用来产生和处理数据，这些数据被我们的服务以及需要大规模数据集的研究和开发工作使用。迄今为止，最大的一个集群利用一千多台机器上的数千个硬盘，提供数百TB的存储空间，同时被数百个客户机访问。
在本论文中，我们展示了设计用来支持分布式应用的文件系统接口的扩展，讨论我们设计的许多方面，最后对小规模基准测试和真实使用作了测量报告。
常用术语
设计，可靠性，性能，测量
关键词
容错，可伸缩性，数据存储，集群存储
1.     简介
为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统(Google File System–GFS)。GFS与之前的分布式文件系统有着很多相同的目标，比如，性能、扩展性、可靠性以及可用性。但是，我们的设计还受对我们的应用的负载和技术环境的观察的影响，现在以及可预见的将来都反映出，我们的设计和早期的分布式文件系统的设想有了显著的分离。这让我们重新审视了传统文件系统在设计上的选择，在设计上探索了彻底不同的设计点。
首先，组件失效被认为是常态事件，而不是意外事件。文件系统由几百乃至数千台由廉价的日常部件组装成的存储机器组成，同时被相当数量的客户机访问。部件的数量和质量事实保证了任意给定时间，一些部件无法工作，一些部件无法从它们目前的失效状态中恢复。我们遇到过如下原因导致的问题，比如应用程序bug、操作系统的bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效。因此，持久的监控、错误侦测、容错以及自动恢复必须集成在系统中。
其次，以传统的标准衡量，我们的文件非常巨大。数GB的文件非常普遍。每个文件通常包含许多应用程序对象，比如web文档。当我们定期由数亿个对象构成的快速增长的数TB的数据集时，即使文件系统支持，管理数十亿KB大小的小文件也是不实用的。因此，设计的假设条件和参数，比如I/O 操作和Block的尺寸都不得不重新考虑。
第三，绝大部分文件的变更是采用在追加新数据，而不是重写原有数据的方式。文件内部的随机写在实际中几乎不存在。一旦写完之后，文件只能读，而且通常只能顺序读。各种数据符合这些特性，比如：一些可能组成了数据分析程序扫描的超大数据集；一些可能是正在运行的应用程序生成的连续数据流；一些可能是档案数据；一些可能是由一台机器生成、另外一台机器处理的中间数据，同时处理或者稍后适时处理。考虑到这种针对海量文件的访问模式，数据的追加是性能优化和原子性保证的焦点所在，客户端对数据块缓存毫无吸引力。
第四，通过增加灵活性，应用程序和文件系统API的协同设计对整个系统有益。比如，我们放松了对GFS一致性模型的要求，不用在应用程序中强加繁重负担，大大简化了文件系统。我们甚至引入了原子性的追加操作，这样多个客户端可以对一个文件同时进行追加操作，不需要他俩之间额外的同步机制。这些问题会在下文进行详细讨论。
当前针对不同目的部署了多重GFS集群。最大的一个集群拥有超过1000个存储节点，超过300TB的硬盘存储，被不同机器上的数百个客户端连续不断的频繁访问。

 假设
在设计满足我们需求的文件系统时候，我们被这种现实指引着：我们的假设既有机遇、又有挑战。我们之前提到一些关键关注点，现在更详细地展示我们的假设。
系统由许多廉价的日用组件组成，组件失效是一种常态。系统必须持续监控自身状态，探测，处理容错并且迅速地恢复失效的组件。
系统存储一定数量的大文件。我们预期会有几百万个文件，文件的大小通常在100MB或者以上。数个GB大小的文件也是普遍存在，并且应该被被有效的管理。系统也必须支持小文件，但是不需要针对小文件做优化。
系统的工作负载主要由两种读操作组成：大规模的流式读取和小规模的随机读取。大规模的流式读取中，单次操作通常读取数百KB的数据，更常见的是一次读取1MB甚至更多的数据。来自同一个客户机的连续操作通常是读取一个文件中一个连续区域。小规模的随机读取通常是在任意位移上读取几个
KB数据。对性能敏感的应用程序通常把小规模的随机读取分批处理并排序，如此在文件中稳固前进而不是往复来去。
系统的工作负