Google关于大数据处理的论文简述概述.docVIP

Google关于大数据处理的论文简述 2013年4月 目录 一、简述 3 二、Google经典三篇大数据论文介绍 3 2.1、GFS 3 2.2、MapReduce 5 2.3、BigTable一个分布式的结构化数据存储系统 6 三、Google新大数据论文介绍 6 3.1、Caffeine：处理个体修改 7 3.2、Pregel：可扩展的图计算 8 3.3、Dremel：在线可视化 8 四、总结 12 一、简述 陆续 从2010年之后、Google三篇大数据论文介绍 三篇论文主要阐述： GFS 公布时间：。GFS阐述了Google File System设计原理，GFS是 GFS完全满足了我们对存储的需求。GFS作为存储平台已经被广泛的部署在Google内部，存储我们的服务产生和处理的数据，同时还用于那些需要大规模数据集的研究和开发工作。 目前为止，最大的一个集群利用数千台机器的数千个硬盘，提供了数百TB的存储空间，同时为数百个客户机服务。 为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统(Google File System –GFS)。GFS 与传统的分布式文件系统有着很多相同的设计目标，比如，性能、可伸缩性、可靠性以及可用性。但是，我们的设计还基于我们对我们自己的应用的负载情况和技术环境的观察的影响，不管现在还是将来，GFS 和早期文件系统的假设都有明显的不同。所以我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。 首先，组件失效被认为是常态事件，而不是意外事件。GFS 包括几百甚至几千台普通的廉价设备组装的存储机器，同时被相当数量的客户机访问。GFS 组件的数量和质量导致在事实上，任何给定时间内都有可能发生某些组件无法工作，某些组件无法从它们目前的失效状态中恢复。我们遇到过各种各样的问题，比如应用程序bug 、操作系统的bug 、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效等造成的问题。所以，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在GFS 中。 其次，以通常的标准衡量，我们的文件非常巨大。数GB的文件非常普遍。每个文件通常都包含许多应用程序对象，比如web文档。当我们经常需要处理快速增长的、并且由数亿个对象构成的、数以TB的数据集时，采用管理数亿个KB大小的小文件的方式是非常不明智的，尽管有些文件系统支持这样的管理方式。因此，设计的假设条件和参数，比如I/O 操作和Block的尺寸都需要重新考虑。 第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对文件的随机写入操作在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是按顺序读。大量的数据符合这些特性，比如：数据分析程序扫描的超大的数据集；正在运行的应用程序生成的连续的数据流；存档的数据；由一台机器生成、另外一台机器处理的中间数据，这些中间数据的处理可能是同时进行的、也可能是后续才处理的。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保证的主要考量因素。 第四，应用程序和文件系统API的协同设计提高了整个系统的灵活性。比如，我们放松了对GFS 一致性模型的要求，这样就减轻了文件系统对应用程序的苛刻要求，大大简化了GFS 的设计。我们引入了原子性的记录追加操作，从而保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性。本文后面还有对这些问题的细节的详细讨论。 Google已经针对不同的应用部署了多套GFS 集群。最大的一个集群拥有超过1000个存储节点，超过300TB的硬盘空间，被不同机器上的数百个客户端连续不断的频繁访问。 2.2、MapReduce 公布时间： 2.3、BigTable一个分布式的结构化数据存储系统 公布时间： 老三篇即使我们常用的Hadoop系统的设计理论基石。 三、大数据论文介绍 的理论基础来自以下三篇论文主导Caffeine、Pregel、Dremel。 3.1、Caffeine：处理个体修改：010年。 Google并没有止步于MapReduce。事实上，随着Internet的指数增长，从零开始重算所有搜索索引变得不切实际。取而代之，Google开发了一个更有价值的系统，同样支持分布式计算系统。Google Caffeine是google全球数据中心网络上的新的搜索基础设施——是基于分布式数据处理系统Percolator的。Percolator引入了事务，而一些NoSQL数据库仍然在强调得到高扩展性的同时你必须牺牲（或者不再需要）事务处理。它是一个增量处理平台——一种可以持续更新Google公司的核心搜索索引而不需要从头开始处理所有数据的