Google利器之Google Cluter

最近花了不少功夫在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会被聚合成一个很大的倒排索引（invertedindex），可以看成是一个很大的二维表。我们需要查找这个索引，找到哪些包含了query词的Document并计算出相似度（google用的是pagerank）。这个相似度决定了结果的排序。
这个索引的查找在工程上是一个很大的挑战，因为整个倒排索引是非常大的（几十TB的级别）。google的解决思路是将整个index切分成许多小块，这样，对于各个小块的查询就可以并行进行，最后再将结果汇总（MapReduce就是这样的...）。
最后，查找得到的结果就是一列Document的ID号。

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

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

从上面的整个query执行过程可以看出，google总是积极地将一个application尽可能的并行化，例如将index切成小份，或者将Document切成小份然后并行处理。在这种情况下，单纯的CPU的峰值计算能力就显得不那么重要了，因为可以通过增加更多的机器，从而将index切成更小份然后并行计算来提高计算能力。举个例子，一台计算能力是4的机器所能够达到的性能，在这种并行计算下可以通过4台计算能力为1的机器得到。正是因为如此，所以google在挑选cluster的机器的时候，考虑的并不是机器单纯的performance，而是考虑它的性价比（price-performanceratio）和它的能耗。这一点非常重要，很多人都知道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这篇文章的后部分主要描述了根据这些原则怎样去挑选合适的机器，包含了大量的实践和细节。有兴趣的可以看看。

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