GFS.BigTable.MapReduce谷歌论文学习笔记

个人在做hadoop有关的开发，作为这种国宝始祖级别的论文无论如何都是要拜读一下的，正好可以从中了解到一些hadoop内部运行机制，读罢不得不掩卷而叹，精，精巧，精准 1.GFS(Google File System) GFS提供了一个与位置无关的名字空间，这使得数据可以为了负载均衡或灾难冗余等目的在不同位置间透明迁移。 GFS并没有在文件系统层面提供任何Cache机制。 GFS没有正对每个目录实现能够列出目录下所有文件的数据结构。 GFS文件以分层目录的形式组织，用路径名来表示。支持的常用操作：创建新文件，删除文件，打开文件，关闭文件，读和写文件。 Chunk服务器： Chunk服务器上的元数据，大部分是用户数据（Chunk块所切分的64kb块）的Checksun，和Chunk的版本号。 Chunk服务器上保存有大量Chunk副本。 对新加入的Chunk服务器负载的调整：周期性检查，逐步调整。 Master服务器与Chunk服务器的心跳中，Chunk服务器在心跳信息中报告它所存储的Chunk子集，Master则通过比较版本号来确定那些Chunk块已经过期，Chunk服务器进行删除。 Chunk块（64MB）： GFS存储文件分割成固定大小的Chunk（64MB）。 每个Chunk有不变，唯一的64位标识。 每个Chunk副本都以普通Linux文件的形式保存在Chunk服务器上。 Master服务器： 元数据：以前缀压缩模式存放的文件名，文件的所有者和权限，文件到Chunk的映射关系，每一个Chunk的当前版本号。 Master服务器内存中拥有完整的从文件到块的映射表。 元数据全部保存在内存中。 通过checkpoint和重演日志操作来进行灾难恢复。 GFS使用租约（lease）机制来保持多个副本见变更顺序的一致性。 Master节点将主Chunk及副本位置返回给客户机。之后的数据传输，检验都在Chunk和客户机之间进行。 主Chunk服务器定义写顺序。 GFS系统运行的2个基本流程： Master服务器与Chunk服务器的交互
Chunk服务器周期性在心跳信息中向Master服务器汇报自己保存的Chunk信息。Master服务器指导Chunk服务器删除，复制Chunk块。
当有新的Chunk服务器进入系统时，Master服务器会在负载均衡算法中会发现这个机器的负载很轻，然后逐步将其他Chunk块转移到次Chunk服务器上。
当有Chunk服务器掉线时，Master服务器会根据掉线服务器导致的Chunk块数量离标准配置的差别确定优先级，来分配新的Chunk服务器存储丢失的Chunk块 文件的存储过程
当有一个新的文件需要存储时。Master服务器保存该文件与Chunk块的对应信息，并使用lease机制来写入数据。并且根据Chunk服务器的心跳信息来维护该文件的存储备份数量。
2.BigTable BigTable使用Google的分布式文件系统（GFS） BigTable的客户不必通过Master服务器来获取Tablet的位置信息。 BigTable：系数，分布式，持久化存储的多维度排序Map。 一个BigTable集群有很多表，每个表是一个Tablet的集合。 1.行：行操作是原子操作。 一个表按行划分为不同的Tablet。 一个Tablet只能分给一个Tablet 一个Tablet服务器上可以有几十到上千个Tablet。 对Tablet可以做的操作有读写，合并，分割。 2.列： 一个列族由多个列组成，存放在同一个列族下的所有数据通常都数据同一个类型。 一张表可以有几百个列族，一张表可以有无限多个列。 Tablet可以按照列族的相关性分类存储为不同的SSTable（数据的逻辑相关性决定其物理相关性） SSTable：持久化的，排序的，不可更改的Map结构 可以对SSTable执行的操作:查询与一个可以值相关的value，遍历某个key值范围内的所有key-value对。 从内部看：SSTable是一些列的数据块（64kb）：在SSTable中查找内容时可以在内存中加载块索引。 部分特殊群组的SSTable可以设置一直存放在内存中（如METADATA） SSTable的大小可以有群组参数指定（可以自定义） SSTable可以压缩后存储，因为解压缩很快，不会很影响性能，而且事实上的压缩比很高 可以通过对部分特定SSTable设置布隆过滤器来减少对磁盘的访问
3.行+列：数据项 表中每一个数据项都可以包含同一数据的不同版本（通过时间戳来进行索引） BigTable暴多三个主要的组件：连接到客户程序中的库，一个Master服务器和多个Tablet服务器。 Master服务器的工作： 为Tablet服务器分配Tablets 监测新加入的或者过期失效的Table服务器 对Tablet服务器进行负载均衡 模式相关：新建表和列族 针对系统工作负载的变化情况，BigTable可以动态的想集群中添加删除Tablet服务器。 Master服务器记录了当前有哪些活跃的Tablet服务器，哪些Tablet分配给了那些Tablet服务器，那些Tablet还没有被分配。 问题：Table分成Tablet是Master做的嘛？ BigTable与GFS的关系： GFS是分布式文件系统，BigTable 是建立在GFS之上的。就像文件系统需要数据库来存储结构化数据一样，GFS也需要Bigtable来存储结构化数据，每个Table都是一个多维的稀疏图，为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每个Tablets大概有 100-200 MB，每个机器存储100个左右的 Tablets。底层的架构是：GFS。由于GFS是一种分布式的文件系统，采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应的表移动到其他空闲机器上，然后快速重建。

3.Hadoop与google三大件：

Hadoop是很多组件的集合，主要包括但不限于MapReduce，HDFS，HBase，ZooKeeper。 MapReduce模仿了Google的MapReduce， HDFS模仿了Google File System， HBase模仿了BigTable， 所以下文只出现MapReduce、HDFS和HBase。
简单来讲， HDFS和HBase是依靠外存（即硬盘）的存储模型和实现。HDFS是一个云存储的文件系统，它会把一个文件分块并分别保存，取用时分别取出再合并。重要的是，这些分块通常会在3台节点（即机群内的电脑）上有3个备份，所以即使出现少数电脑的失效（硬盘损坏、掉电等），文件也不会失效。如果说HDFS是文件级别的存储，那HBase则是表级别的存储。HBase是一个表模型，但比SQL数据库的表要简单的多，没有连接、聚集等功能。HBase表的物理存储是依赖HDFS的，比如把一个表分成4个文件，存到HDFS中。由于HDFS级会做备份，所以HBase级不再备份。
MapReduce则是一个计算模型，而不是存储模型；MapReduce与HDFS紧密配合，而非HBase。举个场景：如果你的手机通话信息保存在一个HDFS的文件callList.txt中，你想找到你与你同事A的所有通话记录并排序。因为HDFS会把callLst.txt分成几块分别存，比如说5块，那么对应的Map过程就是找到这5块所在的5台节点，让他们分别找自己存的那块中关于A的通话记录，对应的Reduce过程就是把5个节点过滤过的通话记录合并在一块并按时间排序。可见MapReduce的计算模型需要HDFS，但与HBase没有任何关系。
ZooKeeper本身是一个非常牢靠的记事本，最好用于记录一些概要信息。Hadoop依靠这个记事本来记录当前哪些节点正在用，哪些已掉线，哪些还备用等，以此来管理机群。

3大论文中文版下载：http://yunpan.cn/QDhPcnYVQt2hM