Google云计算平台技术架构
¢文件存储,Google Distributed File System,GFS
¢并行数据处理MapReduce
¢分布式锁Chubby
¢分布式结构化数据表BigTable
¢分布式存储系统Megastore
¢分布式监控系统Dapper
分三大块来讲的,系统架构、容错机制、系统管理技术
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和操作系统运行在不同的空间,两者耦合性降低 |
只提供专用接口 |
¢降低实现的难度 ¢对应用提供一些特殊支持 ¢降低复杂度 |
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
MapReduce
Ø一种处理海量数据的并行编程模式,用于大规模数据集(通常大于1TB)的并行运算。
u计算问题简单,但求解困难
–待处理数据量巨大(PB级),只有分布在成百上千个节点上并行计算才能在可接受的时间内完成
–如何进行并行分布式计算?
–如何分发待处理数据?
–如何处理分布式计算中的错误?JefferyDean设计一个新的抽象模型,封装并行处理、容错处理、本地化计算、负载均衡的细节,还提供了一个简单而强大的
接口
这就是 MapReduce(1)输入文件分成M块,每块大概16M~64MB(可以通过参数决定),接着在集群的机器上执行分派处理程序
(2)M个Map任务和R个Reduce任务需要分派,Master选择空闲Worker来分配这些Map或Reduce任务
(3)Worker读取并处理相关输入块,Map函数产生的中间结果
(5)当Master通知执行Reduce的Worker关于中间
缓冲的中间数据。当Reduce Worker读到所有的中间数据,它就使用中间key进行排序,这样可使相同key的值都在一起
(6)Reduce Worker根据每一个唯一中间key来遍历所有的排序后的中间数据,并且把key和相关的中间结果值集合传递给用户
定义的Reduce函数。Reduce函数的结果写到一个最终的输出文件
(7)当所有的Map任务和Reduce任务都完成的时候,Master激活用户程序。此时MapReduce返回用户程序的调用点个区