Google在2003年到2004年公布了关于GFS、MapReduce和BigTable三篇技术论文，成为后来云计算发展的重要基石。如今，Google的Caffeine、Pregel、Dremel或将再次影响着全球大数据发展的技术潮流。

GOOGLE搜索引擎Caffeine

　　谷歌(GOOGLE)开发的新的搜索引擎代号为“×××”

 

　　网络搜索服务巨头谷歌公司的新一代搜索引擎已经上线，供使用者测试。据悉，该版本测试完成后将取代谷歌现有的搜索引擎。

 

　　谷歌表示，新的引擎代号为“×××”，搜索速度是旧版本的两倍，并且能提供更精确、更全面的搜索结果。

 

　　新引擎有一个独立的网址，虽然外观同现有的谷歌引擎一样，但谷歌表示，引擎的基本框架已经升级到了新版本。

 

　　业界认为，谷歌此举显然是感受到了微软搜索引擎“必应”(BING)的压力，试图以此拉开与后者的距离。

 

　　还有搜索引擎优化（SEO）人士表示，尽管更新架构会让谷歌搜索更为出色，但谷歌Caffeine将给网络开发与SEO带来相当大的冲击。网络上已经出现大量有关这一新架构的分析与猜测文章。

 

　　谷歌Caffeine项目可能是微软Bing发布后搜索巨头进行的最大一个项目。《纽约邮报》曾报道称，谷歌联席创始人塞吉布林对微软Bing的发布相当紧张，他已经召集了一队人马对自家的服务进行紧急升级。

 

　　但谷歌发言人却表示，Caffeine绝不是谷歌对Bing做出的反击。新一代搜索引擎的计划已经在公司内开展了相当长一段时间。


Caffeine索引技术

   索引对比

索引对比

　　为何要开发新型Caffeine索引技术？原因就是互联网内容的规模每天都在增长。互联网内容的增长并不仅仅体现在数量上面，而且还出现了视频、图片和实时更新等内容。与以往相比，目前平均每个网页所含信息量比以前更为丰富。此外，网民对搜索引擎性能的期望值比以前更高，他们希望能够更及时查找到互联网上刚刚发布的内容。

 

　　为适应互联网产业的向前演进以及满足网民的需求，我们开发了Caffeine索引系统。我们老式索引采用了多层技术，而部分索引层的内容更新快于其他层面;主索引层通常是每隔数周更新一次。如果我们要更新其中的某个索引层，就是必须对整个互联网进行分析。如此一来，网民所搜索到的结果，与互联网的实际内容之间会有一个时间差。

 

　　利用Caffeine技术，我们将互联网划分为不同的部分，然后以连续状态在全球范围对不同部分内容加以升级。当我们发现了新内容，只需将这些新内容添加到当前索引当中。这就是说，你在使用谷歌搜索过程中，所获得的结果与互联网实际内容的时间差已经非常小。

 

　　Caffeine技术可以使我们实现对网络内容索引的规模化。事实上，Caffeine每秒钟可同时处理数十万个网页。如果这些网页是现实生活中的纸张，则这些纸张每秒钟将堆成3英里高。Caffeine在一个数据库中可处理近1亿GB的存储信息，且每天存储信息量都在大幅增长。你需要使用62.5万部容量最大的iPod音乐播放器才能存储这些信息，如果将这些iPod并排放置，则可长达40英里。

 

　　我们开发Caffeine技术，其实是着眼于互联网产业的未来发展。Caffeine不仅仅提高了网络索引的时效性，而且使我们希望组建性更强大的搜索引擎成为可能，然后再向网民提供质量更好的搜索服务。请关注Caffeine的发展，今后数月内，我们将对Caffeine技术加以进一步完善和改进。

 

Pregel学习笔记

　　Pregel是Google的一个分布式图计算的编程框架，是继MapReduce之后又一大分布式计算的利器，主要是为了便于在大规模图数据的情况下实现各种图算法。据说在Google有20%的计算任务由Pregel来完成。Pregel最初在SIGMOD2010上公开发表,题为《Pregel:A System for Large-Scale Graph Processing》。由于课程要求LZ便去拜读了一下。

