Google大数据发展与应用总结归纳.docx

Google大数据发展与应用总结归纳.docx

《Google大数据发展与应用总结归纳.docx》由会员分享，可在线阅读，更多相关《Google大数据发展与应用总结归纳.docx（11页珍藏版）》请在冰豆网上搜索。

Google大数据发展与应用总结归纳

2019年9月11日

Google大数据技术

IT新技术课题报告

姓名：

王六平

专业名称：

软件工程

一、简述4

二、Google经典三篇大数据论文介绍5

2.1、GFS5

2.2、MapReduce6

2.3、BigTable一个分布式的结构化数据存储系统7

三、Google新大数据论文介绍8

3.1、Caffeine：

处理个体修改8

3.2、Pregel：

可扩展的图计算9

3.3、Dremel：

在线可视化11

四、Google大数据的应用14

一、大数据时代的来临

1.大数据的概念：

按照维基百科上的定义，所谓“大数据”（bigdata）在当今的互联网业指的是这样一种现象：

一个网络公司日常运营所生成和积累用户网络行为的数据“增长如此之快，以至于难以使用现有的数据库管理工具来驾驭”。

这些数据量是如此之大，已经不是以我们所熟知的多少G和多少T为单位来衡量，而是以P（1000个T），E（一百万个T）或Z（10亿个T）为计量单位，所以称之为大数据。

大数据泛指巨量的数据集，因可从中挖掘出有价值的信息而受到重视。

《华尔街日报》将大数据时代、智能化生产和无线网络革命称为引领未来繁荣的三大技术变革。

麦肯锡公司的报告指出数据是一种生产资料，大数据是下一个创新、竞争、生产力提高的前沿。

世界经济论坛的报告认定大数据为新财富，价值堪比石油。

因此，发达国家纷纷将开发利用大数据作为夺取新一轮竞争制高点的重要抓手。

2.大数据的发展

互联网特别是移动2互联网的发展，加快了信息化向社会经济各方面、大众日常生活的渗透。

有资料显示，1998年全球网民平均每月使用流量是1MB（兆字节），2000年是10MB，2003年是100MB，2008年是1GB（1GB等于1024MB），2014年将是10GB。

全网流量累计达到1EB（即10亿GB或1000PB）的时间在2001年是一年，在2004年是一个月，在2007年是一周，而2013年仅需一天，即一天产生的信息量可刻满1.88亿张DVD光盘。

我国网民数居世界之首，每天产生的数据量也位于世界前列。

淘宝网站每天有超过数千万笔交易，单日数据产生量超过50TB（1TB等于1000GB），存储量40PB（1PB等于1000TB）。

XX公司目前数据总量接近1000PB，存储网页数量接近1万亿页，每天大约要处理60亿次搜索请求，几十PB数据。

一个8Mbps（兆比特每秒）的摄像头一小时能产生3.6GB数据，一个城市若安装几十万个交通和安防摄像头，每月产生的数据量将达几十PB。

医院也是数据产生集中的地方。

现在，一个病人的CT影像数据量达几十GB，而全国每年门诊人数以数十亿计，并且他们的信息需要长时间保存。

总之，大数据存在于各行各业，一个大数据时代正在到来。

信息爆炸不自今日起，但近年来人们更加感受到大数据的来势迅猛。

一方面，网民数量不断增加，另一方面，以物联网和家电为代表的联网设备数量增长更快。

2007年全球有5亿个设备联网，人均0.1个；2013年全球将有500亿个设备联网，人均70个。

随着宽带化的发展，人均网络接入带宽和流量也迅速提升。

全球新产生数据年增40%，即信息总量每两年就可以翻番，这一趋势还将持续。

目前，单一数据集容量超过几十TB甚至数PB已不罕见，其规模大到无法在容许的时间内用常规软件工具对其内容进行抓取、管理和处理。

数据规模越大，处理的难度也越大，但对其进行挖掘可能得到的价值更大，这就是大数据热的原因。

3.大数据的特征：

大数据（BigData）是指“无法用现有的软件工具提取、存储、搜索、共享、分析和处理的海量的、复杂的数据集合”。

业界通常用四个V来概括大数据的特征。

数据体量巨大（Volume）。

到目前为止，人类生产的所有印刷材料的数据量是200PB（1PB=210TB），而历史上全人类说过的所有的话的数据量大约5EB（1EB=210PB）。

当前，典型个人计算机硬盘的容量为TB量级，而一些大企业的数据量已经接近EB量级。

数据类型繁多（Variety）。

这种类型的多样性也让数据被分为结构化数据和非结构化数据。

相对于以往便于存储的以文本为主的结构化数据，非结构化数据越来越多，包括网络日志、音频、视频、图片、地理位置信息等，这些多类型的数据对数据的处理能力提出了更高要求。

