Google——Google Cluster

最近花了不少功夫在Google发布的这些文章上。Google这几年发布了不少的论文来介绍它底层分布式的计算平台,其中最重要的有5篇,其中包括了大名鼎鼎的MapReduce,GFS,也有不那么出名的chubby:
GoogleCluster: http://research.google.com/archive/googlecluster.html 
Chubby:http://labs.google.com/papers/chubby.html 
GFS:http://labs.google.com/papers/gfs.html 
BigTable:http://labs.google.com/papers/bigtable.html 
MapReduce:http://labs.google.com/papers/mapreduce.html 

这里写的就是我看Google Cluster的一些笔记和心得。希望有时间也能把其它的几篇都整理出来。



这个图就是一个普通的Query所要经过的整个逻辑流程。

首先,一个query(例如www.google.com/search?q=ieee+society)被用户输入到浏览器。
浏览器会通过DNS得到对应的www.google.com的IP。由于整个google的service包含了几个分布在全球不同地方的cluster(每个包含上千台机器),DNS需要选择一个最合适的cluster(选择的标准要考虑到用户的地理位置等等)。
于是,用户的浏览器将这个query以HTTP的方式发送到这个cluster。这个cluster的一个LoadBalancer会将query发送到 其中的一个GoogleWebServer(GWS)机器上。这个GWS会协调整个query的执行过程,并将结果以HTML的方式返回给浏览器。
而上面的这个图表示的正是query在一个cluster上的执行过程。


这个执行过程又分为两部分。
第一部分是对索引的查找。在信息检索中,所有的Document会被聚合成一个很大的倒排索引(inverted index),可以看成是一个很大的二维表。我们需要查找这个索引,找到哪些包含了query词的Document并计算出相似度(google用的是 pagerank)。这个相似度决定了结果的排序。
这个索引的查找在工程上是一个很大的挑战,因为整个倒排索引是非常大的(几十TB的级别)。google的解决思路是将整个index切分成许多小块,这样,对于各个小块的查询就可以并行进行,最后再将结果汇总(MapReduce就是这样的...)。
最后,查找得到的结果就是一列Document的ID号。

第二部分则是对实际的Document的操作。使用第一部分得到的ID号,通过Document Server来找到对应的Document,这些Document需要进行一定的处理,例如Summary(我们搜索后得到的结果不就是一组网站的摘要 么),然后将结果返回给用户。其中,使用ID查找对应Document的过程和第一部分类似,也是通过将整个Document集合切分成许多小份再分别进 行查找。

除了这两部分以外,可能还包括一些例如拼写检查或者广告之类的模块。如图所示。

从上面的整个query执行过程可以看出,google总是积极地将一个application尽可能的并行化,例如将index切成小份,或者将 Document切成小份然后并行处理。在这种情况下,单纯的CPU的峰值计算能力就显得不那么重要了,因为可以通过增加更多的机器,从而将index切 成更小份然后并行计算来提高计算能力。举个例子,一台计算能力是4的机器所能够达到的性能,在这种并行计算下可以通过4台计算能力为1的机器得到。正是因 为如此,所以google在挑选cluster的机器的时候,考虑的并不是机器单纯的performance,而是考虑它的性价比(price- performance ratio)和它的能耗。这一点非常重要,很多人都知道google的cluster采用的就是我们常人所用的普通的PC机,但通过这篇文章我们可以知 道,google之所以这样做并不是因为想标新立异,而是因为采用普通的PC机并不会带来性能的损失,而且整体费用甚至更低。

此外,google cluster还有其它一些有趣的特性。
例如,google cluster保存数据使用了大量的副本。一份数据在cluster中都有几份副本。这样做有几个好处,首先,可以提高吞吐量,因为多个副本就意味着对同一组数据可以同时进行操作,其次,还满足了容错性的需求。
还有,从上面的query过程我们可以发现,大部分的操作都是read-only的,update操作相对而言非常稀少。所以在一个副本的数据 update的时候,可以将正在它上面进行的query操作转移走。也就说不存在对一个数据同时读和写的情况。这样做非常有意义,因为回避了一个在普通的 DataBase中非常重要的问题,即数据的一致性(consistency)。
google cluster的容错也与众不同。它甚至都没有采用RAID这样的措施,所有的可靠性保障和容错性能都是基于software的。


总结

google cluster的设计原则包括:
1. 软件层面的安全可靠保障。
2. 使用数据的副本。
3. 性价比甚于peak performance。
4. 采用日常的PC。
不仅仅是google cluster,还包括MapReduce,GFS,他们之所以现在如此成功,我认为一个很重要的原因就在于需求非常的明确。在设计之初就没有遵循传统的方式,而是针对实际当中的要求给出了不同的思路,这种量身定制决定了他们的成功。
Google这篇文章的后部分主要描述了根据这些原则怎样去挑选合适的机器,包含了大量的实践和细节。有兴趣的可以看看。

由于我自己也是刚刚开始接触这方面的知识,有任何理解不当之处欢迎批评指正。

 

转载自:http://blog.csdn.net/historyasamirror/archive/2009/02/03/3861144.aspx

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值