分布式文件系统

分布式文件系统Google文件系统GFS系统架构容错机制系统管理技术Google业务全球最大搜索引擎、GoogleMaps、GoogleEarth、Gmail、YouTube等数据量巨大，且面向全球用户提供实时服务

Google云计算平台技术架构文件存储，GoogleDistributedFileSystem，GFS并行数据处理MapReduce分布式锁Chubby分布式结构化数据表BigTable分布式存储系统Megastore分布式监控系统Dapper

秘密武器：云计算平台！GFS设计动机Google需要一个支持海量存储的文件系统购置昂贵的分布式文件系统与硬件？为什么不使用当时现存的文件系统？Google所面临的问题与众不同

不同的工作负载，不同的设计优先级（廉价、不可靠的硬件）需要设计与Google应用和负载相符的文件系统是否可以在一堆廉价且不可靠的硬件上构建可靠的分布式文件系统？GFS设计背景Google的应用负载和技术环境集群中的节点失效是一种常态，而不是一种异常。按照传统标准，文件都是非常巨大的，通常以G字节计。大部分文件都是只会在文件尾新增加数据，而少见修改已有数据的。应用程序和文件系统API的协同设计提高了整个系统的灵活性。

5GFS设计背景设计预期持续监视、错误检测、容错处理、自动恢复对大文件有效管理同时支持小型文件文件超大文件的顺序写入、随机小规模的写入大量的操作为在文件后追加数据，几乎没有随机写入，写完后只读，且读取方式基本上只有大规模顺序读和小规模随机读支持多路合并模式进行操作高性能的稳定带宽的网络要比低延时更加重要接口常见操作create、delete、open、close、read、write特殊操作snapshot、recordappend(原子操作)6GFS将容错的任务交给文件系统完成，利用软件的方法解决系统可靠性问题，使存储的成本成倍下降。GFS将服务器故障视为正常现象，并采用多种方法，从多个角度，使用不同的容错措施，确保数据存储的安全、保证提供不间断的数据存储服务

GFS架构是怎样的？系统架构Client（客户端）：应用程序的访问接口

Master（主服务器）：管理节点，在逻辑上只有一个，保存系统的元数据，负责整个文件系统的管理ChunkServer（数据块服务器）：负责具体的存储工作。数据以文件的形式存储在ChunkServer上实现机制客户端首先访问Master节点，获取交互的ChunkServer信息，然后访问这些ChunkServer，完成数据存取工作。这种设计方法实现了控制流和数据流的分离。Client与Master之间只有控制流，而无数据流，极大地降低了Master的负载。Client与ChunkServer之间直接传输数据流，同时由于文件被分成多个Chunk进行分布式存储，Client可以同时访问多个ChunkServer，从而使得整个系统的I/O高度并行，系统整体性能得到提高。

GFS特点有哪些？GFS特点采用中心服务器模式可以方便地增加ChunkServerMaster掌握系统内所有ChunkServer的情况，方便进行负载均衡不存在元数据的一致性问题不缓存数据

文件操作大部分是流式读写，不存在大量重复读写，使用Cache对性能提高不大ChunkServer上数据存取使用本地文件系统，若读取频繁，系统具有Cache从可行性看，Cache与实际数据的一致性维护也极其复杂在用户态下实现

利用POSIX编程接口存取数据降低了实现难度，提高通用性

POSIX接口提供功能更丰富

用户态下有多种调试工具

Master和ChunkServer都以进程方式运行，单个进程不影响整个操作系统

GFS和操作系统运行在不同的空间，两者耦合性降低只提供专用接口降低实现的难度对应用提供一些特殊支持降低复杂度

GFSArchitectureClientClient代码包含了google文件系统的API，并且会和master和

chunkserver进行通信。client和master通信—交互元数据信息client会缓存从master获取的元数据信息，以便对同一块

的操作不在通过client-master交互。client和chunkserver通信—交互文件数据client所有的数据相关的通信是直接和chunkserver进行，