价值密度低（Value）。

价值密度的高低与数据总量的大小成反比。

以视频为例，一部1小时的视频，在连续不间断的监控中，有用数据可能仅有一两秒。

如何通过强大的机器算法更迅速地完成数据的价值“提纯”，成为目前大数据背景下亟待解决的难题。

处理速度快（Velocity）。

这是大数据区分于传统数据挖掘的最显着特征。

根据IDC的“数字宇宙”报告，预计到2020年，全球数据使用量将达到35.2ZB（1ZB=210EB）。

在如此海量的数据面前，处理数据的效率就是企业的生命

二、Google经典三篇大数据论文介绍

Google在2003年到2006年公布了关于GFS、MapReduce和BigTable三篇技术论文。

2.1、GFS

公布时间：

2003年。

GFS阐述了GoogleFileSystem的设计原理，GFS是一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。

GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。

虽然GFS的设计目标与许多传统的分布式文件系统有很多相同之处，但是，我们设计还是以我们对自己的应用的负载情况和技术环境的分析为基础的，不管现在还是将来，GFS和早期的分布式文件系统的设想都有明显的不同。

所以我们重新审视了传统文件系统在设计上的折衷选择，衍生出了完全不同的设计思路。

GFS完全满足了我们对存储的需求。

GFS作为存储平台已经被广泛的部署在Google内部，存储我们的服务产生和处理的数据，同时还用于那些需要大规模数据集的研究和开发工作。

目前为止，最大的一个集群利用数千台机器的数千个硬盘，提供了数百TB的存储空间，同时为数百个客户机服务。

为了满足Google迅速增长的数据处理需求，我们设计并实现了Google文件系统（GoogleFileSystem–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

公布时间：

2004年。

MapReduce是一个编程模型，也是一个处理和生成超大数据集的算法模型的相关实现。

用户首先创建一个Map函数处理一个基于key/valuepair的数据集合，输出中间的基于key/valuepair的数据集合；然后再创建一个Reduce函数用来合并所有的具有相同中间key值的中间value值。

现实世界中有很多满足上述处理模型的例子，本论文将详细描述这个模型。

MapReduce架构的程序能够在大量的普通配置的计算机上实现并行化处理。

这个系统在运行时只关心：

如何分割输入数据，在大量计算机组成的集群上的调度，集群中计算机的错误处理，管理集群中计算机之间必要的通信。

采用MapReduce架构可以使那些没有并行计算和分布式处理系统开发经验的程序员有效利用分布式系统的丰富资源。

我们的MapReduce实现运行在规模可以灵活调整的由普通机器组成的集群上：

一个典型的MapReduce计算往往由几千台机器组成、处理以TB计算的数据。

程序员发现这个系统非常好用：

已经实现了数以百计的MapReduce程序，在Google的集群上，每天都有1000多个MapReduce程序在执行。

2.3BigTable一个分布式的结构化数据存储系统

公布时间：

2006年。

Bigtable是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：

通常是分布在数千台普通服务器上的PB级的数据。

Google的很多项目使用Bigtable存储数据，包括Web索引、GoogleEarth、GoogleFinance。

这些应用对Bigtable提出的要求差异非常大，无论是在数据量上（从URL到网页到卫星图像）还是在响应速度上（从后端的批量处理到实时数据服务）。

尽管应用需求差异很大，但是，针对Google的这些产品，Bigtable还是成功的提供了一个灵活的、高性能的解决方案。

本论文描述了Bigtable提供的简单的数据模型，利用这个模型，用户可以动态的控制数据的分布和格式。

老三篇即使我们常用的Hadoop系统的设计理论基石。

虽然Google没有公布这三个产品的源码，但是根据google发布了这三个产品的详细设计论文。

而且，Yahoo资助的Hadoop也有按照这三篇论文的开源Java实现:

Hadoop对应Mapreduce,HadoopDistributedFileSystem（HDFS）对应Googlefs,Hbase对应Bigtable。

不过在性能上Hadoop比Google要差很多

三、Google新大数据论文介绍

Hadoop来源自Google在2003年底和2004年发表的两篇研究论文。

第一篇介绍了GoogleFileSystem，它是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。

它运行于廉价的普通电脑服务器上，但可以提供容错功能并且可以给大量的用户提供总体性能较高的服务；另一篇介绍的是MapReduce，这是是一种编程模型，用于大规模数据集（大于1TB）的并行运算，能够极大地方便编程人员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上。

八年之后，Hadoop在网络上得到了广泛的使用，应用领域涉及数据分析到各种这样的数值计算任务。

但Google却研发出了更好的技术。

2009年，网络巨头Google开始用新的技术取代GoogleFileSystem和MapReduce。

相应替代的理论基础来自以下三篇论文为主导:

Caffeine、Pregel、Dremel。

