Google 三大论文分别为：《Google File System》、《Google Bigtable》和《Google MapReduce》。这三大论文为大数据时代的发展奠定了理论基础，下面是我对此的一些理解。
一、GFS
Google File System 是Google公司为了存储海量搜集数据而设计的专用文件系统。是一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。与普通文件系统相比，GFS 虽然仍运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大客户机提供了高性能的服务。
二、设计思路
GFS与以往文件系统的不同观点如下：
-
系统由许多廉价的普通组件组成，组件失效是一种常态。
-
系统包含一定数量的大文件。预期上数量会有几百万，文件的大小通常是GB级。
-
系统支持两种读操作：大规模的流式读取和小规模的随机读取。在前一种读操作中，可能要读几百KB，通常达 1MB 或更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。
-
工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。
-
系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。
-
高可持续带宽比低延迟更重要
三、体系结构
1、GFS架构
-
一个GFS集群由一个master和大量的chunkserver构成，并被许多客户端访问。
-
每一个节点都是一个普通的Linux计算机，运行的是一个用户级别的服务器进程
-
在GFS下，每一个文件都拆成固定大小的chunk(块)。每一个块都由master根据块创建的时间产生一个全局唯一的以后不会改变的64位的chunk -handle标志。
-
ChunkServer 将块当作Linux文件存储在本地磁盘，并可以读和写由chunk－handle和位区间指定的数据。
-
出于可靠性的考虑，每个块都会 在不同的chunkserver上保存备份。缺省情况下，保存3个备份。
2、单master
只有一个master也极大的简化了设计并使得master可以根据全局情况作出精密的块放置和复制决定。但是我们必须要将master对读和写的参与减至最少，这样它才不会成为系统的瓶颈。
3、块规模
块规模是设计中的一个关键参数。我们选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。
块规模较大的好处有：
- 减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。
- Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。
- 这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。
4、快照
GFS 使用 copy-on-write 技术来实现快照。当 master 受到一个快照请求时，它首先将要快照的文件上块上的 lease 收回。这使得任何一个向这些块写数据的操作都必须和 master 交互以找到拥有 lease 的副本。
副本被撤销或终止后，master 在磁盘上登记执行的操作，然后复制源文件或目录树的 metadata 以对它的内存状态实施登记的操作。这个新创建的快照文件和源文件（其metadata）指向相同的块（chunk）。
它的内存状态实施登记的操作。这个新创建的快照文件和源文件（其metadata）指向相同的块（chunk）。
四、最后
GFS 作为 Google 公司为了存储搜集数据而设计的文件系统，虽然其源码未被公布，其理论为大数据时代的发展奠定了基础。现在知名的 hadoop 开源组件就是以Google三论文为理论设计的，HDFS 是 GFS论文的实现，只不过 HDFS 更通用而且开源。