但是不会缓存文件数据。11GFSArchitectureReadoperateClient读取数据的操作顺序：client把应用要读取的文件名和偏移量，根据固定的chunk大小，转换成为文件的chunkindex。向master发送这个包含了文件名和chunkindex的请求。master返回相关的chunkhandle以及对应的位置，client缓存这些信息。client就向最近的对应位置的chunkserver发起请求，请求包含chunkhandle以及一个在这个chunk内需要读取得字节区间。chunkserver返回给client要读取的chunkdata。12GFSArchitectureMaster负责管理所有的文件系统的元数据文件和chunk的namespace访问控制信息文件到chunk的映射关系当前chunk的位置等等Master控制系统级别的活动chunk的分配管理孤点chunk的垃圾回收机制chunk在chunkserver之间的移动Master用心跳信息周期地跟每个chunkserver通信，给他们以指示并收集他们的状态单一Master设计必须减小master的读/写操作，以避免它成为集群瓶颈。Master13GFSArchitectureMaster保存三种类型的数据：文件和chunk的namespace文件到chunks的映射关系每个chunk副本的位置所有的元数据都是保存在Master的内存里。前两个由在master本地硬盘的记录所有变化信息的operationlog来持久化保存的，这个记录也会在远端机器上保存副本。Master并不持久化保存chunk位置信息，启动地时候以及chunkserver加入集群的时候，向每一个chunkserver询问他的chunk信息。Metadata14GFSArchitectureOperationlog保存了关键的元数据变化历史记录,它是GFS的核心。同时作为逻辑时间基线，定义了并行操作的顺序。为了Operationlog的可靠性，保证写log原子性。我们把这个文件保存在多个不同的主机上，并且只有当刷新这个相关的操作记录到本地和远程磁盘之后，才会给客户端操作应答。master通过自己的operationlog回滚自身文件系统状态。

为了减少启动时间，我们必须尽量减少操作日志的大小，采用checkpoint操作。master的恢复时候，只需要最新的checkpoint以及后续的log文件。Operationlog15GFS

Architecture在GFS下，每一个文件都拆成固定大小的chunk(块)。每一个块都由master根据块创建的时间产生一个全局唯一的以后不会改变的64位的chunkhandle标志。chunkservers在本地磁盘上用Linux文件系统保存这些块，并且根据chunkhandle和字节区间，通过Linux文件系统读写这些块的数据。出于可靠性的考虑，每一个块都会在不同的chunkserver上保存备份。缺省情况下，我们保存3个备份。Chunkserver16GFSArchitectureChunksize是设计的关键参数(64M)。采用很大的chunksize优点：它减少了客户端和master的交互。减少网络管理量。减少了元数据在master上的大小。采用很大的chunksize缺点：小型文件包含较少数目的chunk，也许只有一个chunk。保存这些文件的chunkserver就会在大量客户端访问的时候就会成为焦点，导致系统局部过载。Chunksizeize17GFS读Applications通过GFSclient向GFS提交一个读请求，Client会将文件名（filename）和chunkindex（通过程序指定的字节偏移和固定的chunksize可以计算出chunk的偏移，发送给GFSMasterMaster通过filename在namespace中找到相应的metadata，metadata中包含有文件对应chunk的chunkhandle和所在在的chunkserver的位置client缓存Master回复的metadata。Client直接去找chunkserver数据，请求信息包含了chunkhandle和byterange。chunkserver返回具体的数据。client不必再和master交互了，直接向chunkserver要数据，除非client上缓存的metadata过期了，或者文件被重新打开了。2015/10/17GFS写一是单个client顺序写二是多客户端的并行写这里的写指都是追加操作一致性Lease租约Checkpoint时间戳Checksum校验2015/10/17GFSWrite

客户端向Master请求chunk每个副本所在的ChunkServer，其中PrimaryChunkServer持有修改Lease。如果没有ChunkServer持有Lease，说明该chunk最近没有写操作，Master会创议一个任务，按照一定的策略将chunk的Lease授权给个中一台chunkServer。

Master返回客户端Primary和其它ChunkServer的位置信息，客户端将缓存这些信息供以后使用。如果不出现故障，客户端以后读写该chunk都不需要再次请求Master。

客户端将要追加的记录发送到每个副本。每个ChunkServer会在内部的LRU构造中缓存这些数据。GFS中采用数据流和控制流星散的方法，从而能够基于收集拓扑布局更好地调剂数据流的传输。当所有副本都确认收到了数据，客户端倡议一个写要求控制号令给Primary。因为Primary可能收到多个客户端对同一个chunk的并发追加操作，Primary将确定这些操作的挨次并写入当地；Primary把写请求提交给所有的Secondary副本。每一个Secondary会按照Primary确定的递次执行写操作；Secondary副本成功完成后应对Primary；

