你好,游客 登录 注册 搜索
背景:
阅读新闻

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

[日期:2013-03-05] 来源:CSDN  作者:仲浩 [字体: ]

        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的下一篇论文。





收藏 推荐 打印 | 录入: | 阅读:
相关新闻