3.1、Caffeine：

处理个体修改

公布时间：

2010年。

Google并没有止步于MapReduce。

事实上，随着Internet的指数增长，从零开始重算所有搜索索引变得不切实际。

取而代之，Google开发了一个更有价值的系统，同样支持分布式计算系统。

GoogleCaffeine是google全球数据中心网络上的新的搜索基础设施——是基于分布式数据处理系统Percolator的。

Percolator引入了事务，而一些NoSQL数据库仍然在强调得到高扩展性的同时你必须牺牲（或者不再需要）事务处理。

它是一个增量处理平台——一种可以持续更新Google公司的核心搜索索引而不需要从头开始处理所有数据的方法。

在本质上Caffeine丢弃MapReduce转而将索引放置在由Google开发的分布式数据库BigTable上。

作为Google继GFS和MapReduce两项创新后的又一项创新，其在设计用来针对海量数据处理情形下的管理结构型数据方面具有巨大的优势。

这种海量数据可以定义为在云计算平台中数千台普通服务器上PB级的数据。

在本论文中，Google展示了其网络搜索是如何保持着与时俱进。

Percolator建立于已存类似Bigtable的技术，但是加入了事务以及行和表上的锁和表变化的通知。

这些通知之后会被用于触发不同阶段的计算。

通过这样的方式，个体的更新就可以“渗透”整个数据库。

这种方法会让人联想到类似Storm（或者是Yahoo的S4）的流处理框架（SPF），然而Percolator内在是以数据作为基础。

SPF使用的一般是消息传递而不是数据共享，这样的话更容易推测出究竟是发生了什么。

然而问题也随之产生：

除非你手动的在某个终端上储存，否则你将无法访问计算的结果。

Caffeine大大提升了google搜索速度。

在原有的系统中，Google公司每天爬数以亿万计的文档，把它们和现有文档的集合一起经过约100次MapReduce工序进行处理。

由于系统是顺序的，每个文档都要花2到3天来索引才能出现在google的在线搜索结果中。

Percolator提供对现有的PB级索引数据的随机访问，让google可以更新索引而不需要重新处理所有数据，通过这种方式减少了这个延迟。

“随机访问让我们可以处理单个文档，而不是像MapReduce那样需要对整个数据仓库进行扫描。

”论文中说道。

该系统运行于海量计算机上，通过被称作ACID兼容数据库事务的方式，并行的对索引进行大量修改。

3.2、Pregel：

可扩展的图计算

公布时间：

2010年。

最终Google还需要挖掘图数据，比如在线社交网络的社交图谱；所以他们开发了Pregel，并在2010年公布其论文。

Pregel是一个用于分布式图计算的计算框架主要用于图遍历（BFS）、最短路径（SSSP）、PageRank计算等等。

共享内存的运行库有很多但是对于google来说一台机器早已经放不下需要计算的数据了所以需要分布式的这样一个计算环境。

没有Pregel之前用MapReduce来做,但是效率很低;也可以用已有的并行图算法库ParallelBGL或者CGMgraph来做,但是这两者又没有容错。

Pregel内在的计算模型比MapReduce复杂的多：

基本上每个节点都拥有一个工作者线程，并且对众多工作者线程进行迭代并行。

在每一个所谓的“superstep”中，每一个工作者线程都可以从节点的“收件夹”中读取消息和把消息发送给其它节点，设置和读取节点相关值以及边界，或者投票停止。

线程会一直运行，直到所有的节点都被投票停止。

此外，还拥有Aggregator和Combiner做全局统计。

论文陈述了许多算法的实现，比如Google的PageRank、最短路径、二分图匹配等。

对比MapReduce或SPF，Pregel需要更多实现的再思考。

3.3、Dremel：

在线可视化

公布时间：

2010年。

面对海量数据的分析处理，MapReduce的优势不需多言，其劣势在于时效性较差不满足交互式查询的需求，比如3秒内完成对万亿数据的一次查询等，Dremel应此需求而生，与MapReduce成为有效互补。

Dremel是一个为结构化数据设计，并拥有类SQL语言的交互式数据库。

然而取代SQL数据库使用字段填补的表格，Dremel中使用的是类JSON格式数据（更准确的说，使用Google?

Protocolbuffer格式，这将加强对允许字段的限制）。

内部，数据被使用特殊格式储存，可以让数据扫描工作来的更高效。

查询被送往服务器，而优秀的格式可以最大性能的输出结果。

这篇论文描述了一个叫做Dremel的系统，它支持在普通PC组成的共享集群上对超大规模的数据集合执行交互式查询。

不像传统的数据库，它能够操作原位嵌套数据。

原位意味着在适当的位置访问数据的能力，比如，在一个分布式文件系统（比如GFS或者其他存储层（比如Bigtable）。