Primary应答客户端，如果有副本发生错误，将出现Primary写成功但是某些Secondary不成功的情况，客户端将重试。2015/10/17GFSArchitecture文件名字空间的改变（比如，文件的创建）是原子操作。他们是由master来专门处理的。名字空间的锁定保证了操作的原子性以及正确性。如果不论从哪个副本上读，所有的客户都看到同样的数据，那么文件的这个区域就是一致的。如果文件的区域是一致的并且用户可以看到修改操作所写的数据，那么它就是已定义的。

Consistencymodel21GFSArchitecture数据更改可能是写一个记录或是一个记录增加（writes/recordappends）写操作会把数据写在应用程序指定的偏移位置。记录增加会导致数据（记录）增加，这个增加即使是在并发操作中也至少是一个原子操作。GFS可以在这些记录之间增加填充，或者仅仅是记录的重复。这些确定区间之间的填充或者记录的重复是不一致的，并且通常是因为用户记录数据量比较小造成的。一系列成功的改动之后，改动后的文件区是确保确定的对所有的数据副本，按照相同顺序对chunk进行提交数据的改动来保证这样的一致性。采用chunk的版本号码控制，来检查是否有过期的chunk改动，这种通常发生在chunkserver宕机的情况下。过期的副本将不参加到改动或者提交给master，让master通知客户端这个副本chunk的位置。

Consistencymodel22GFS删除一个文件删除时，Master节点象对待其它修改操作一样，立刻把删除操作以日志的方式记录下来。Master节点并不马上回收资源，而是把文件名改为一个包含删除时间戳的、隐藏的名字。当Master节点对文件系统命名空间做常规扫描的时候，它会删除所有三天前的隐藏文件。直到文件被真正删除，它们仍旧可以用新的特殊的名字读取，也可以通过把隐藏文件改名为正常显示的文件名的方式“反删除”。当隐藏文件被从名称空间中删除，Master服务器内存中保存的这个文件的相关元数据才会被删除。2015/10/17Google文件系统GFS系统架构容错机制系统管理技术Master容错

MasterNameSpace，文件系统目录结构

Chunk与文件名的映射Chunk副本的位置信息(默认有三个副本)

NameSpace，文件系统目录结构

Chunk与文件名的映射Chunk副本的位置信息Master单个Master，对于前两种元数据，GFS通过操作日志来提供容错功能

第三种元数据信息保存在各个ChunkServer上，Master故障时，磁盘恢复

GFS还提供了Master远程的实时备份,防止Master彻底死机的情况ChunkServer容错

采用副本方式实现ChunkServer容错每一个Chunk有多个存储副本（默认为三个），分布存储在不同的ChunkServer上用户态的GFS不会影响ChunkServer的稳定性副本的分布策略需要考虑多种因素，如网络的拓扑、机架的分布、磁盘的利用率等对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入GFS中的每一个文件被划分成多个Chunk，Chunk的默认大小是64MBChunkServer存储的是Chunk的副本，副本以文件的形式进行存储每个Chunk又划分为若干Block（64KB），每个Block对应一个32bit的校验码，保证数据正确（若某个Block错误，则转移至其他Chunk副本）尽管一份数据需要存储三份，好像磁盘空间的利用率不高，但综合比较多种因素，加之磁盘的成本不断下降，采用副本无疑是最简单、最可靠、最有效，而且实现的难度也最小的一种方法。Simple,andgoodenough!Google文件系统GFS系统架构容错机制系统管理技术大规模集群安装技术故障检测技术

节点动态加入技术

节能技术

新的ChunkServer加入时，只需裸机加入，大大减少GFS维护工作量

GFS构建在不可靠廉价计算机之上的文件系统，由于节点数目众多，故障发生十分频繁

Google采用了多种机制降低服务器能耗，如采用蓄电池代替昂贵的UPS系统管理技术GFS集群中通常有非常多的节点，需要相应的技术支撑

