GFS, MapReduce and Bigtable

[CookiePieWw]

https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
http://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf
http://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf

[CookiePieWw]

GFS

为面向大规模分布式数据密集型应用设计和实现的可扩展的分布式文件系统，在大量的廉价商用硬件机器上运行并提供容错机制和聚合性能。

[CookiePieWw]

设计

GFS 的设计基于以下假设：

1. 在廉价商用硬件机器上运行，因此组件失效是常见的。为此需要设计对组件的监控、探测和快速的自动恢复。
2. 存储大文件。单个文件的大小通常在 100 MB 以上，包括 GB 级别的文件。支持存储小文件，但不会单独优化。
3. 主要支持大量的顺序读取和少量的随机读取。顺序读取通常在 1 MB 以上，随机读取通常在 KB 级别。关注性能的应用通常会按批读取数据而非进行大量随机读取，以获取更好的性能表现。
4. 主要支持顺序写入，向文件末尾添加数据。写入的大小和读取相仿。极少进行修改，支持随机写入但效率不高。
5. 倾向于更高的带宽而不是更低的延迟。（面向批处理系统）

[CookiePieWw]

GFS 首先提供 POSIX 标准的文件接口，如 create，delete，open，close，read 和 write。此外，GFS 还提供 snapshot 和 record append，前者是低成本的复制，后者支持并行写入一个文件。

[CookiePieWw]

GFS 由单个 master （单点失效？）和多个 chunkserver 以及 client 组成。

每个文件被分为多个大小固定的 chunk 并以多个副本的形式存储在 chunkserver 上，每个 chunk 由全局唯一的 chunk handle 确定。

master 负责存储 metadata，包括 namespace，访问控制信息，文件和 chunk 的映射和 chunk 的位置。同时 master 也直接控制系统级的操作，如 gc、chunk migration 等。

client 通过与 master 交互获得文件 metadata，与 chunkserver 交互获得数据。

client 和 chunkserver 不提供除 Linux 本身的 cache 之外额外的文件 cache。cache 对 GFS 面临的大文件读取任务几乎没有好处。client 会 cache metadata。

[CookiePieWw]

GFS 使用 relaxed 的 consistency model。

这里没有具体说读和写的并发结果如何，看起来是可以读到写到一半的东西。GFS 提供一个 lease/version 机制来保证不会读到损坏的 chunk，但并没有保证写操作的原子性。

GFS 提供一个原子的 record append 操作，该操作保证 a record is appended atomically at least once，但这个操作可能引发 inconsistency。应用负责在 inconsistency 的情况下作检查。

GFS 建议使用 record append 操作。