gfs和hdfs文件系统的区别

转载:http://blog.csdn.net/mindfloating/article/details/49103611

我们知道 HDFS 最早是根据 GFS（Google File System）的论文概念模型来设计实现的。
然后呢，我就去把 GFS 的原始论文找出来仔细看了遍，GFS 的整体架构图如下：

HDFS 参照了它所以大部分架构设计概念是类似的，比如 HDFS NameNode 相当于 GFS Master，HDFS DataNode 相当于 GFS chunkserver。
但还有些细节不同的地方，所以本文主要分析下不同的地方。

写入模型

HDFS 在考虑写入模型时做了一个简化，就是同一时刻只允许一个写入者或追加者。
在这个模型下同一个文件同一个时刻只允许一个客户端写入或追加。
而 GFS 则允许同一时刻多个客户端并发写入或追加同一文件。

允许并发写入带来了更复杂的一致性问题。
多个客户端并发写入时，它们之间的顺序是无法保证的，同一个客户端连续追加成功的多个记录也可能被打断。
这意味着一个客户端在连续写入文件数据时，它的数据最终在文件中的分布可能是不连续的。

所谓一致性就是，对同一个文件，所有的客户端看到的数据是一致的，不管它们是从哪个副本读取的。
如果允许多个客户端同时写一个文件，怎么保证写入数据在多个副本间一致？
我们前面讲 HDFS 时它只允许一个写入者按流水线方式写入多个副本，写入顺序一致，写入完成后数据将保持最终一致。
而对多个客户端而言，就必须让所有同时写入的客户端按同一种流水线方式去写入，才可能保证写入顺序一致。
这个写入流程我们下一节详细分析。

写入流程

GFS 使用租约机制来保障在跨多个副本的数据写入中保持顺序一致性。
GFS Master 将 chunk 租约发放给其中一个副本，这个副本我们就称为主副本，其他副本称为次副本。
由主副本来确定一个针对该 chunk 的写入顺序，次副本则遵守这个顺序，这样就保障了全局顺序一致性。
chunk 租约机制的设计主要是为了减轻 Master 的负担，由主副本所在的 chunkserver 来承担流水线顺序的安排。
如下图，我们详细描述下这个过程。

客户端请求 Master 询问哪个 chunkserver 持有租约以及其他副本的位置。
如果没有 chunkserver 持有租约，说明该 chunk 最近没有写操作。
Master 则选择将租约授权给其中一台 chunkserver。
Master 返回客户端主副本和次副本的位置信息。
客户端缓存这些信息以备将来使用。
客户端以后不再需要联系 Master，除非主副本所在 chunkserver 不可用或返回租约过期了。
客户端选择最优的网络顺序推送数据，chunkserver 将数据先缓存在内部的 LRU 缓存中。
GFS 中采用数据流和控制流分离的方法，从而能够基于网络拓扑结构更好地调度数据流的传输。
一旦所有的副本确认收到了数据，客户端将发送一个写请求控制命令到主副本。
由主副本分配连续的序列号来确定最终的写入顺序。
主副本转发写请求到所有次副本，次副本按主副本安排的顺序执行写入操作。
次副本写完后向主副本应答确认操作完成。
最后主副本应答客户端，若任意副本写入过程中出现错误，将报告给客户端，由客户端发起重试。

GFS 和 HDFS 的写入流程都采用了流水线方式，但 HDFS 没有分离数据流和控制流。
HDFS 的数据流水线写入在网络上的传输顺序与最终写入文件的顺序一致。
而 GFS 数据在网络上的传输顺序与最终写入文件的顺序可能不一致。
GFS 在支持并发写入和优化网络数据传输方面做出了最佳的折衷。

总结

GFS 的论文发表于 2003 年，后来大部分的分布式文件系统设计实现或多或少都参考了 GFS 的设计思路。
而 HDFS 算是开源分布式文件系统中最完整实现了 GFS 论文中的概念模型。
但 HDFS 依然简化了 GFS 中关于并发写的思路，本文就两者的写入模型和过程做了一些对比说明，并希望引发一些思考。

参考

