看了基于Google File System思想实现的Hadoop代码,重读了Google的这篇论文《The Google File System》。Paper挺长,网上已经有热心的人把翻译版奉献了出来。在这里,只是把其中的部分内容抽取出来,与大家一起分享。
性能,可扩展性,可靠性,可用性仍然是GFS的目标,但它还有一些与传统分布式文件系统与众不同的东西:
(1)对于大规模的集群系统,机器出现故障很正常,因此系统容错必须十分重视。文件系统必须具有高可用性,数据完整性和相应的诊断工具。通过快速恢复,chunk复制,master复制达到高可用性;通过checksum检查数据完整性;通过log记录系统中出现的各种事件,以便诊断错误。
(2)传统文件系统的block的大小只有几k,而GFS将选用64M,以满足当前出现的越来越庞大的数据集处理需求。选用大的chunk size,可以:
a、减少与master的交互次数;
b、大部分的时候,对chunk的操作都集中在一个chunk上,因此可以维护一个持久的TCP连接减小网络开销;
c、减少存储在master上的元数据把它放在内存中。
在具有优点的同时,存在缺点,就是多个客户端同时访问同一个文件(此文件比较小,由一个chunk组成),易形成hot spot。
(3)通过观察发现,绝大部分的时候,对文件的修改操作都只是附加内容,很少是翻盖写或者随机写。因此在GFS中,对文件附加操作进行重点优化。
GFS的体系结构
GFS的体系结构是由一个master和多个chunkserver组成(在Hadoop中,master称作name node,chunkserver称作data node,chunk称作block)。
采用单一的master,可以简化系统设计,在拥有全局视图的情况下制定更好的chunk处置策略。采用此种方法,存在瓶颈问题是显而易见的。因此master只存储元信息,相当于元数据服务器,具体的数据传输由client和chunkserver来完成。
元数据
包括三类元数据,它们分别是:文件和chunk的命名空间,文件到chunk的映射和每个chunk副本的位置。元数据全部放入内存,这样可以加快master的操作速度,但它受限于内存大小。
操作日志
对文件系统的操作都将被记录到持久化存储介质,通过重新执行这些操作来达到恢复文件系统的目的。当操作日志达到一定大小时,将做checkpoint,这样可以减少文件系统的恢复时间。目前,Hadoop不支持对操作日志做checkpoint。
Data Flow
在GFS中,数据流和控制流分开,这是显而易见的。数据流怎么流动,具有一定的技巧性。它采用的是pipeline方式。一个chunkserver并不是把数据同时分发给其余的chunkserver,而是把数据只传给离自己最近的chunkserver(距离的远近通过IP地址来判断)。此时这个chunkserver在接受数据的同时,把数据转发给离它最近的chunkserver,这样充分利用了全双工网络的带宽。
以上只谈到paper中涉及的一些方面,完整内容请阅读paper。