Google大数据论文GFS(Google File System)介绍

最新推荐文章于 2024-08-20 16:48:22 发布

长破藏书

最新推荐文章于 2024-08-20 16:48:22 发布

阅读量2k

点赞数 3

分类专栏：读书笔记文章标签： big data

本文链接：https://blog.csdn.net/dddgg__/article/details/119328289

版权

读书笔记专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Google大数据论文GFS(Google File System)介绍

众所周知，现在大数据技术的应用越来越成为一种趋势，但是很多人只是听过一个名词，并不真正的了解大数据具体是在进行什么样的工作。

根据百度百科上的定义：大数据（big data） 是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

我们说通俗一点就是：大数据是按照普通的手段，无法处理得到理想结果的海量的数据。因此我们需要用新的手段对这些海量的数据进行处理。

首先我们要来对 “ 海量数据 ” 这个概念进行理解，什么叫做海量数据呢。首先我们要对数据的数量级有一个认识。

数据最小的基本单位是bit，而1bit就相当于1个0/1，在计算机的底层，数据都是以0/1的形式存在的，也就是我们俗称的 “机器码” 。而数据按从小到大的顺序给出所有单位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。他们之间的都是1024的进率。

对这几个单位可能没有什么很直观的概念，这里我来给大家举几个例子：

人类历史上说过的所有的话储存在电脑里面，差不多只有1EB级别。
1PB的容量约等于小时候我们看的250000张DVD的容量，我们就算一天看一张DVD，大约要看680年才能看完。
1PB的数据按照百兆宽带全速下载（100M/s），要下载两年半才能下完

现在大家可能明白了PB的数据量是惊人的。然后再给大家猜一个问题，你知道谷歌每天要处理的数据量有多大吗？
答案是：20PB！

因此大家可能对于我们今天的所强调的 海量数据 有了一个直观的感受。

以前一台单独的普通计算机（或者服务器），处理数据的速度是以KB/s为单位的，但是我们现在明显感受到，在大数据的领域，如果依然按照KB/s的处理能力来处理数据，那么只会使得系统陷入停滞或者瘫痪。

因此我们亟需设计一种拥有强大的数据采集、存储、处理的系统，这也是我们大数据主要解决的问题。

大数据的起源来源于google的三篇论文：《Google File System》(GFS)、《MapReduce》、《BigTable》。为什么这三篇论文都是google发表的呢？因为创新来源于需求，作为世界上最庞大的数据体，google每天的搜索量达到了惊人的30亿次，平均每秒钟都有3.4万个问题被搜索。因此google也最先遇到了需要设计一个庞大的系统来处理如此海量的数据。

《Google File System》(GFS) 这篇论文，就像是一篇设计文档一样，具体的描述了google如何去设计一个分布式的文件管理系统，来对每天产生的海量数据进行管理、储存、修改、访问。

因为谷歌公布了其技术论文，更有国外类似如Hadoop的等开源框架的具体实现，国内的许多互联网大厂才能在此基础上设计自己的分布式文件管理系统，例如淘宝的TFS（Taobao File System） 、**百度的BFS（Baidu File System）**等等。

作为大数据的 “开山鼻祖”，进来我们就来简单了解一下google的 《Google File System》(下文简称GFS)。

设计预期

在GFS的开篇中就说到，这个系统在设计之初就是希望设计成一个分布式的文件系统，其中整个系统由许多普通且廉价的服务器组成（大约几百台或者上千台）。系统设计完成必须要满足这么几个预期：

性能：这个系统要求对于数据的吞吐量必须要达到MB/s、GB\s甚至是TB/s的级别，这样在一瞬间有海量的数据涌来的时候，才能对这些数据进行处理。
可伸缩性：因为组成系统的每台服务器都是普通的服务器，因此每台服务器随时都有损坏、报废的可能，因此必须使得系统能够自动的检测哪些服务器出现了问题，并且可以自动的对其进行处理，不需要使得整个系统断电，就能动态的改变服务器的数量。这样的性能非常的重要，不但体现在服务器损坏时可以自动的修复，更加体现在比如 **“双十一”**时，这时候的数据量肯定比以往的数据量更加的庞大，因此需要的服务器的数量就更多，因为需要系统可以根据实时的需要，来决定使用的服务器的资源的多少，这样的 可伸缩性 使得整个系统的更加的灵活。
可靠性：这里的可靠性就是指系统需要有很强的容错能力，比如上文提到的，如果服务器突然损坏，怎么来保证数据不丢失，更有甚者，比如发生了自然灾害，整个数据中心崩溃，怎么来恢复数据，保证系统能继续进行正常的工作。还有在日常的一些对数据的访问的过程中，如果系统发生了物理上的异常，比如发生了0/1的跳变，那如何来进行容错，这些都是设计整个系统的可靠性时，需要进行考虑的东西。
可用性：可用性指用户如何来对数据进行访问、修改、追加、复制等操作，同时需要保证多个客户端并行（同时）的访问或者修改同一个数据时，怎么才能保证数据的一致性，是使得数据的修改不混乱，保证下一次读取时，数据时可用的，不是混乱的数据。

