那些年Google公开的大数据领域论文

云计算
主流的大数据基本都是MapReduce的衍生,然而把目光聚焦到实时上就会发现:MapReuce的局限性已经渐渐浮现。下面将讨论一下自大数据开始,Google公布的大数据相关技术,以及这些技术的现状。

Mikio L. Braun柏林工业大学机器学习学博士后,TWIMPACT联合创始人兼首席数据科学家。在其个人博客上总结了Google近几年大数据领域的论文,并发表了自己的见解。

以下为译文:

 

 

主流的大数据基本都是MapReduce的衍生,然而把目光聚焦到实时上就会发现:MapReuce的局限性已经渐渐浮现。下面将讨论一下自大数据开始,Google公布的大数据相关技术,以及这些技术的现状。

MapReuce、Google File System以及Bigtable:大数据算法的起源

按时间算第一篇的论文应该2003年公布的 Google File System,这是一个分布式文件系统。从根本上说:文件被分割成很多块,使用冗余的方式储存于商用机器集群上;这里不得不说基本上Google每篇论文都是关于“商用机型”。

紧随其后的就是2004年被公布的 MapReduce,而今MapReuce基本上已经代表了大数据。传说中,Google使用它计算他们的搜索索引。而Mikio L. Braun认为其工作模式应该是:Google把所有抓取的页面都放置于他们的集群上,并且每天都使用MapReduce来重算。

Bigtable发布于2006年,启发了无数的NoSQL数据库,比如:Cassandra、HBase等等。Cassandra架构中有一半是模仿Bigtable,包括了数据模型、SSTables以及提前写日志(另一半是模仿Amazon的Dynamo数据库,使用点对点集群模式)。

Percolator:处理个体修改

Google并没有止步于MapReduce。事实上,随着Internet的指数增长,从零开始重算所有搜索索引变得不切实际。取而代之,Google开发了一个更有价值的系统,同样支持分布式计算。

这也是其有趣的地方,特别是在对比常见的主流大数据之后。举个例子,Percolator引入了事务,而一些NoSQL数据库仍然在强调得到高扩展性的同时你必须牺牲(或者不再需要)事务处理。

在2010年这篇 Percolator的论文中,Google展示了其网络搜索是如何保持着与时俱进。Percolator建立于已存类似Bigtable的技术,但是加入了事务以及行和表上的锁和表变化的通知。这些通知之后会被用于触发不同阶段的计算。通过这样的方式,个体的更新就可以“渗透”整个数据库。

这种方法会让人联想到类似Storm(或者是Yahoo的S4)的流处理框架(SPF),然而Percolator内在是以数据作为基础。SPF使用的一般是消息传递而不是数据共享,这样的话更容易推测出究竟是发生了什么。然而问题也随之产生:除非你手动的在某个终端上储存,否则你将无法访问计算的结果。

Pregel:可扩展的图计算

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

Pregel内在的计算模型比MapReduce复杂的多:基本上每个节点都拥有一个工作者线程,并且对众多工作者线程进行迭代并行。在每一个所谓的“superstep”中,每一个工作者线程都可以从节点的“收件夹”中读取消息和把消息发送给其它节点,设置和读取节点相关值以及边界,或者投票停止。线程会一直运行,直到所有的节点都被投票停止。此外,还拥有Aggregator和Combiner做全局统计。

论文陈述了许多算法的实现,比如Google的PageRank、最短路径、二分图匹配等。Mikio L. Braun认为,对比MapReduce或SPF,Pregel需要更多实现的再思考。

Dremel:在线可视化

在2010年,Google还公布了 Dremel论文。一个为结构化数据设计,并拥有类SQL语言的交互式数据库。然而取代SQL数据库使用字段填补的表格,Dremel中使用的是类JSON格式数据(更准确的说,使用Google Protocol buffer格式,这将加强对允许字段的限制)。内部,数据被使用特殊格式储存,可以让数据扫描工作来的更高效。查询被送往服务器,而优秀的格式可以最大性能的输出结果。

Spanner:全球分布

 

 

最后 Spanner—— 全球分布式数据库;Google在2009年提出了Spanner远景计划,并在2012年对外公布Spanner论文。Spanner的公布可以说是Google向大数据技术中添的又一把火,Spanner具有高扩展性、多版本、全球级分布以及同步复制等特性。

跨数据中心的高扩展性及全球分布会对一致性保障提出苛刻的需求 —— 读写的外部一致性和基于时间戳的全局读一致性。为了保障这一点,Google引入了TrueTime API。TureTime API可以同步全球的时间,拥有一个TT.now()的方法,将获得一个绝对时间,同时还能得到时间误差。为了保证万无一失,TrueTime API具有GPS和原子钟双保险。也只有这样的机制才能让全球范围内的并发处理得到保障。

大数据超越MapReduce

Google并没有止步于MapReduce,他们在MapReduce不适用的地方开发新方法;当然,对于大数据领域来说这是个福音。MapReduce不是万能的;当然,你可以更深入一步,比如说将磁盘数据移入内存,然而同样还存在一些任务的内部结构并不是MapReduce可以扩展的。

在Google思路以及论文的启发下,同样涌现出一些开源项目,比如:Apache Drill、Apache Giraph、斯坦福GPS等等。

Google近年来每篇论文都有着深远的影响,同时大数据领域内有很多人必然在翘首以盼Google的下一篇论文。

责任编辑:王程程 来源: 博客
相关推荐

2013-09-23 09:52:22

云计算大数据

2016-10-24 22:41:06

大数据Google

2012-12-27 10:22:46

大数据

2021-09-13 17:27:49

对比学习深度学习人工智能

2015-06-24 09:01:37

Google数据中心网络

2013-03-27 10:50:40

云计算领域

2017-01-04 12:23:08

大数据机器学习数据科学

2024-01-04 16:20:35

2021-07-23 11:32:05

大数据数据处理杀熟

2019-02-26 08:14:41

大数据HadoopSpark

2015-02-05 09:14:38

惠普大数据

2016-11-29 16:36:03

2020-12-25 13:51:49

大数据医疗大数据

2017-12-15 15:52:40

大数据数据IT

2015-11-15 17:22:25

微软硬件创新

2020-07-24 11:25:58

数据中心IT技术

2020-12-11 11:33:15

大数据Hadoop

2016-09-13 09:10:35

大数据

2017-01-07 11:42:16

2016-12-23 18:27:45

联想
点赞
收藏

51CTO技术栈公众号