小结简单的，就是最好的！思考GFS有什么问题吗？提纲Hadoop简介Hadoop分布式文件系统HDFSHDFS使用HDFS2015/10/17Hadoop简介

Hadoop——Apache开源组织的一个分布式计算框架，可以在大量廉价的硬件设备组成的集群上运行应用程序，为应用程序提供了一组稳定可靠的接口，旨在构建一个具有高可靠性和良好扩展性的分布式系统

Hadoop云计算系统Google云计算系统HadoopHDFSGoogleGFSHadoopMapReduceGoogleMapReduceHadoopHBaseGoogleBigtableHadoopZooKeeperGoogleChubbyHadoopPigGoogleSawzallHadoop云计算系统与Google云计算系统

Hadoop简介开源项目Lucene：Java开发的开源高性能全文检索工具包

开源项目Nutch：第一个开源的Web搜索引擎

Hadoop

Hadoop简介Hadoop项目组成

（1）HadoopCommon（2）Avro（3）Chukwa（4）HBase（5）HDFS（6）Hive（7）MapReduce（8）Pig（9）ZooKeeper

Hadoop优点

（1）可扩展（2）经济（3）可靠（4）高效提纲Hadoop简介Hadoop分布式文件系统HDFSHDFS使用设计前提与目标

设计前提与目标硬件错误是常态而不是异常流式数据访问

超大规模数据集

简单一致性模型

移动计算比移动数据更简单

异构软硬件平台间的可移植性

体系结构HDFS主从结构体系NameNode：主控制服务器，负责维护文件系统的命名空间（Namespace）并协调客户端对文件的访问，记录命名空间内的任何改动或命名空间本身的属性改动DataNode：负责它们所在的物理节点上的存储管理保障可靠性的措施

1．冗余备份每个文件存储成一系列数据块（Block），默认块大小为64MB（可配置）。为了容错，文件的所有数据块都会有副本（副本数量即复制因子，可配置）2．副本存放采用机架感知（Rack-aware）的策略来改进数据的可靠性、可用性和网络带宽的利用率

复制因子为3时数据块分布情况

保障可靠性的措施

3.心跳检测NameNode周期性地从集群中的每个DataNode接受心跳包和块报告，收到心跳包说明该DataNode工作正常4.安全模式系统启动时，NameNode会进入一个安全模式。此时不会出现数据块的写操作5.数据完整性检测

HDFS客户端软件实现了对HDFS文件内容的校验和（Checksum）检查保障可靠性的措施

6.空间回收

文件被用户或应用程序删除时，先把它移动到/trash目录里；只要还在这个目录里，文件就可以被迅速恢复7.元数据磁盘失效NameNode可以配置为支持维护映像文件和事务日志的多个副本，任何对映像文件或事务日志的修改，都将同步到它们的副本上8.快照

快照支持存储某个时间的数据复制，当HDFS数据损坏时，可以回滚到过去一个已知正确的时间点。HDFS目前还不支持快照功能提升性能的措施

提升性能措施副本选择HDFS会尽量使用离程序最近的副本来满足用户请求，这样可以减少总带宽消耗和读延时

负载均衡HDFS的架构支持数据均衡策略

客户端缓存HDFS客户端先把数据缓存到本地的一个临时文件，程序的写操作透明地重定向到这个临时文件流水线复制DataNode从前一个节点接收数据的同时，即时把数据传给后面的节点，这就是流水线复制访问接口

HadoopAPI（1）org.apache.hadoop.conf（2）org.apache.hadoop.dfs（3）org.apache.hadoop.fs（4）org.apache.hadoop.io（5）org.apache.hadoop.ipc（6）org.apache.hadoop.mapred（7）org.apache.hadoop.metrics（8）org.apache.hadoop.record（9）org.apache.hadoop.tools（10）org.apache.hadoop.util浏览器接口典型HDFS安装会配置一个Web服务器开放自己的命名空间，其TCP端口可配；默认配置下http://namenode-name:50070这个页面列出了集群里的所有DataNode和集群的基本状态

提纲Hadoop简介Hadoop分布式文件系统HDFSHDFS使用Overview2015/10/17Writing

Data2015/10/17Writing

Data2015/10/17Writing

Data2015/10/17Reading

Data2015/10/17Fault2015/10/17Fault2