但凡开始讲大数据的，都离不开谷歌的三篇论文：Google File System(GFS)，MapReduce，BigTable。本篇主要介绍谷歌的GFS，后面会介绍Mapreduce和BigTable。
我们先来看一下Linux的体系结构
Linux文件系统中的文件是数据的集合，文件系统不仅包含着文件中的数据而且还有文件系统的结构，所有Linux 用户和程序看到的文件、目录、软连接及文件保护信息等都存储在其中。
Hadoop也有自己的文件系统Hadoop Distributed File System（HDFS），Hadoop的HDFS设计思想源于谷歌的GFS，看GFS的全写就知道，GFS是谷歌的一个文件系统，但跟我们计算机里面的硬盘不一样，我们的硬盘只存在于你的一台计算机中，而GFS是建立在大量的计算机组成的集群中，用来存储海量数据（TB级和PB级）。
一 个GFS集群由一个master和大量的chunkserver构成，并被许多客户（Client）访问。
Master和 chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，chunkserver和client可以运行在同一个机器 上。文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk－handle标识，chunk－handle是在块创建时 由 master分配的。ChunkServer将块当作Linux文件存储在本地磁盘并可以读和写由chunk－handle和位区间指定的数据。出于可靠性考虑，每一个块被复制到多个chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。
Master维护文件系统所有的元数据（metadata），包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约（lease）管理，孤儿块的垃圾收集，chunkserver间的块迁移。Master定期通过HeartBeat消息与每一个 chunkserver通信，给chunkserver传递指令并收集它的状态。
与每个应用相联的GFS客户代码实现了文件系统的API并与master和chunkserver通信以代表应用程序读和写数据。客户与master的交换只限于对元数据（metadata）的操作，所有数据方面的通信都直接和chunkserver联系。
客 户端和chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户端程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据（metadata）。Chunkserver也不必缓存文件，因为块是作为本地文件存储的。
一个GFS包括一个主服务器（master）和多个块服务器（chunk server），这样一个GFS能够同时为多个客户端应用程序（Application）提供文件服务。文件被划分为固定的块，由主服务器安排存放到块服务器的本地硬盘上。主服务器会记录存放位置等数据，并负责维护和管理文件系统，包括块的租用、垃圾块的回收以及块在不同块服务器之间的迁移。此外，主服务器还周期性地与每个块服务器通过消息交互，以监视运行状态或下达命令。客户端通过与主服务器和块服务器的交互来实现对应用数据的读写，客户端与主服务器之间的交互仅限于元数据，也就是一些控制数据，其他的数据操作都是直接与块服务器交互的，从而达到了控制与业务相分离。
只有一个master也极大的简化了设计并使得master可以根据全局情况作出精密的块放置和复制决定。但是我们必须要将master对读和写的参与减至 最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。Client只是询问master它应该和哪个 chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和chunkserver交互。
块规模是设计中的一个关键参数。GFS选择的块大小是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。
GFS中还有其他的一些特性和细节，本文不再描述，HDFS就是基于GFS的设计思想而来，下篇会讲HDFS。