⑴ 谷歌的分布式文件系统的优缺点
Google File System 文件系统为了满足Google迅速增长的数据处理需求，Google设计并实现了Google文件系统(GFS，Google File System)。GFS与过去的分布式文件系统拥有许多相同的目标，例如性能、可伸缩性、可靠性以及可用性。然而，它的设计还受到Google应用负载和技术环境的影响。主要体现在以下四个方面:1. 集群中的节点失效是一种常态，而不是一种异常。由于参与运算与处理的节点数目非常庞大，通常会使用上千个节点进行共同计算，因此，每时每刻总会有节点处在失效状态。需要通过软件程序模块，监视系统的动态运行状况，侦测错误，并且将容错以及自动恢复系统集成在系统中。2. Google系统中的文件大小与通常文件系统中的文件大小概念不一样，文件大小通常以G字节计。另外文件系统中的文件含义与通常文件不同，一个大文件可能包含大量数目的通常意义上的小文件。所以，设计预期和参数，例如I/O操作和块尺寸都要重新考虑。3. Google文件系统中的文件读写模式和传统的文件系统不同。在Google应用(如搜索)中对大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。对文件的随机写是几乎不存在的。对于这类巨大文件的访问模式，客户端对数据块缓存失去了意义，追加操作成为性能优化和原子性(把一个事务看做是一个程序。它要么被完整地执行，要么完全不执行)保证的焦点。4. 文件系统的某些具体操作不再透明，而且需要应用程序的协助完成，应用程序和文件系统API的协同设计提高了整个系统的灵活性。例如，放松了对GFS一致性模型的要求，这样不用加重应用程序的负担，就大大简化了文件系统的设计。还引入了原子性的追加操作，这样多个客户端同时进行追加的时候，就不需要额外的同步操作了。总之，GFS是为Google应用程序本身而设计的。据称，Google已经部署了许多GFS集群。有的集群拥有超过1000个存储节点，超过300T的硬盘空间，被不同机器上的数百个客户端连续不断地频繁访问着。
⑵ 5. google文件系统gfs有什么不足
1、部件错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统由成百上千个用于存储的机器构成，而这些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。2、按照传统的标准，文件都非常大。长度达几个GB的文件是很平常的。每个文件通常包含很多应用对象。当经常要处理快速增长的、包含数以万计的对象、长度达TB的数据集时，我们很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考虑。对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。3、大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据。在一个文件中随机的操作在实践中几乎不存在。一旦写完，文件就只可读，很多数据都有这些特性。一些数据可能组成一个大仓库以供数据分析程序扫描。有些是运行中的程序连续产生的数据流。有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据。由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点。而在客户机中缓存数据块则失去了吸引力。4、工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百 KB，通常达1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个 KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。5、工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作。所写的数据的规模和读相似。一旦写完，文件很少改动。 在随机位置对少量数据的写操作也支持，但不必非常高效。6、系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。
⑶ hadoop和谷歌的maprece、gfs等技术之间的关系。
简单点来说，就是Hadoop是继承了Google的MapRece、GFS思想，开发出来的一套框架，后来又交给了Apache作为开源项目。MapRece诞生于谷歌实验室，MapRece与GFS、BigTable并称为谷歌的三驾马车，、而Hadoop则是谷歌三驾马车的开源实现。2003年，Google发表了一篇技术学术论文谷歌文件系统（GFS）。GFS是google公司为了存储海量搜索数据而设计的专用文件系统。2004年，Nutch创始人Doug Cutting基于Google的GFS论文实现了分布式文件存储系统名为NDFS。2004年，Google又发表了一篇技术学术论文MapRece。MapRece是一种编程模型，用于大规模数据集（大于1TB）的并行分析运算。2005年，Doug Cutting又基于MapRece，在Nutch搜索引擎实现了该功能。2006年，Yahoo雇用了Doug Cutting，Doug Cutting将NDFS和MapRece升级命名为Hadoop，Yahoo开建了一个独立的团队给Goug Cutting专门研究发展Hadoop。
⑷ google用的是什么操作系统，Windows还是Linux
Google拥有自己的文件系统，称为"Google文件系统"，这一系统专门针对处理大型数据进行了优化，它能够处理64MB大小的数据块。更为重要的是，它能够应付随时可能发生的磁盘或网络故障。外Google的数据被复制三份，并存放在不同地方，这样确保万无一失。凭借这些应付故障的措施，PC就完全可以担负互联网搜索服务的重任。 Google数以千计的PC服务器运行一种基于Red Hat版本的简化版Linux，该系统内核已经针对Google的特殊应用进行了修改。 Google还设计了一种能够处理大量数据而迅速响应查询的系统。Google将整个Web划分为数以百万计的碎片，以Google的技术术语这些碎片被称为shard，它能在系统出错的时候被复制。 Google创建了一个出现在Web上的词汇索引，而且它还有文档服务器存储着Google现在的页面。 Google在数据中心管理方面另一个重要的技术创新是编写出能够在数以千计的服务器上平滑运行的软件系统。通常情况下，开发在多个服务器上并行运行的软件系统需要专门的编程工具和机巧。 Google的编程工具称为MapRece，在系统出错的情况下，它能自动恢复整个程序，而这对削减成本至关重要。从去年开始，Google已经开始大规模使用MapRece编程工具。 此外，Google还开发了批量任务调度软件Global Work Queue，能对上百万的操作进行调度安排。该软件系统能够将任务分解成许多更小的计算操作，并将它们分配给各台计算机完成。 为了解决紧急灾难性问题，Google还准备了6辆救火车，以应对Google数据中心发生的紧急事件。此外，电力成本是Google数据中心设计中的另一个重要因素。由于采购了更多廉价计算设备，整体功耗就会增加，为此控制电力开支也是Google设计数据中心必须考虑的一个主要问题。
⑸ Hadoop辉煌还能延续多久
Hadoop技术已经无处不在。不管是好是坏，Hadoop已经成为大数据的代名词。短短几年间，Hadoop从一种边缘技术成为事实上的标准。看来，不仅现在Hadoop是企业大数据的标准，而且在未来，它的地位似乎一时难以动摇。
谷歌文件系统与MapRece
我们先来探讨一下Hadoop的灵魂——MapRece。面对数据的爆炸性增长，谷歌的工程师Jeff Dean和Sanjay Ghemawat架构并发布了两个开创性的系统：谷歌文件系统（GFS）和谷歌MapRece（GMR）。前者是一个出色而实用的解决方案-使用常规的硬件扩展并管理数据，后者同样辉煌，造就了一个适用于大规模并行处理的计算框架。
谷歌MapRece（GMR）为普通开发者/用户进行大数据处理提供了简易的方式，并使之快速、具备容错性。谷歌文件系统（GFS）和谷歌MapRece（GMR）也为谷歌搜索引擎对网页进行抓取、分析提供了核心动力。
再回头看看开源世界中的Hadoop，Apache Hadoop的分布式文件系统（HDFS）和Hadoop MapRece完全是谷歌文件系统（GFS）和谷歌MapRece（GMR）的开源实现。Hadoop项目已经发展成为一个生态系统，并触及了大数据领域的方方面面。但从根本上，它的核心是MapRece。
Hadoop是否可以赶超谷歌？
一个有趣的现象是，MapRece在谷歌已不再显赫。当企业瞩目MapRece的时候，谷歌好像早已进入到了下一个时代。事实上，我们谈论的这些技术早就不是新技术了，MapRece也不例外。
我希望在后Hadoop时代下面这些技术能够更具竞争性。尽管许多Apache社区的项目和商业化Hadoop项目都非常活跃，并以来自HBase、Hive和下一代MapRece（YARN）的技术不断完善着Hadoop体系，我依然认为，Hadoop核心（HDFS和Zookeeper）需要脱离MapRece并以全新的架构增强自己的竞争力，真正与谷歌技术一较高下。
过滤不断增长的索引，分析不断变化的数据集。Hadoop的伟大之处在于，它一旦开始运行，就会飞速地分析你的数据。尽管如此，在每次分析数据之前，即添加、更改或删除数据之后，我们都必须将整个数据集进行流式处理。这意味着，随着数据集的膨胀，分析时间也会随之增加，且不可预期。
那么，谷歌又是怎么做到搜索结果越来越实时呈现呢？一个名为Percolator的增量处理引擎取代了谷歌MapRece（GMR）。通过对新建、更改和已删除文档的处理，并使用二级索引进行高效的分类、查询，谷歌能够显著地降低实现其目标的时间。
Percolator的作者写道：“将索引系统转化为一个增量系统……文档平均处理延迟的因子降低到了现在的100。”这句话的意思是，索引Web上新内容的速度比之前MapRece系统快了100倍。
谷歌Dremel即时数据分析解决方案
谷歌和Hadoop社区曾致力于构建基于MapRece的易用性即时数据分析工具，如谷歌的并行处理语言Sawzall，Apache Pig和Hive。但对熟知SQL的人们而言，他们忽略了一个基本事实-构建MapRece的目标就在于管理数据处理工作。它的核心能力在于工作流管理，而不是即时数据分析。
与之形成鲜明对比的是，很多BI或数据分析查询基本上都要求即时、交互和低延迟。这意味着，使用Hadoop不仅需要规划流程图，而且需要为许多查询分析裁减不必要的工作流。即便如此，我们也要花费数分钟等待工作开始，然后花费数小时等待工作流完成，并且这个过程也非常不利于交互式体验。因此，谷歌研发了Dremel予以应对。Dremel是Google 的“交互式”数据分析系统，可以在几秒钟内处理PB级别的数据，并能轻松应对即时查询。
Google Dremel的设计特点：
Dremel是一个可扩展的大型系统。在一个PB级别的数据集上面，将任务缩短到秒级，无疑需要大量的并发。磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的并发读! Google一向是用廉价机器办大事的好手。但是机器越多，出问题概率越大，如此大的集群规模，需要有足够的容错考虑，保证整个分析的速度不被集群中的个别节点影响。
Dremel是MapRece的补充。和MapRece一样，Dremel也需要GFS这样的文件系统作为存储层。在设计之初，Dremel并非是MapRece的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapRece的结果集或者用来建立分析原型。
Dremel的数据模型是嵌套的。互联网数据常常是非关系型的。Dremel还需要有一个灵活的数据模型，这个数据模型至关重要。Dremel支持一个嵌套的数据模型，类似于JSON。而传统的关系模型，由于不可避免的有大量的JOIN操作，在处理如此大规模的数据的时候，往往是有心无力的。
Dremel中的数据是采用列式存储的。使用列式存储，分析的时候，可以只扫描需要的那部分数据的时候，减少CPU和磁盘的访问量。同时列式存储是压缩友好的，使用压缩，可以综合CPU和磁盘，发挥最大的效能。
Dremel结合了Web搜索和并行DBMS的技术。Dremel借鉴了Web搜索中的“查询树”的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询。大事化小，小事化了，能并发的在大量节点上跑。另外，和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样。
谷歌的图数据计算框架Pregel
谷歌MapRece是专门为抓取、分析世界上最庞大的图形架构-internet而设计的，但针对大规模图算法（如图遍历（BFS）、PageRank，最短路径（SSSP）等）的计算则显得效率低下。因此，谷歌构建了Pregel。
Pregel给人的印象非常深刻。Pregel不仅能高效执行SSSP或PageRank算法，更令人惊讶的是，公布的数据显示Pregel处理一个有着几十亿节点、上万亿条边的图，只需数分钟即可完成，其执行时间随着图的大小呈线性增长。
Pregel基于BSP模型，就是“计算”-“通信”-“同步”的模式：
输入输出为有向图
分成超步
以节点为中心计算，超步内每个节点执行自己的任务，执行节点的顺序不确定
两个超步之间是通信阶段
在Pregel中，以节点为中心计算。Step 0时每节点都活动着，每个节点主动“给停止投票”进入不活动状态。如果接收到消息，则激活。没有活动节点和消息时，整个算法结束。容错是通过检查点来做的。在每个超步开始的时候，对主从节点分别备份。
总结
尽管当前大数据技术的核心依然是Hadoop，但谷歌却已经为我们展现了许多更先进的大数据技术。谷歌开发这些技术的本意并不是要立刻抛弃掉MapRece，但毫无疑问这是未来大数据技术的趋势。尽管已经出现了上述大数据技术的开源实现，但我们不禁要问，Hadoop的辉煌还能延续多久？
⑹ 谷歌文件系统中的容错机制主要有哪两部分内容组成
文件系统由三部分组成： 1、文件系统的接口，对对象操纵和管理的软件集合； 2、对象； 3、属性。 文件系统介绍： 文件系统是操作系统用于明确存储设备（常见的是磁盘，也有基于NAND Flash的固态硬盘）或分区上的文件的方法和数据结构，即在
⑺ 如何在google 文件系统中建立文件夹
登陆https://www.google.com/accounts/ServiceLogin?service=writely&passive=true&continue=http%3A%2F%2Fdocs.google.com%2F&followup=http%3A%2F%2Fdocs.google.com%2F<mpl=homepage&nui=1网址 然后输入用户名,密码 就可以了
⑻ 《谷歌如何控制世界》读后感急用速求
我们设计并实现了Google文件系统，一个面向分布式数据密集型应用的、可伸缩的分布式文件系统。虽然运行在廉价的日用硬件设备上，但是它依然了提供容错功能，为大量客户机提供了很高的总体性能。虽然与很多之前的分布式文件系统有很多相同目标，但是，我们的设计已经受应用的负载情况和技术环境影响，现在以及可预见的将来都反映出，我们的设计和早期的分布式文件系统的设想有了显著的分离。这让我们重新审视了传统文件系统在设计上的选择，探索彻底不同的设计点。GFS成功满足了我们的存储需求。其作为存储平台被广泛的部署在Google内部，该平台用来产生和处理数据，这些数据被我们的服务以及需要大规模数据集的研究和开发工作使用。迄今为止，最大的一个集群利用一千多台机器上的数千个硬盘，提供数百TB的存储空间，同时被数百个客户机访问。在本论文中，我们展示了设计用来支持分布式应用的文件系统接口的扩展，讨论我们设计的许多方面，最后对小规模基准测试和真实使用作了测量报告。常用术语设计，可靠性，性能，测量关键词容错，可伸缩性，数据存储，集群存储1. 简介为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统(Google File System–GFS)。GFS与之前的分布式文件系统有着很多相同的目标，比如，性能、扩展性、可靠性以及可用性。但是，我们的设计还受对我们的应用的负载和技术环境的观察的影响，现在以及可预见的将来都反映出，我们的设计和早期的分布式文件系统的设想有了显著的分离。这让我们重新审视了传统文件系统在设计上的选择，在设计上探索了彻底不同的设计点。首先，组件失效被认为是常态事件，而不是意外事件。文件系统由几百乃至数千台由廉价的日常部件组装成的存储机器组成，同时被相当数量的客户机访问。部件的数量和质量事实保证了任意给定时间，一些部件无法工作，一些部件无法从它们目前的失效状态中恢复。我们遇到过如下原因导致的问题，比如应用程序bug、操作系统的bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效。因此，持久的监控、错误侦测、容错以及自动恢复必须集成在系统中。其次，以传统的标准衡量，我们的文件非常巨大。数GB的文件非常普遍。每个文件通常包含许多应用程序对象，比如web文档。当我们定期由数亿个对象构成的快速增长的数TB的数据集时，即使文件系统支持，管理数十亿KB大小的小文件也是不实用的。因此，设计的假设条件和参数，比如I/O 操作和Block的尺寸都不得不重新考虑。第三，绝大部分文件的变更是采用在追加新数据，而不是重写原有数据的方式。文件内部的随机写在实际中几乎不存在。一旦写完之后，文件只能读，而且通常只能顺序读。各种数据符合这些特性，比如：一些可能组成了数据分析程序扫描的超大数据集；一些可能是正在运行的应用程序生成的连续数据流；一些可能是档案数据；一些可能是由一台机器生成、另外一台机器处理的中间数据，同时处理或者稍后适时处理。考虑到这种针对海量文件的访问模式，数据的追加是性能优化和原子性保证的焦点所在，客户端对数据块缓存毫无吸引力。第四，通过增加灵活性，应用程序和文件系统API的协同设计对整个系统有益。比如，我们放松了对GFS一致性模型的要求，不用在应用程序中强加繁重负担，大大简化了文件系统。我们甚至引入了原子性的追加操作，这样多个客户端可以对一个文件同时进行追加操作，不需要他俩之间额外的同步机制。这些问题会在下文进行详细讨论。当前针对不同目的部署了多重GFS集群。最大的一个集群拥有超过1000个存储节点，超过300TB的硬盘存储，被不同机器上的数百个客户端连续不断的频繁访问。
⑼ google文件系统不缓存数据的原因是什么
这个流式读取文件貌似有很多种，不知道楼主所说的类别，给个最常见的吧。我们在网络上看视频，很大一部分是flv格式的，这个格式并非我们经常用的avi rm rmvb mkv等等常见格式，原因就是这个文件允许流式读取，就是说，这边你可以看视频，而你的电脑还在缓冲着下面的文件内容。这个叫做流式读取文件。回答仅供参考，希望对楼主有帮助。
⑽ google云计算技术包括哪些内容
Google云计算的关键技术主要包括：Google文件系统GFS、分布式计算编程模型MapRece、分布式锁服务Chubby和分布式结构化数据存储系统BigTable等。其中：1）GFS提供了海量数据存储和访问的能力；2）MapRece使得海量信息的并行处理变得简单易行；3）Chubby保证了分布式环境下并发操作的同步问题；4）BigTable使得海量数据的管理和组织十分方便。
未经允许不得转载：山九号 » 谷歌文件系统|google用的是什么操作系统Windows还是Linux
