Google的云计算原理与应用

Google业务

Ø全球最大搜索引擎、Google Maps、Google Earth、Gmail、YouTube等——特点：数据量庞大、面向全球用户提供实时服务

Google云计算平台技术架构

¢文件存储，Google Distributed File System，GFS

¢并行数据处理MapReduce

¢分布式锁Chubby

¢分布式结构化数据表BigTable

¢分布式存储系统Megastore

¢分布式监控系统Dapper

一、Google文件系统GFS

分三大块来讲的，系统架构、容错机制、系统管理技术

1、系统架构

Client（客户端）：应用程序的访问接口

Master（主服务器）：管理节点，在逻辑上只有一个，保存系统的元数据，负责整个文件系统的管理

ChunkServer（数据块服务器）：负责具体的存储工作。数据以文件的形式存储在ChunkServer上

关于上面的架构图之前看到过一篇博客，上面对其机架感知(Rack Awareness)机制有一个简单的表示，很可惜博客竟未找到，大致是：

对于Rack Awareness——Rack1:Chunk1 、Chunk4、Chunk7……Rack n:Chunk2、Chunk 5、Chunk6……

而对于ns:file——Chunk1、Chunk2……

这样，两者一结合，查找文件块、甚至对相对的查找的优化等比较方便

GFS特点：

采用中心服务器模式

u可以方便地增加Chunk Server u Master掌握系统内所有Chunk Server的情况，方便进行负载均衡 u不存在元数据的一致性问题

不缓存数据

˜文件操作大部分是流式读写，不存在大量重复读写，使用Cache对性能提高不大 ˜ Chunk Server上数据存取使用本地文件系统，若读取频繁，系统具有Cache ˜从可行性看，Cache与实际数据的一致性维护也极其复杂

在用户态下实现

¨利用POSIX编程接口存取数据降低了实现难度，提高通用性     ¨POSIX接口提供功能更丰富     ¨用户态下有多种调试工具     ¨Master和Chunk Server都以进程方式运行，单个进程不影响整个操作系统     ¨GFS和操作系统运行在不同的空间，两者耦合性降低

只提供专用接口

¢降低实现的难度     ¢对应用提供一些特殊支持     ¢降低复杂度

2、容错机制

Master容错

Name Space，文件系统目录结构 

Chunk与文件名的映射

Chunk副本的位置信息(默认有三个副本) 

单个Master，对于前两种元数据，GFS通过操作日志来提供容错功能

第三种元数据信息保存在各个ChunkServer上，Master故障时，磁盘恢复

GFS还提供了Master远程的实时备份,防止Master彻底死机的情况

Chunk Server容错

u采用副本方式实现Chunk Server容错

¨每一个Chunk有多个存储副本（默认为三个），分布存储在不同的Chunk Server上用户态的GFS不会影响Chunk Ser

ver的稳定性

¨副本的分布策略需要考虑多种因素，如网络的拓扑、机架的分布、磁盘的利用率等

¨对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入 

 

尽管一份数据需要存储三份，好像磁盘空间的利用率不高，但综合比较多种因素，加之磁盘的成本不断下降，采用副本

无疑是最简单、最可靠、最有效，而且实现的难度也最小的一种方法。

 

¨ GFS中的每一个文件被划分成多个Chunk，Chunk的默认大小是64MB

缓冲的中间数据。当Reduce Worker读到所有的中间数据，它就使用中间key进行排序，这样可使相同key的值都在一起

（6）Reduce Worker根据每一个唯一中间key来遍历所有的排序后的中间数据，并且把key和相关的中间结果值集合传递给用户

定义的Reduce函数。Reduce函数的结果写到一个最终的输出文件

 

（7）当所有的Map任务和Reduce任务都完成的时候，Master激活用户程序。此时MapReduce返回用户程序的调用点个区