一、GFS的设计目标
Google File System是一个面向密集应用的，可伸缩的大规模分布式文件系统，以满足其庞大的储存需求。GFS与之前的分布式文件系统具有以下不同：
1、组件失效被认为是常态事件，而不是意外事件
Google的一个应用至少有成百上千台服务器正在运转，同时也有一定数量级的用户进行访问，而系统不能保证时时刻刻每台服务器都运转正常，任意时刻下某个服务器都有可能因为人为操作的失误、程序的bug、操作系统的bug、硬件或者网络的问题，导致组件失效。即使昂贵的硬件设备也不能完全阻止这种情况发生，所以GFS使用多个廉价的磁盘驱动器来组成存储设备。为了对抗组件的失效，GFS中包含了监视、错误侦测、容错以及自动修复的机制。
2、系统存储一定量的大文件，数GB的文件非常普遍
因为GFS处理的都是大规模的数据集，以后面对的基本是数百GB级别的数据，所以设计的假设条件和参数，比如I/O操作和Block的尺寸都需要重新考虑。虽然GFS支持对以KB计算的小文件进行处理，但是这样做效率并不高。
3、系统的工作负载的读操作主要有两种：大规模的流式读取和小规模的随机读取。
大规模的流式读取通常一次读取1MB甚至更多的数据。来自同一个客户机的连续操作通常是读取同一个文件中的连续的一个区域。小规模的随机读取通常是在文件某个随即位置读取几个KB的数据。
所以，如果应用程序对性能非常关注，通常的做法是把小规模的随机读取操作合并并且排序，之后按顺序批量读取，这样就避免了在文件中前后来回移动读取位置。
4、绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。
Google应用中对大部分文件的修改，不是覆盖原有数据，而是在文件尾追加新数据。对文件的随机写是几乎不存在的，一个文件一旦被写好，只是被连续地读取。对于海量文件的访问模式，客户端对数据块缓存已经没有意义。
5、应用程序和文件系统的API的协同设计提高了系统的灵活性
Google希望通过简化GFS的一致性模型来简化文件系统，而不是给应用程序太多压力。由于同时读写数据的客户端很多，因此使用最小的同步开销来实现的原子的多路追加数据操作是必不可少的，所以数据的追加操作是性能优化和原子性保证的主要考量因素。
6、高性能的稳定网络带宽远比低延迟重要。
大多数的应用程序都是高速地处理大量数据，而对每一次的读写操作没有严格的时间要求。 目标程序（客户端）绝大部分要求能够高速率的、大批量的处理数据，高性能稳定的网络带宽比延迟更重要。
7、GFS提供了快照操作
GFS中的快照功能是非常强大的，可以非常快的对文件或者目录进行拷贝，并且不影响当前的操作（读、写、复制）。快照也能以很低的成本创建一个文件或者目录树的拷贝。
Bigtable是一个为管理大规模结构化数据而设计的分布式存储系统，可以扩展到PB级数据和上千台服务器。很多google的项目使用Bigtable存储数据，这些应用对Bigtable提出了不同的挑战，比如数据规模的要求、延迟的要求。Bigtable能满足这些多变的要求，为这些产品成功地提供了灵活、高性能的存储解决方案。
Bigtable看起来像一个数据库，采用了很多数据库的实现策略。但是Bigtable并不支持完整的关系型数据模型；而是为客户端提供了一种简单的数据模型，客户端可以动态地控制数据的布局和格式，并且利用底层数据存储的局部性特征。Bigtable将数据统统看成无意义的字节串，客户端需要将结构化和非结构化数据串行化再存入Bigtable。
下文对BigTable的数据模型和基本工作原理进行介绍，而各种优化技术（如压缩、Bloom Filter等）不在讨论范围。MapReduce 是一个编程模型,也是一个处理和生成超大数据集的算法模型的相关实现。用户首先创建一 个 Map 函数处理一个基于 key/value pair 的数据集合,输出中间的基于 key/value pair 的数据集合;然后再创建 一个 Reduce 函数用来合并所有的具有相同中间 key 值的中间 value 值。现实世界中有很多满足上述处理模型 的例子,本论文将详细描述这个模型。
原文：https://www.cnblogs.com/wcx1217/p/11058745.html