[1] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System
[2] Hadoop Documentation. HDFS Architecture.
[3] Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas. The Hadoop Distributed File System
[4] Tom White. Hadoop: The Definitive Guide. O’Reilly Media(2012-05), pp 94-96
[5] Yongjun Zhang. Understanding HDFS Recovery Processes
[6] Hairong Kuang, Konstantin Shvachko, Nicholas Sze, Sanjay Radia,  Robert Chansler , Yahoo! HDFS team  Design Specification: Append/Hflush/Read Design 
[7] HDFSteam. Design Specification: HDFS Append and Truncates

GFS：Google File System
HDFS：Hadoop Distribute File System首先，有一点要确认的是，作为GFS的一个最重要的实现，HDFS设计目标和GFS是高度一致的。在架构、块大小、元数据等的实现上，HDFS与GFS大致一致。但是，在某些地方，HDFS与GFS又有些不同。如：1、   快照（Snapshot）：GFS中的快照功能是非常强大的，可以非常快的对文件或者目录进行拷贝，并且不影响当前操作（读/写/复制）。GFS中生成快照的方式叫copy-on-write。也就是说，文件的备份在某些时候只是将快照文件指向原chunk，增加对chunk的引用计数而已，等到chunk上进行了写操作时，Chunk Server才会拷贝chunk块，后续的修改操作落到新生成的chunk上。而HDFS暂时并不支持快照功能，而是运用最基础的复制来完成。想象一下，当HBase上的数据在进行重新划分时（过程类似于hash平衡），HDFS需要对其中的所有数据（P/T级的）进行复制迁移，而GFS只需要快照，多不方便！2、 记录追加操作（append）：在数据一致性方面，GFS在理论上相对HDFS更加完善。a)    GFS提供了一个相对宽松的一致性模型。GFS同时支持写和记录追加操作。写操作使得我们可以随机写文件。记录追加操作使得并行操作更加安全可靠。b) HDFS对于写操作的数据流和GFS的功能一样。但是，HDFS并不支持记录追加和并行写操作。NameNode用INodeFileUnderConstruction属性标记正在进行操作的文件块，而不关注是读还是写。DataNode甚至看不到租约！一个文件一旦创建、写入、关闭之后就不需要修改了。这样的简单模型适合于Map/Reduce编程。3、 垃圾回收（GC）：a)    GFS垃圾回收采用惰性回收策略，即master并不会立即回收程序所删除的文件资源。 GFS选择以一种特定的形式标记删除文件（通常是将文件名改为一个包含时间信息的隐藏名字），这样的文件不再被普通用户所访问。Master会定期对文件的命名空间进行检查，并删除一段时间前的隐藏文件（默认3天）。b) HDFS并没有采用这样的垃圾回收机制，而是采取了一种更加简单但是更容易实现的直接删除方式。c)  应该说延迟回收和直接删除各有优势。延迟回收为那些“不小心“的删除操作留了后路。同时，回收资源的具体操作时在Master结点空闲时候完成，对GFS的性能有很好的提高。但是延迟回收会占用很大的存储空间，假如某些可恶的用户无聊了一直创建删除文件怎么办？试分析下这种不同。有人说，GFS在功能上非常完善，非常强大，而HDFS在策略上较之简单些，主要是为了有利于实现。但实际上，GFS作为存储平台早已经被广泛的部署在Google内部，存储Google服务产生或者要处理的数据，同时用于大规模数据集的研究与开发工作。因此GFS并不仅仅是理论上的研究，而是具体实现。作为GFS的后辈与开源实现，HDFS在技术上应该是更加成熟的，不可能为了“偷懒”而简化功能。因此，简化说应该是不成立的。个人认为，GFS与HDFS的不同是由于“专”与“通”的区别。众所周知，Hadoop是一个开源软件/框架，在设计之初就考虑到了用户（面向世界上的所有个人、企业）在需求上的差异，比如数据密集型（如淘宝的数据存储）、计算密集型（百度的PR算法）、混合型等等。而GFS在设计之初就对目标比较明确，都是Google的嘛，因此GFS可以对其主要功能进行性能上的优化。