摘要：Google于2004年公布了MapReduce论文，为数据领域工作者开启了大数据算法之门。然而Google的大数据脚步显然不止于此，其后公布了Percolator、Pregel、Dremel、Spanner等多篇论文。没有止步的不仅是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-08-3
本文来自云栖社区合作伙伴“大数据文摘”，了解相关信息可以关注“BigDataDigest”微信公众号
