GFS Google Storage System/HDFS

Google File System GFS

参考文档：

Ghemawat03: S. Ghemawat, H. Gobioff, S-T. Leung, Symp. on Operating Systems Principles (SOSP’03), Oct 2003, Bolton Landing, NY.

Bigtable: A Distributed Storage System for Structured Data. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber. Appears in USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2006

MapReduce: Simplified Data Processing on Large Clusters. Jeffrey Dean and Sanjay Ghemawat. Appears in USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2004

Commodity Clusters 社区集群

最早的时候，Google的超大规模文件系统设计是认为有错是正常的，有很多廉价的节点。使用磁盘的容量来满足简单的需求，设计了一些模式来减少错误（当然这些都是没有公布的，只能靠猜想）；提供给应用的接口非常有局限。一个应用集合里面，能拥有的文件数量是有限制的，对小文件的性能没有太多关注；允许某些特殊的访问模式，导致性能很差；能够改变文件系统的语义，增加一些新的操作。

最早的GFS如下图所示：

客户取文件的时候，将所需使用的文件名，块索引发给GFS的主机，然后根据文件路径名进行树搜索得到BigTable对应块的位置，然后把文件handle和位置发回给用户。用户再去GFS的chunkservser里面取数据出来。

以下是GFS设计的简单版本：所有的metadata都在内存中，所有的文件都应该是很大的（一个块64M）；metadata也会经常改变，因为chunk的位置不是固定的。每次新操作就会进行所有的同步，没有隐藏不一致性，使得效率低下。用户的API是使用用户级别的库进行，不怎么优雅就是了。在做恢复，修复的时候是异步进行的，是over-replicate的。只有在Linux File System采用到了Cache，别的地方都没有。

介绍完了整个的结构，就谈一下GFS是如何进行数据复制用来做恢复的。

这个逻辑架构叫做Dual Ordering。首先是用户发送请求给Master Server，然后Master返回handle给用户，你可以把数据写到哪里，作为最开始拷贝的部分。然后最开始拷贝的chunk pos 1有把数据拷贝到另外一个存储位置2，然后2又把数据拷贝到第三个位置3。中间的控制信号来自于用户，用户的控制权限来自于Master。这样做的目的就可以大大减少用户所需要的带宽，提高性能。

对于并发共享数据的处理（concurrent sharing）：
在GFS中是未定义的行为，可以自定义。Append操作需要被记录至少一次，如果竞争发生错误，就会导致不同的复制版本，GFS需要对记录进行重复到不同的拷贝中。

由于GFS存在种种问题，所以在这里提出了后台维护。
1、服务器需要周期性地维护chunk的内容的正确性；
2、对每个chunk进行后台分析：如果某个chunk丢了，那么进行re-replicate。慢慢对不同的chunkserver进行数据搬移实现负载均衡；移除旧的数据。
3、垃圾回收。

GFS2的改进：
1、使用BigTable存储共享的metadata；
2、不再简单的拷贝，而是使用Reed-Solomon（RAID 6）编码。
3、在用户端计算encoding。

单个metadata服务器，使用前缀树（字典树）来进行索引路径。

模仿者：Hadoop FS HDFS

Hadoop是Oracle根据GFS的论文模仿出来的开源代码，但是性能比GFS差了很多。我觉得一方面是GFS很多优化细节其实没有po出来，另外一方面hadoop是用Java写的，GFS使用C写的，这种更底层的应用，C还是更快很多，Java要通过JVM再变成可执行的指令，效率还是会低一些。