Google File System 见解 (作业)

Google File System

——见解

   近年来，大街小巷都传遍的大数据，引起了社会的一阵学习大数据狂热，造成任何公司在招聘人员的时候都会注上一条，会大数据的优先考虑；但是，从另一方面来说，这狂热是否是正确的，还有对大数据有多少人能真正的了解呢？它的理论基础是什么，是什么促进了大数据的狂热。下面是我对大数据以及诞生它的理论基础论文的见解。

   首先，大数据是什么。我想做个简单的介绍，大数据是当数据大到人类已经无法处理的地步，才被认可为大数据。而不是平常我们的书本知识或者生活的数据能比拟的。而是远远超过了人类的存储能力，且无法快速处理的数据。这是我对大数据的看法。当然，官方的定义是，大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。                                                

为什么只在计算机出现后才会被重视，大数据并不是现在才诞生，而是从古往今都有这个观点，只是因为古时候数据的存储极为不方便；况且，众观历史，流传下来的都是经过加工的数据，即称为信息。而不是原始的数据，这已经不是大数据中的原始数据了，而是被加工过后的数据。而电子计算机出现后，数据的存储大大简化了，一个硬盘既可以存储许多知识，目前有关记载的数据应该不会超过100PB，但是100PB对于现代而言，数据量是多么的渺小，所以大数据出现之所以在计算机出现后才被重视是因为得利于存储方式的改变，存储量的改变。

Google File System是大数据的理论基础论文，也是给出了独特的见解。

   以下是我对Google File System的见解。

   GFS是一个可扩展的分布式文件系统，用于大型的、对大量的、分布式的数据进行访问的应用。同时它是运行于廉价的普通硬件上。从本质上来说，文件会被分割成固定大小的块(Chunk)，存储在廉价服务器上，至少存储三份。

   GFS由一个master和大量的chunkserver(chunk服务器)组成，同时可以被多个Client(客户端)访问；每一个文件都被拆成固定大小的块(Chunk)并由master产生一个全局唯一的不会改变的64b的chunk handle标志。存储在多台chunk服务器上。缺省情况下(也可以称为系统默认状态default),保存3个备份。如果master挂了，会有后备的master顶上，如果所有后备的master都挂了；那就需要从chunkserver中选取一个来充当master，而这个chunkserver是性能较为优秀的服务器，如果这个chunkserver被选举成master后又挂了，就需要通过再从剩余的chunkserver中选举master，直至所有chunkserver都挂了，这个选举行为才会结束，同时这个服务也会停止。

         Master：管理元数据、协调整体系统的活动

         Chunkserver：存储并维护数据块，可以进行读写操作。

         Client：向master请求元数据，并根据master给的信息去访问对应的chunkserver。

 

   首先，我先解释下元数据的意思，它在数据库里是表示一行的信息，一行可以有多列信息。比如，计算机的一个文件元数据有，名称、修改日期、文件类型、大小等信息；可能也含有别的意思。

Master和chunkserver的关系就是以下的解释，通过以上对元数据的解释，master就是只需要管理重要的信息如名字、控制信息、文件大小、文件存储在chunkserver的位置等属性，而文件并不存在master上，否则master会无法抵御大量的client访问，而是把数据存储到chunkserver中，类似于DNS（域名系统）的结构，顶层DNS服务器(可以看成master)只负责传递相邻层的域名服务器的信息，而不存储具体的域名服务信息，而是由下层的DNS服务器(可以看做chunkserver)负责存储域名服务信息，而顶层DNS服务器只是负责存储转发、映射DNS服务器间的信息，而不是真正的存储域名服务信息。当然，master需要在规定的时间向chunkserver发包，如果chunkserver没有回复，然后master再重发，如果chunkserver再没有回复，即可认为chunkserver挂掉了，当然也可以通过反向来监视master是否挂掉了。当然重发包的次数和重发包的间隔有规定，而不是简单以上的两次即可。

         然后client需要访问数据(Data)时，需要先和master进行信息的交流，可能通过三次握手等方式，从master上传回client所需的元数据信息，比如数据保存在chunkserver的位置等信息，当然master是通过map(Key-value)返回的一对键值对，可能通过集合返回所需信息吧。然后client就从master传回的map中找到所需要的数据存储在哪个chunkserver位置的的信息，然后通过该信息，找到存储在chunkserver上的数据，并提取所需要的数据。至此client提取数据的路径也已经完成。总结来说，就是client从master上拿到元数据，然后所有的数据传输等操作都是client和chunkserver完成的，而master只是在开头提供给client信息然后，不参与数据的操作。

   至此，以上是我对大数据和Google File System的见解，说的有点不是那么通畅，文笔不算太好，不过通过Google File System让我大致懂得了一些关于这方面的知识；当然，这里面还有许多的不足，希望通过后期的学习，能更系统化的了解大数据的本质核心。