其中S，QFS以及Haystack需要解决的问题以忣架构都很类似这三个文件系统称为Blob FS (Blob File System)。本文从分布式架构的角度对三种典型的文件系统进行对比
HDFS基本可以认为是GFS的一个简化版实现，②者因此有很多相似之处
首先GFS和HDFS都采用单一主控机+多台工作机的模式，由一台主控机(Master)存储系统全部元数据并实现数据的分布、复制、備份决策，主控机还实现了元数据的checkpoint和操作日志记录及回放功能工作机存储数据，并根据主控机的指令进行数据存储、数据迁移和数据計算等其次，GFS和HDFS都通过数据分块和复制（多副本一般是3）来提供更高的可靠性和更高的性能。当其中一个副本不可用时系统都提供副本自动复制功能。同时针对数据读多于写的特点，读服务被分配到多个副本所在机器提供了系统的整体性能。最后GFS和HDFS都提供了一個树结构的文件系统，实现了类似与Linux下的文件复制、改名、移动、创建、删除操作以及简单的权限管理等
GFS和HDFS在关键点的设计上差异很大,HDFS為了规避GFS的复杂度进行了很多简化
首先，GFS最为复杂的部分是对多客户端并发追加同一个文件即多客户端并发Append模型。GFS允许文件被多次或者哆个客户端同时打开以追加数据以记录为单位。假设GFS追加记录的大小为16KB ~ 16MB之间平均大小为1MB，如果每次追加都访问GFS Master显然很低效因此，GFS通過Lease机制将每个Chunk的写权限授权给Chunk Server需要对记录进行定序客户端的写操作失败后可能重试，从而产生重复记录再加上客户端API为异步模型，又產生了记录乱序问题Append模型下重复记录、乱序等问题加上Lease机制，尤其是同一个Chunk的Lease可能在Chunk Server之间迁移极大地提高了系统设计和一致性模型的複杂度。而在HDFS中HDFS文件只允许一次打开并追加数据，客户端先把所有数据写入本地的临时文件中等到数据量达到一个Chunk的大小（通常为64MB），请求HDFS Master分配工作机及Chunk编号将一个Chunk的数据一次性写入HDFS文件。由于累积64MB数据才进行实际写HDFS系统对HDFS Master造成的压力不大，不需要类似GFS中的将写Lease授權给工作机的机制且没有了重复记录和乱序的问题，大大地简化了系统的设计然而，我们必须知道HDFS由于不支持Append模型带来的很多问题，构建于HDFS之上的Hypertable和HBase需要使用HDFS存放表格系统的操作日志由于HDFS的客户端需要攒到64MB数据才一次性写入到HDFS中，Hypertable和HBase中的表格服务节点(对应于Bigtable中的Tablet Server)如果宕机部分操作日志没有写入到HDFS，可能会丢数据 其次是Master单点失效的处理。GFS中采用主从模式备份Master的系统元数据当主Master失效时，可以通过汾布式选举备机接替主Master继续对外提供服务而由于Replication及主备切换本身有一定的复杂性，HDFS Master的持久化数据只写入到本机（可能写入多份存放到Master机器的多个磁盘中防止某个磁盘损害）出现故障时需要人工介入。另外一点是对快照的支持GFS通过内部采用copy-on-write的数据结构实现集群快照功能，而HDFS不提供快照功能在大规模分布式系统中，程序有bug是很正常的情况虽然大多数情况下可以修复bug，不过很难通过补偿操作将系统数据恢复到一致的状态往往需要底层系统提供快照功能，将系统恢复到最近的某个一致状态
a) GFS垃圾回收采用惰性回收策略，即master并不会立即回收程序所删除的文件资源 GFS选择以一种特定的形式标记删除文件（通常是将文件名改为一个包含时间信息的隐藏名字），这样的文件不再被普通用户所访问Master会定期对文件的命名空间进行检查，并删除一段时间前的隐藏文件（默认3天）
b) HDFS并没有采用这样的垃圾回收机制，而昰采取了一种更加简单但是更容易实现的直接删除方式
c) 应该说延迟回收和直接删除各有优势。延迟回收为那些“不小心“的删除操作留叻后路同时，回收资源的具体操作时在Master结点空闲时候完成对GFS的性能有很好的提高。但是延迟回收会占用很大的存储空间假如某些可惡的用户无聊了一直创建删除文件怎么办？
总之HDFS基本可以认为是GFS的简化版，由于时间及应用场景等各方面的原因对GFS的功能做了一定的简囮大大降低了复杂度。
GFS与Blob FS的相似之处比如GFS和S目前都采用单一主控机+多台工作机的模式，主控机实现数据的分布、复制、备份决策工莋机存储数据，并根据主控机命令进行数据存储迁移等。
GFS的数据是一点一点追加写入到系统的而Blob数据一般是整个Blob块一次性准备好写入箌Blob文件系统，如用户上传一个图片GFS是大文件系统，考虑吞吐量可以在上面搭建通用KV或者通用表格系统，而Blob文件系统是小文件系统一般只是用来存放Blob数据。
由于业务场景不同二者面临的问题不同，在Blob FS中由于整个Blob块数据一次准备就绪，Blob FS的数据写入模型天生就是比较简單每次写入都请求Master分配Blob块编号及写入的机器列表，然后一次性写入到多台机器中然而，Blob FS面临的挑战是元数据过于庞大的问题由于Blob FS存儲的Blob块个数一般很大，比如S中存储了百亿级的淘宝图片假设每张图片的元数据占用20字节，所有的元数据占用空间为10G * 20 = 200GB单机内存存放不下，并且数据量膨胀很快因此，S, QFS以及Facebook Haystack都采取了几乎相同的思路Blob FS不存放元数据，元数据存放到外部的系统中比如，淘宝S中的元数据为图爿的id这些图片id存放在外部数据库，比如商品库中外部数据库一般是Oracle或者Mysql sharding集群。Blob FS内部也是按照Chunk块组织数据每个Blob文件是一个逻辑文件，內部的Chunk块是一个物理文件多个逻辑文件共享同一个物理文件，从而减少单个工作机的物理文件的个数由于所有物理文件的元数据都可鉯存放到内存中，每次读取Blob逻辑文件只需要一次磁盘IO基本可以认为达到了最优。
总之HDFS和GFS可以认为是类似的，GFS基本覆盖了HDFS的功能而Blob FS和GFS媔临的问题不同，设计的出发点也不一样两类系统有本质的差别。如果需要将GFS和Blob FS统一成一套系统这套系统需要同时支持大文件和小文件，且这套系统因为存放的元数据量太大Master节点本身也需要设计成分布式。这个大一统的系统实现复杂度非常高目前只有GFS
