Google三大论文简单摘要
GFS:
为了满足Google迅速增长的数据处理需求。设计目标:性能、可伸缩性、可靠性、可用性等。
组件失效被认为是常态事件,而不是意外事件。
其次,以通常的标准衡量,我们的文件非常巨大。以TB为单位。
第三,绝大部分文件的修改是采用在文件尾部追加数据,而不是覆盖原有数据的方式。
第四,应用程序和文件系统API的协同设计提高了整个系统的灵活性。
系统的工作负载主要由两种读操作组成:大规模的流式读取和小规模的随机读取。
GFS提供了一套类似传统文件系统的API接口函数。另外,GFS提供了快照和记录追加操作。
一个GFS集群包含一个单独的Master节点、多台Chunk服务器,并且同时被多个客户端访问。
GFS存储的文件都被分割成固定大小的Chunk。缺省情况下,我们使用3个存储复制节点。
Master节点管理所有的文件系统元数据。
无论是客户端还是Chunk服务器都不需要缓存文件数据。
单一的Master节点。
Chunk的尺寸为64MB。
Master服务器只需要不到64个字节的元数据就能够管理一个64MB的Chunk。
操作日志包含了关键的元数据变更历史记录。
GFS支持一个宽松的一致性模型。
一个重要的原则:最小化所有操作和Master节点的交互。
客户机向Master节点询问哪一个Chunk服务器持有当前的租约,以及其他副本的位置。
Master节点将主Chunk的标识符以及其他副本的位置返回给客户机。
客户机把数据推送到所有的副本上。
当所有的副本都确认接受到了数据,客户机发送写请求到主Chunk服务器。
主Chunk把写请求传递到所有的二级副本。
所有的二级副本回复主Chunk,它们已经完成了操作。
主Chunk服务器回复客户机。
为了提高网络效率,我们采取了把数据流和控制流分开的措施。
GFS提供了一种原子的数据追加操作-记录操作。
记录追加是一种修改操作。
如果追加操作在任何一个副本上失败了客户端就需要重新进行操作。
快照操作几乎可以瞬间完成对一个文件或者目录树做一个拷贝,并且几乎不会对正在进行的其他操作造成任何干扰。
Master节点执行所有的名称空间操作。
Master节点的很多操作会花费很长的时间。
GFS集群是高度分布的多局布局结构,而不是平面结构。
Chunk副本位置选择的策略服务两大目标:最大化数据可靠性和可用性,最大化网络带宽利用率。
Chunk的副本有三个用途:Chunk创建,重新复制和重新负载均衡。
GFS在文件删除后不会立刻回收可用的物理空间。
当Chunk服务器失效时,Chunk的副本有可能因错失了一些修改操作而过期失效。
GM:
MapReduce是一个编程模型,也是一个处理和生成超大数据集的算法模型的相关实现。
MapReduce编程模型的原理是:利用一个输入key/value pair集合来产生一个输出的key/value pair集合。MapReduce库的用户用两个函数表达这个计算:Map和Reduce。
Map函数输出文档中的每个词、以及这个词的出现次数。Reduce函数把Map函数产生的每一个特定的词的计数累加起来。
实现环境:
1. X86架构、运行Linux操作系统、双处理器、2-4GB内存的机器。
2. 普通的网络硬件设备,每个机器的带宽为百兆或者千兆,但是远小于网络的平均带宽的一半。
3. 集群中包含成百上千的机器,因此,机器故障时常态。
4. 存储为廉价的内置IDE硬盘。一个内部分布式文件系统用来管理存储在这些磁盘上的数据。文件系统通过数据复制来在不可靠的硬件上保证数据的可靠性和有效性。
5. 用户提交工作给调度系统。每个工作都包含一系列的任务,调度系统将这些任务调度到集群中多台可用的机器上。
通过将Map调用的输入数据自动分割为M个数据片段的集合,Map调用被分布到多台机器上执行。
Master就像一个数据管道,中间文件存储区域的位置信息通过这个管道从Map传递到Reduce。
Master周期性的ping每个worker。如果在一个约定的时间范围内没有收到worker返回的信息,Master将把这个worker标记为失效。
Master失败需要重新执行MapReduce操作。
调用备用任务来减少“落伍者”出现的情况。
GB:
Bigtable是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的PB级的数据。
Bigtable已经实现了下面几个目标:适用性广泛、可扩展、高性能和高可用性。
Bigtable是一个稀疏的、分布式的、持久化存储的多维度排序Map。
Bigtable是建立在其他的几个Google基础构件上的。
Bigtable使用GFS存储日志文件和数据文件。
Bigtable内部存储数据的文件是Google SSTable格式的。SSTable是一个持久化的、排序的、不可更改的Map结构。
Bigtable还依赖一个高可用的、序列化的分布式锁服务组件,叫做Chubby。
Bigtable包括了三个主要的组件:链接到客户程序中的库、一个Master服务器和多个Table服务器。针对系统工作负载的变化情况,Bigtable可以动态的向集群中添加(或者删除)Tablet服务器。
Master服务器主要负责以下工作:为Tablet服务器分配Tablets、检测新加入的或者过期失效的Tablet服务器、对Tablet服务器进行负载均衡、以及对保存在GFS上的文件进行垃圾收集。
GFS:
为了满足Google迅速增长的数据处理需求。设计目标:性能、可伸缩性、可靠性、可用性等。
组件失效被认为是常态事件,而不是意外事件。
其次,以通常的标准衡量,我们的文件非常巨大。以TB为单位。
第三,绝大部分文件的修改是采用在文件尾部追加数据,而不是覆盖原有数据的方式。
第四,应用程序和文件系统API的协同设计提高了整个系统的灵活性。
系统的工作负载主要由两种读操作组成:大规模的流式读取和小规模的随机读取。
GFS提供了一套类似传统文件系统的API接口函数。另外,GFS提供了快照和记录追加操作。
一个GFS集群包含一个单独的Master节点、多台Chunk服务器,并且同时被多个客户端访问。
GFS存储的文件都被分割成固定大小的Chunk。缺省情况下,我们使用3个存储复制节点。
Master节点管理所有的文件系统元数据。
无论是客户端还是Chunk服务器都不需要缓存文件数据。
单一的Master节点。
Chunk的尺寸为64MB。
Master服务器只需要不到64个字节的元数据就能够管理一个64MB的Chunk。
操作日志包含了关键的元数据变更历史记录。
GFS支持一个宽松的一致性模型。
一个重要的原则:最小化所有操作和Master节点的交互。
客户机向Master节点询问哪一个Chunk服务器持有当前的租约,以及其他副本的位置。
Master节点将主Chunk的标识符以及其他副本的位置返回给客户机。
客户机把数据推送到所有的副本上。
当所有的副本都确认接受到了数据,客户机发送写请求到主Chunk服务器。
主Chunk把写请求传递到所有的二级副本。
所有的二级副本回复主Chunk,它们已经完成了操作。
主Chunk服务器回复客户机。
为了提高网络效率,我们采取了把数据流和控制流分开的措施。
GFS提供了一种原子的数据追加操作-记录操作。
记录追加是一种修改操作。
如果追加操作在任何一个副本上失败了客户端就需要重新进行操作。
快照操作几乎可以瞬间完成对一个文件或者目录树做一个拷贝,并且几乎不会对正在进行的其他操作造成任何干扰。
Master节点执行所有的名称空间操作。
Master节点的很多操作会花费很长的时间。
GFS集群是高度分布的多局布局结构,而不是平面结构。
Chunk副本位置选择的策略服务两大目标:最大化数据可靠性和可用性,最大化网络带宽利用率。
Chunk的副本有三个用途:Chunk创建,重新复制和重新负载均衡。
GFS在文件删除后不会立刻回收可用的物理空间。
当Chunk服务器失效时,Chunk的副本有可能因错失了一些修改操作而过期失效。
GM:
MapReduce是一个编程模型,也是一个处理和生成超大数据集的算法模型的相关实现。
MapReduce编程模型的原理是:利用一个输入key/value pair集合来产生一个输出的key/value pair集合。MapReduce库的用户用两个函数表达这个计算:Map和Reduce。
Map函数输出文档中的每个词、以及这个词的出现次数。Reduce函数把Map函数产生的每一个特定的词的计数累加起来。
实现环境:
1. X86架构、运行Linux操作系统、双处理器、2-4GB内存的机器。
2. 普通的网络硬件设备,每个机器的带宽为百兆或者千兆,但是远小于网络的平均带宽的一半。
3. 集群中包含成百上千的机器,因此,机器故障时常态。
4. 存储为廉价的内置IDE硬盘。一个内部分布式文件系统用来管理存储在这些磁盘上的数据。文件系统通过数据复制来在不可靠的硬件上保证数据的可靠性和有效性。
5. 用户提交工作给调度系统。每个工作都包含一系列的任务,调度系统将这些任务调度到集群中多台可用的机器上。
通过将Map调用的输入数据自动分割为M个数据片段的集合,Map调用被分布到多台机器上执行。
Master就像一个数据管道,中间文件存储区域的位置信息通过这个管道从Map传递到Reduce。
Master周期性的ping每个worker。如果在一个约定的时间范围内没有收到worker返回的信息,Master将把这个worker标记为失效。
Master失败需要重新执行MapReduce操作。
调用备用任务来减少“落伍者”出现的情况。
GB:
Bigtable是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的PB级的数据。
Bigtable已经实现了下面几个目标:适用性广泛、可扩展、高性能和高可用性。
Bigtable是一个稀疏的、分布式的、持久化存储的多维度排序Map。
Bigtable是建立在其他的几个Google基础构件上的。
Bigtable使用GFS存储日志文件和数据文件。
Bigtable内部存储数据的文件是Google SSTable格式的。SSTable是一个持久化的、排序的、不可更改的Map结构。
Bigtable还依赖一个高可用的、序列化的分布式锁服务组件,叫做Chubby。
Bigtable包括了三个主要的组件:链接到客户程序中的库、一个Master服务器和多个Table服务器。针对系统工作负载的变化情况,Bigtable可以动态的向集群中添加(或者删除)Tablet服务器。
Master服务器主要负责以下工作:为Tablet服务器分配Tablets、检测新加入的或者过期失效的Tablet服务器、对Tablet服务器进行负载均衡、以及对保存在GFS上的文件进行垃圾收集。