首页 > 代码库 > 分布式文件系统--GFS
分布式文件系统--GFS
前言：Google大数据处理的3篇核心论文
《The Google File System》：http://research.google.com/archive/gfs.html
《MapReduce: Simplified Data Processing on Large Clusters 》：http://research.google.com/archive/mapreduce.html
《Bigtable: A Distributed Storage System for Structured Data》：http://research.google.com/archive/bigtable.html
GFS（Google文件系统）作为一个分布式文件系统，为Google提供基础的海量数据存储服务。虽然GFS并没有开源，但Google在其 04年发表的论文《The Google File System》里面做了详细的介绍，很多设计思路都很有学习的价值。
分布式文件系统
分布式文件系统：当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区（partition）并存储到若干台单独的计算机上。管理网络中夸多台计算机存储的文件系统。这种系统构架于网络之上，肯定会引入网络编程的复杂性，因此它比普通的磁盘文件系统更为复杂。
我们首先来简单的说明一下这个分布式，我们都知道现在要存储的数据量越来越大，但是一台电脑的存储能力是有限的，尽管我们可以通过提高某台电脑的存储能力来解决这个问题，但是这是无法根本解决这个问题，所以我们通过很多很多台廉价的电脑来分布式存储这些数据。简单说就是把要存的文件分割成一份一份存到许多台电脑上。
Google File System：是由google开发并设计的一个面向大规模数据处理的一个分布式文件系统。
为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统。它是有几百甚至几千台普通的廉价设备组装的存储机器。以下是一些设计思路。
1）我们知道有这么多机器，那么这些设备中的某些机器出现故障是很常见的事情，所以在GFS要集成持续的监控、错误侦测、灾难冗 余以及自动恢复的机制。
2）我们要存的数据大小是很大，所以要是按照以往的存储文件块大小，那么就要管理数亿个KB大小的小文件，这是很不合理的，所以在这个系统里面他们定义一个文件块的大小是64M。
3）绝大部分的大数据都是采用在文件尾部追加数据的，而不是覆盖数据的。对大文件的随机写入基本上是不存在的。
4）应用程序和文件系统API协同设计，简化对GFS的要求。
GFS架构设计：
GFS采用主/从模式，一个GFS包括一个master服务器r和多个chunk服务器。当然这里的一个master是指逻辑上的一个，物理上可以有多个（就是可能有两台，一台用于以防万一，一台用于正常的数据管理）。并且我们可以把客户端以及chunk服务器放在同一台机器上。
GFS Master（即NameNode）：单独节点，管理GFS所有元数据（如名字空间、访问控制权限等）
GFS ChunkServer（即DataNode）：数据存储节点，文件被分割为固定大小的（block）Chunk，每个Chunk被唯一标识，默认情况下，（block）Chunk存储为3个副本。
GFS Client：实现GFS的API接口函数（不是POSIX标准，因为API只需在用户空间调用）
我们先来说明一下数据是如何存储的。我们上面说过大数据会被切分，并且单位是64M。所以在GFS中，存储的文件会被切分成固定大小的block，每当一个block被创建的时候都会由master为它分配一个全球固定的标识。chunk服务器把block以linux文件存储的形式存储在本地系统。为了可靠性，每块block可能会复制成多份存放在不同的机器节点上。并且master服务器存储着文件和block之间的位置映射已经其他一些元数据信息。
1、master（就是在hadoop里面的namenode）：
master管理者所有文件的元数据，比如说名字空间，block的映射位置等等。Master节点使用心跳信息周期地和每个Chunk服务器通讯，发送指令到各个Chunk服务器并接收Chunk服务器的状态信息。我们知道master是单一节点的（逻辑上）。这个是可以大大简化系统的设计。单一的master可以通过全局信息精确的定位每个block在哪个chunk服务器上以及进行复制决策。由于只有一台master，所以我们要减少对master的读写操作，避免master成为系统的瓶颈。而且master的元数据都是存储在内存当中的，这样速度处理快，但是也导致了存储的数据是有限制的。
要注意的是，客户端对数据的读写不是在master上，而是通过master获取block在chunk的位置信息，直接和chunk服务器进行数据交互读写的。我们说master是逻辑上只有一个节点，物理可能有两个。就行hadoop里面的hdfs一样，有一个namenode和secondarynamenode。另外一个正常情况下不去用，当master服务器宕机了，它就体现价值了。有点映像的感觉，当然它还有其他好多功能。
2、Chunk（就是hadoop里面datanode）：这个才是用于存储数据的机器，文件大小为64MB，这个尺寸远远大于一般文件系统的Block size。每个block的副本都以普通Linux文件的形式保存在Chunk服务器上。Master服务器并不保存持久化保存哪个Chunk服务器存有指定block的副本的信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息。Master服务器能够保证它持有的信息始终是最新的，因为它控制了所有的block位置的分配，而且通过周期性的心跳信息监控 Chunk服务器的状态。
block块较大尺寸优点：（是一个关键的设计参数，默认为64MB。每个block都以普通Linux文件存储在ChunkServer上）
（1）减少Clinet与Master的通信
（2）减少Master的元数据的存储
（3）Client可以对文件块进行多次操作，减少I/O压力
3、元数据
主要包括：命名空间、文件和Block的映射关系（文件包括哪些Block）、每个Block副本的存放文章信息。
存储：元数据存储在Matser服务器的内存中，这样可以快速查找，性能好，但是由于Master内存有限制。
* 命名空间及文件和Chunk的映射关系，均以记录变更日志的方式落地为系统日志文件，并复制到远程Master备机上。
*Block副本的位置信息为Master周期性向各个ChunkServer轮询获得 => 没有落地，避免了ChunkServer变更时的Master和ChunkServer的数据同步问题
* 操作日志记录了关键元数据变更历史，对Master的容灾非常重要，故只有在元数据变更持久化到日志后，才会对Client可见。为了避免操作日志过长，GFS定期会对当前操作日志做一次Checkpoint，以压缩 B+树形式存储为一个CheckPoint文件。
* 故Master的恢复只需最新的CheckPoint文件和后续的操作日志。
4、存储访问流程：首先，客户端把文件名和程序指定的字节偏移，根据固定的block大小，转换成文件的block索 引。然后，它把文件名和block索引发送给Master节点。Master节点将相应的block标识和副本的位置信息发还给客户端。客户端用文件名和 block索引作为key缓存这些信息。之后客户端发送请求到其中的一个副本处，一般会选择最近的。请求信息包含了block的标识和字节范围。在对这个block的后续读取操作中， 客户端不必再和Master节点通讯了，除非缓存的元数据信息过期或者文件被重新打开。实际上，客户端通常会在一次请求中查询多个block信息。
下面简单解释下在单点Master下一次简单的读取过程：
（1）客户端向Master发送请求，请求信息为（文件名，块索引）
（2）Master使用心跳信息监控块服务器的状态，并向其发送指令。
（3）块服务器需要周期性的返回自己的状态给Master，以确保能够接收Master的请求。
（4）Master将（块句柄，块位置）这一信息返回给客户端
（5）客户端使用文件名和块索引作为Key进行缓存信息。然后，客户端发送请求到其中的一个副本中（通常为最近的），该请求包括（块句柄，字节范围）。对这个块的后续操作，客户端无需再和Master进行通信，除非缓存信息过期或者文件被重新打开。
（6）块服务器将所需的块数据发送给客户端。
hadoop是的hdfs是基于GFS设计实现的。因此它们的原理是一样。现在hadoop到处都是，所以对于GFS就总结这些，具体的介绍留着在hadoop的HDFS中说明。
参考：http://www.open-open.com/lib/view/open1328763454608.html
http://www.open-open.com/lib/view/open1386577681689.html
分布式文件系统--GFS