小白在学云计算—GFS

          云计算的实现让我能够对大规模的数据进行处理，获得我们需要的信息。通过云计算，我们可以在成千上万的数据中快速，准确的得到我们想要的信息。然而，有一点我们不能忽略，那就是云计算的实现在依赖大规模分布式计算集群的同时，同样依赖海量的数据输入。可以说，没有“大数据”，就无法“云计算”。那么，对于云计算所需要的海量数据，我们怎么去提供呢？很显然，储存这些数据是我们能够提供数据的前提。这里，Google公司为我们提供了一套可靠的、便捷的文件系统，用来储存我们所需要的海量的数据，它就是GFS（Google File System）。
一：什么是GFS？
          根据官方的说法：GFS是一个分布式的结构化数据储存系统，它被用来处理海量数据（通常是分布在数千台普通服务器上的PB级数据）。
          很显然，GFS作为用来储存数据的文件系统，保证数据的稳定、完整，实现数据的快速读取和写入是这个文件系统必须具备的特征。既然面向的是PB级的数据，便意味着储存的文件普遍会比较大，GB级的文件非常普遍。在这种条件下，对于储存的基本单元的大小（BLOCK的尺寸）、I/O操作等都需要特殊的考量。其次，作为一个用于处理PB级数据的分布式文件系统，GFS将会被部署在几百台至几千台普通、廉价的储存设备上，所以组件失效被认为是一种常态，而非意外事件。
二：GFS的设计预期
          1， 正如前文所说，GFS将被部署在一个有廉价的储存集群上，那么机器故障将会是一种常态，所以GFS必须具备强大的错误侦测、灾难冗余以及失效数据的自动恢复的性能。
          2， GFS必须具备储存一定数量大问价的能力。在设计之初，GFS工程师们便预计将会有几百万分文件，文件的大小也将在100MB以上，甚至为经常性的出现几个GB的文件。因此，GFS不但要具备储存这下数据文件的能力，还必须能够快速的提供这些数据的读写。
          3， 需要保证文件的一致性。很显然，PB级的数据将不可能通过一台客户机操作。GFS实际的运行中将会面对来自不同网络环境的不同上千个客户机群体。那么怎么在不同的客户机对同一问价的同时读取时保证数据的一致性，是GFS处理数据的主要难点。另外，处于对数据安全的考虑，GFS中的文件通常会被复制成三分，形成三个副本。那么在三个副本同时被三个客户机访问时，怎么保证副本的一致性，也是GFS需要考虑并处理的问题。
          4， 在网络带宽有限的情况下必须保证能够大批量高速率的处理数据。相对于较为丰富的储存空间，网络将会是非常稀缺的资源，所以GFS必须保证整个集群能够快速的进行数据的交换和信息的传输，以保证这个系统能够高速的处理数据。

三：设计细节
           GFS为了实现上面的设计预期，在普通的分布式文件系统之上做出了相当大的调整。在很多的细节上面，也做了精心的设计。
          1， master节点的设计。GFS中使用了单一的master节点来管理整个系统。这样的决策大大简化了GFS的设计。单一的master节点能够通过全局的信息精确定位Chunk（实际用于储存数据的单元）的位置以及进行复制、修改的操作的决策。在master节点中，将储存每个Chunk的元数据（包括数据储存的位置、副本的复制因素、修改操作的日志信息等），并且会使用心跳信息周期性地和CHUNK服务器进行通信，以获取Chunk服务器的状态信息。
          2， 客户端访问数据的方式。考虑到网络带宽的限制，如果客户机长期和master节点保持通信，master节点将会在大量客户机同时访问时成为热点，影响到系统数据的读写速率。所以在实际操作中，客户机在读取文件时只会和master节点产生短暂的通信。在获取需要访问的文件所在的chunk的元素据后，客户机将会断开和master节点的通信，转而直接和chunk服务器进行通信。因为这个设计，在实际使用中，master的通信压力相当小，所需的网络带宽也始终处于可以接收的范围内。
          3， Chunk尺寸的设计。Chunk是储存数据的最小单元，那么chunk尺寸的设计就成了影响系统效率的重要因素。在GFS中，选择了64MB。这种选择主要是出于GFS是用来处理大文件(一般是GB级及以上)的前提。较大的Chunk尺寸保证了数据的读写和查找的效率。同时由于文件本省普遍比较大，chunk尺寸较大产生的空间浪费将会可以忽略。对于小文件的处理，一般会通过数据的合并来转换成较大的文件，从而保证了系统对于小文件的处理效率。
          4， 建立操作日志。如果说副本是保证chunk服务器产生异常后保证数据稳定的方式，那么操作日志这是用来保证master服务器产生异常后能够快速的实现系统功能的恢复。master节点进行每一次操作都将被操作日志记录。操作日志信息会被复制到多台远程主机，以保正master信息永远不会丢失。为了使master尽快的恢复，必须保证操作日志足够的小。因此，在操作日志增长到一定量是，master服务器会对系统做一次checkpiont，将操作日志信息写入一个Checkpoint文件中。在灾难恢复时，master服务器会从磁盘上读取这些文件以及重演之后的有限个的操作日志文件来恢复系统。
          5， Master和chunk间签订租约（lease）。这其实是为了保证不同chunk副本间的一致性。在对chunk进行操作的时候，如果不同的客户端访问了不同的副本，并分别进行的写操作，那么不同的副本件就很难保证一致性。对于这种问题，GFS选择了master节点和chunk节点签订lease的方法。在对chunk的副本进行操作是，master节点会选择其中一个副本，并与它签订租约。这个副本就叫做主副本。由主副本来对chunk副本的所有操作进行序列化，所有的副本都遵循这个顺序进行修改操作。这样的设定即保证了副本间的一致性，有大大减轻了master节点的管理负担。

四：小结
           GFS向我们展示了一个使用普通硬件支持大规模数据处理的系统的特质。通过GFS，我们可以利用普通的计算机集群来实现庞大数据的稳定存储和快速读取。然而这个文件系统也并非没有缺陷，高度的定制化便是影响其适用于所有工程的因素。对于Google内部不同的产品，GFS都会根据其特殊的需求进行定制，来使得GFS能够满足不同系统的不同要求。因此，在实际使用中，我们一般不会直接使用到GFS，而是使用相同的替代品（HDFS，Hadoop Distribute File System）。这种用于Hadoop品台的文件系统在功能上与GFS相同，但更具有普遍性，更适用于实际云计算平台的搭建。