看《The Google File System》后的一些笔记

看了基于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。