查询这些数据一般需要一系列的MapReduce任务，而Dremel可以同时执行很多，而且执行时间比MapReduce小得多。

Dremel不是为了成为MapReduce的替代品，而是经常与它协同使用来分析MapReduce管道的输出或者创建大规模计算的原型系统。

Dremel自从2006就投入生产了并且在Google有几千用户。

多种多样Dremel的实例被部署在公司里，排列着成千上万个节点。

使用此系统的例子包括：

●分析网络文档

●追踪Android市场应用程序的安装数据

●Google产品的崩溃报告分析

●GoogleBooks的OCR结果

●垃圾邮件分析

●GoogleMaps里地图部件调试

●托管Bigtable实例中的Tablet迁移

●Google分布式构建系统中的测试结果分析

●成百上千的硬盘的磁盘IO统计信息

●Google数据中心上运行的任务的资源监控

●Google代码库的符号和依赖关系分析

Dremel基于互联网搜索和并行DBMS的概念。

首先，它的架构借鉴了用在分布式搜索引擎中的服务树概念。

就像一个web搜索请求一样，查询请求被推入此树、在每个步骤被重写。

通过聚合从下层树节点中收到的回复，不断装配查询的最终结果。

其次，Dremel提供了一个高级、类SQL的语言来表达ad-hoc查询。

与Pig和Hive不同，它使用自己技术执行查询，而不是翻译为MapReduce任务。

最后也是最重要的，Dremel使用了一个column-striped的存储结构，使得它能够从二级存储中读取较少数据并且通过更廉价的压缩减少CPU消耗。

列存储曾被采用来分析关系型数据，但是据我们了解还没有推广到嵌套数据模型上。

我们所展现的列状存储格式在Google已经有很多数据处理工具支持，包括MapReduce、Sawzall、以及FlumeJava。

四、Google大数据的应用

保护野生老虎

谷歌强调的第一个例子是使用谷歌地图的数据来保护野生老虎。

借助谷歌地图海量的卫星图像和地理数据库资源，以及强大的处理分析能力，米尼苏达大学的科学家完成了他们在重点地区恢复老虎的栖息地的研究。

这个研究团队测量了过去14年里，全世界76个老虎栖息地面积缩小的数据。

他们发现，老虎栖息地的退化速度远远高于森林面积的退化速度。

只有在尼泊尔和印度这样拥有老虎栖息地保护区的国家，老虎的数量得到了增长。

这两个国家老虎的数量分别增长了61%和31%。

这个研究中最让人惊奇的是，大部分的研究都通过使用卫星图片信息完成的，这些信息全部通过谷歌地球免费获得的。

比如，你可以在谷歌地球中输入全球的任何一个位置，然后你就可以通过地球资源卫星图片，看到该地点是如何随着时间的迁移而变化的。

“天窗计划”

谷歌另一个有意思的研究项目是“天窗计划”。

“天窗计划”可以预估在房顶安装太阳能设备后可以节省的开支。

谷歌地球的图像库里拥有全年的日照情况和天气变化数据，“天窗计划”可以计算安装太阳能板的屋顶空间，判断使用太阳能带来的价值和可以节省的能源费用，并将用户与太阳能电池板提供商连接起来。

这是我们对不断扩大的数据库的又一创新使用：

帮助我们对重大项目作出更明智的决定。

在这个案例中，能源消耗就是这个重要项目。

目前，全美41个州的4300多万户居民可以使用“天窗计划”。

用户提供一个指标，它就可以来可以测算出可能节省的开支，以及并网发电后可能带来的收益。

通过测算你的房子或地区进行独特定制，最终推动太阳能在更大范围的使用。

治理空气污染

第三个例子由GoogleEarthOutreach和环境守护基金（theEnvironmentalDefenseFund）牵头完成。

他们测量了铺设在道路下的天然气管道的甲烷泄露情况。

谷歌通过适配谷歌街景（GoogleStreetview）汽车来完成这一任务。

这些汽车携带甲烷分析器，在街道行驶并绘制道路地图。

这意味着这些汽车在为Google地图获取街景图片内容的同时，他们也在以半秒钟为时间单位，测量所在街道甲烷的浓度。

使用这些数据，研究小组可以标记哪里存在甲烷的泄露以及泄露的程度。

“我们发现泄露的程度从平均一英里一个泄露点位（波士顿）到两百英里一个（印第安纳波利斯）不等。

通过分些这些数据，研究小组得出了很多实用的信息。

比如，在管线建设中，使用塑料管道的效果会比使用铸铁管道更好。

“

链接：

·GoogleFileSystem中文版

·GoogleMapReduce中文版

·GoogleBigTable中文版

·BigDatabeyondMapReduce:

Google'sBigDatapapers?

（编译/仲浩审校/王旭东）