分布式文件系统--GFS

时间 2019-12-11

原文原文链接

前言：Google大数据处理的3篇核心论文html

《The Google File System》：http://research.google.com/archive/gfs.htmlnode

《MapReduce: Simplified Data Processing on Large Clusters 》：http://research.google.com/archive/mapreduce.htmllinux

《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之间的位置映射已经其余一些元数据信息。

一、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服务器宕机了，它就体现价值了。有点映像的感受，固然它还有其余好多功能。

二、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压力

三、元数据

主要包括：命名空间、文件和Block的映射关系（文件包括哪些Block）、每一个Block副本的存放文章信息。

存储：元数据存储在Matser服务器的内存中，这样能够快速查找，性能好，可是因为Master内存有限制。

* 命名空间及文件和Chunk的映射关系，均以记录变动日志的方式落地为系统日志文件，并复制到远程Master备机上。

*Block副本的位置信息为Master周期性向各个ChunkServer轮询得到 => 没有落地，避免了ChunkServer变动时的Master和ChunkServer的数据同步问题

* 操做日志记录了关键元数据变动历史，对Master的容灾很是重要，故只有在元数据变动持久化到日志后，才会对Client可见。为了不操做日志过长，GFS按期会对当前操做日志作一次Checkpoint，以压缩 B+树形式存储为一个CheckPoint文件。

* 故Master的恢复只需最新的CheckPoint文件和后续的操做日志。

四、存储访问流程：首先，客户端把文件名和程序指定的字节偏移，根据固定的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