系统架构（系统怎么工作的）

GFS中包含了数百台服务器（普通的计算机），一个服务器就是一个节点，其中有一台服务器最特殊，叫做 “Master节点”，他是所有服务器的老大，其余的服务器都叫做 “Chunk节点”，整个系统叫做一个集群，而海量的数据都是存储在集群上的，同时数据的计算和处理也是基于集群工作的。

Master节点：Master节点是储存什么的呢?Master节点储存的是 “元数据”，说通俗点，储存的就是每一个Chunk数据的位置，以及每一个Chunk节点储存了哪些数据。注意：master节点不存储具体的数据，具体的数据都存储在chunk节点上，Master节点相当于一个目录，你通过master节点就可以查到你想要的数据存储在哪一个chunk节点上，以及这个chunk节点的具体位置在哪里。
chunk节点： chunk节点用来存储具体的数据，其中的数据是一块一块的划分的，我们称作块数据，一块的大小为大概128M。注意：为了保证容错性，我们一般会使用3个chunk来存储相同的数据，也就是说将一份数据备份3份，这样当一个chunk出错或者损坏时，可以通过另外两份备份的数据，快速的将当前chunk的数据进行恢复。

下面举一个例子来说明，当客户端需要访问或者修改时，系统的交互流程：

客户端访问master节点，master节点根据客户端需要访问的数据，查找自身存储的索引信息，找到对应的chunk节点的位置和索引范围；
master节点返回chunk节点的位置，以及chunk节点中块数据（block）的范围，注意：因为相同的信息一般会存储在3个chunk节点当中，因此这里master节点会根据相应的算法来寻找距离最近的chunk节点，作为主chunk
客户端获取到chunk的位置和数据区域以后，和主chunk进行连接，访问主chunk内的数据，不再和master进行交流 注意：在没有意外的情况下，客户端一般是和主chunk进行交互，如果读数据有修改，再由主chunk将数据同步到其他的chunk之中
客户端访问chunk完成后，chunk向master进行通信，更新master内存储的数据区域的位置，保证客户端下次读取时数据的正确。

这就是比较的简单的一次客户端访问系统时产生的一些交互流程，在这里有一些补充的注意点：
尽量减少对Master的访问：虽然我们使用的服务器都是普通且廉价的，但是master节点依然占有比较重要的位置，如果master节点损坏的话，会对整个系统产生比较严重的影响，因此我们应该尽量的减少对master节点的访问。而且master节点的数量相比于chunk节点很少（一般1个集群1台master节点），如果所有的客户端访问该系统都需要频繁的和master节点进行交互的话，必然会严重降低系统的并行处理数据的性能，不符合我们整个系统大吞吐量的设计目标，因此，一般来说客户端每次访问系统只需要和master进行一次交互，在获取了相应的chunk的位置和数据范围后，以后的操作都直接和chunk进行交互就ok了，这样就避免了频繁的和master进行交互。
主chunk失效不需要重新访问master： 这里还有一个细节，master在返回chunk的位置和数据范围时，并不是只返回主chunk的位置和数据范围，而是连带着将其与两个chunk的位置和范围也一并返回，这样如果客户端访问主chunk失败，可以直接访问其他的两个chunk，不需要再和master进行交互。
“数据流”传输：chunk之间的数据传递是通过数据流的形式进行的。什么意思呢，比如，客户端在向主chunk进行写数据时，并不是说等全部写完了以后，主chunk再把数据同步到另外两个chunk。主chunk是一边接收，一边传输，收到多少数据，就把数据同步到另外两个chunk，因此也叫 “管道传输”。 这样做的目的也是为了提高系统的吞吐量性能，另外两台服务器不需要进行等待，可以进行工作。
主chunk“限时租约，超时收回”： master指定一台chunk节点作为主节点时，这个过程叫做 “租约”，租约一般是有时间限制的，当时间超出后，master会重新给客户端分配主chunk，这叫做 “租约更改” 。这样做的主要目的是为了防止主chunk内陷入死循环或者损坏时，系统的工作无法继续进行。