google论文2-google文件系统(上).doc

《google论文2-google文件系统(上).doc》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、【google论文二】Google文件系统(上)2010-10-0117:01:45

2、  分类：搜索与分布式

3、  标签：master  chunkserver  副本  文件系统  append  

4、字号大中小 订阅转载请注明：http://duanple.blog.163.com/blog/static/7097176720109145829346/ 作者phylips@bmy 摘要我们设计实现了google文件系统，一个面向大规模分布式数据密集性应用的可扩展分布式文件系统。它运行在廉价的商品化硬件上提供容错

5、功能，为大量的客户端提供高的整体性能。 尽管与现有的分布式文件系统具有很多相同的目标，我们的设计更多的来源于对于我们的具体应用的负载类型以及当前甚至未来技术环境的观察，这就使得它与早期的文件系统表现出明显的不同。这也使得我们重新审视传统上的设计选择，探索出一些在根本上不同的设计观点。 这个文件系统成功的满足了我们的存储需求。伴随这研究和开发的努力，在google内部，它已经作为那些需要大数据集服务的数据生成处理的基础存储平台而广泛部署。迄今为止，最大的集群可以通过超过一千台机器的数千块硬盘提供数百T的存储，这些

6、存储空间可以由数百个客户端并发访问。 在本论文中，我们将描述为了支持分布式应用的文件系统扩展接口设计，讨论很多我们的设计观点，展示来自于beachmark和现实世界的一些测量数据。 分类和主题描述：分布式文件系统  常用词：设计，可靠性，性能，测量 关键词：容错，可扩展，数据存储，集群存储 导引为了满足google快速增长的数据处理需求，我们设计实现了google文件系统(GFS)。GFS与传统的分布式文件系统具有很多相同的目标比如性能，可扩展性，可靠性，可用性。然而，它的设计是由我们的具体应用的负载类型以及当

7、前甚至未来技术环境的观察驱动的，所以与早期文件系统的设计假设具有明显的区别。我们重新审视传统上的设计选择，探索出一些在根本上不同的设计观点。 一，组件失败成为一种常态而不是异常。文件系统是由成百上千台通过廉价的商品化部件组装起来的存储机器构成，可以被大量的客户端访问。组件的数量和质量在本质上决定了在某一时间有一些是不可用的，有一些无法从当前的失败中恢复过来。我们观察到，应用程序的bug，操作系统bug，人为的错误，硬盘的失败，内存，连接器，网络，电力供应都可以引起这样的问题。因此经常性的监控，错误检测，容错和自

8、动恢复必须集成到系统中。 二，与传统的标准相比，文件是巨大的。在这里，好几个G的文件是很普通的。每个文件通常包含很多的应用程序处理的对象比如网页文档。当我们日常处理的快速增长的数据集合总是达到好几个TB的大小，包含数十亿的对象时，去处理数十亿个KB级别的文件即使文件系统支持也会显得很笨重。这样设计中的一些假设和参数，比如IO操作和块大小就必须重新定义。三，大部分的文件更新模式是通过在尾部追加数据而不是覆盖现有数据。文件内部的随机写操作几乎是不存在的。一旦写完，文件就是只读的，而且通常是顺序读。大量的数据都具有这

9、样的特点。有些可能是被数据分析程序扫描的库组成，有些可能是由运行中的应用程序持续生成的数据流，有些可能是档案数据，有些可能是数据需要由一台机器产生，然后由另一台机器处理而产生的中间结果。假设在大文件上数据访问具有这样的模式，那么当当缓存数据在客户端失效后，append操作就成为性能优化和原子性的关键。 四，应用程序和文件系统api的协同设计，增加了整个系统的灵活性。比如我们通过放松了GFS的一致性模型大大简化了文件系统，同时也没有给应用程序带来繁重的负担。我们也提供了一个原子性的append操作，这样多个客户端

10、就可以对同一个文件并行的进行append操作而不需要彼此间进行额外的同步操作。这些都会在后面进行详细的讨论。 目前已经有多个GFS集群为了不同的目的而部署起来。最大的那个具有1000个存储节点，超过300T的磁盘空间，被来自不同机器的数百个客户端持续访问着。 2设计概览2.1假设在设计一个满足我们需求的文件系统时，我们以一些充满了挑战和机遇的假设作为指南，之前我们曾间接的提到过一些关键的点，现在我们把这些假设再详细的列出来。 系统是由廉价的经常失败的商品化组件构建而来。必须进行经常性的监控和检测，容错，并且能够

11、从组件失败中迅速的恢复，这些都应该像是例行公事。 系统存储了适度个数的大文件。我们期望有数百万个文件，每个100mb或者更大。上GB的文件大小应该是很普通的情况而且能被有效的管理。小文件也应该被支持，但我们不需要为它们进行优化。 工作负载主要由两种类型的读组成：大的顺序流式读取和小的随机读取。在大的流式读取中，单个操作通常要读取数百k，甚至1m或者更大的数据。来自于同一个客户端的连续读