　　Pregel是一个stateful model（姑且叫做状态模型吧），它维护着图中每个顶点的状态，每个顶点的状态包括该顶点自身的值，由它出发的有向边的值和有向边的destination，以及该顶点的活动标记（是否为活动状态），因此这是一个以顶点为中心的编程框架。它的计算过程是由一系列supersteps组成，在每一轮supersteps中，Pregel调用用户自定义的函数compute（）来对每一个顶点进行计算，每一个顶点的计算过程如下：接收其他顶点（可能相邻或不相邻）发送给它的消息，执行自定义的compute（）函数从而改变自身的值和从它出发的边（也有可能改变图拓扑结构）以及向其他节点发送消息。当在某一轮supersteps中它的值不变时便标记为inactive，处于inactive状态下的顶点在收到消息时重新变为active，Pregel不会对inactive状态下的顶点调用计算函数compute（），因此当所有节点都处于inactive，并且没有消息在传送中时计算结束。下图为作者在论文中举得一个例子，目的是要将所有节点的值改为这些节点中的最大值，其中comupute（）函数定义为向相邻节点发送本节点的值，用灰色标记的节点表明已经处于inactive状态。

　　　　　　

　　Pregel的设计就是为了使完成处理大规模图数据的处理（如PageRank，最短路径）更加简单，因此它的API接口十分的简单，主要就是继承Vertex类（其定义如下图），重写其中的compute（）方法（即用户自定义的顶点的处理函数，参数msgs表示其他顶点发送给它的消息。此外为了节省消息在不同的物理机器之间传递的开销以及消息所占空间，Pregel提供了Combiners接口，用于消息的提前处理。为了提供一些全集信息，Pregel提供了Aggragators接口来汇总各个顶点提交上来的信息。

　　Pregel运行在Google的集群环境中。首先有个master，管理所有的workers，每个worker完成一部分顶点的计算任务（顶点的划分任然是个未很好解决的问题），master同步所有worker的计算，当所有worker完成一步supersteps之后master才会命令workers进入下一步supersteps计算。在这样的分布式计算环境中，出错是难免的，因此Pegel提供了容错机制，可以将中断的任务继续执行，所用的方法是在每一步supersteps之前将所有顶点的状态备份。

　　利用Pregel可以完成很多图上面的计算任务，下图是一个利用pregel来完成pagerank的例子，发送的消息的值为发送节点的当前pagerank的值除以该节点的outdegree。程序中只循环计算了30次（实际情况中当所有节点都inactive时终止计算）

　　作者的实验结果表明Pregel对图数据的规模和workers的数量都具有很好的scalibility，适合稀疏图数据的处理。

 

Google Dremel设计
 
简介

Dremel 是Google 的“交互式”数据分析系统。可以组建成规模上千的集群，处理PB级别的数据。MapReduce处理一个数据，需要分钟级的时间。作为MapReduce的发起人，Google开发了Dremel将处理时间缩短到秒级，作为MapReduce的有力补充。Dremel作为Google BigQuery的report引擎，获得了很大的成功。最近Apache计划推出Dremel的开源实现Drill，将Dremel的技术又推到了浪尖上。

 

根据Google公开的论文《Dremel: Interactive Analysis of WebScaleDatasets》可以看到Dremel的设计原理。还有一些测试报告。论文写于2006年，公开于2010年，Google在处理大数据方面，果真有得天独厚的优势。下面的内容，很大部分来自这篇论文。

随着Hadoop的流行，大规模的数据分析系统已经越来越普及。数据分析师需要一个能将数据“玩转”的交互式系统。如此，就可以非常方便快捷的浏览数据，建立分析模型。Dremel系统有下面几个主要的特点：

  • Dremel是一个大规模系统。在一个PB级别的数据集上面，将任务缩短到秒级，无疑需要大量的并发。磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的并发读! Google一向是用廉价机器办大事的好手。但是机器越多，出问题概率越大，如此大的集群规模，需要有足够的容错考虑，保证整个分析的速度不被集群中的个别慢(坏)节点影响。
  • Dremel是MR交互式查询能力不足的补充。和MapReduce一样，Dremel也需要和数据运行在一起，将计算移动到数据上面。所以它需要GFS这样的文件系统作为存储层。在设计之初，Dremel并非是MapReduce的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapReduce的结果集或者用来建立分析原型。
  • Dremel的数据模型是嵌套(nested)的。互联网数据常常是非关系型的。Dremel还需要有一个灵活的数据模型，这个数据模型至关重要。Dremel支持一个嵌套(nested)的数据模型，类似于Json。而传统的关系模型，由于不可避免的有大量的Join操作，在处理如此大规模的数据的时候，往往是有心无力的。
  • Dremel中的数据是用列式存储的。使用列式存储，分析的时候，可以只扫描需要的那部分数据的时候，减少CPU和磁盘的访问量。同时列式存储是压缩友好的，使用压缩，可以综合CPU和磁盘，发挥最大的效能。对于关系型数据，如果使用列式存储，我们都很有经验。但是对于嵌套(nested)的结构，Dremel也可以用列存储，非常值得我们学习。
  • Dremel结合了Web搜索 和并行DBMS的技术。首先，他借鉴了Web搜索中的“查询树”的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询。大事化小，小事化了，能并发的在大量节点上跑。其次，和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样。