分布式文件系统架构GFS、HDFS、TFS、Haystack

分布式文件系统架构GFS、HDFS、TFS、Haystack


分布式文件系统很多，包括GFS，HDFS，淘宝开源的TFS，Tencent用于相册存储的TFS (Tencent FS，为了便于区别，后续称为QFS)，以及Facebook Haystack。

分布式文件系统通常可以作为底层存储，如GFS作为Google bigtable的底层，EBS作为 Amazon RDS的底 层，HDFS作为HBase的底层文件系统

其中，TFS，QFS以及Haystack需要解决的问题以及架构都很类似，这三个文件系统称为Blob FS (Blob File System)。本文从分布式架构的角度对三种典型的文件系统进行对比。

GFS --------------- HDFS

  • GFS
  • HDFS

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。写Lease的含义是Chunk Server对某个Chunk在Lease有效期内(假设为12s)有写权限，拥有Lease的Chunk Server称为Primary
    Chunk Server，如果Primary Chunk Server宕机，Lease有效期过后Chunk的写Lease可以分配给其它Chunk Server。多客户端并发追加同一个文件导致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，不过很难通过补偿操作将系统数据恢复到一致的状态，往往需要底层系统提供快照功能，将系统恢复到最近的某个一致状态。
  • 垃圾回收（GC）： 
    a)  GFS垃圾回收采用惰性回收策略，即master并不会立即回收程序所删除的文件资源。 GFS选择以一种特定的形式标记删除文件（通常是将文件名改为一个包含时间信息的隐藏名字），这样的文件不再被普通用户所访问。Master会定期对文件的命名空间进行检查，并删除一段时间前的隐藏文件（默认3天）。

b)  HDFS并没有采用这样的垃圾回收机制，而是采取了一种更加简单但是更容易实现的直接删除方式。

c)  应该说延迟回收和直接删除各有优势。延迟回收为那些“不小心“的删除操作留了后路。同时，回收资源的具体操作时在Master结点空闲时候完成，对GFS的性能有很好的提高。但是延迟回收会占用很大的存储空间，假如某些可恶的用户无聊了一直创建删除文件怎么办？
  • 总之，HDFS基本可以认为是GFS的简化版，由于时间及应用场景等各方面的原因对GFS的功能做了一定的简化，大大降低了复杂度。

    Blob File System和GFS/HDFS的相似之处

  • GFS与Blob FS的相似之处，比如GFS和TFS目前都采用单一主控机+多台工作机的模式，主控机实现数据的分布、复制、备份决策，工作机存储数据，并根据主控机命令进行数据存储，迁移等。

    Blob File System和GFS/HDFS的区别

  • GFS和HDFS比较通用，可以在GFS和HDFS上搭建通用的表格系统，如Bigtable，Hypertable以及HBase，而Blog File System的应用场景一般为图片，相册这类的Blob数据。
  • GFS的数据是一点一点追加写入到系统的，而Blob数据一般是整个Blob块一次性准备好写入到Blob文件系统，如用户上传一个图片。GFS是大文件系统，考虑吞吐量，可以在上面搭建通用KV或者通用表格系统，而Blob文件系统是小文件系统，一般只是用来存放Blob数据。

    Blob File System和GFS/HDFS二者分别面临的问题

  • 由于业务场景不同，二者面临的问题不同，在Blob FS中，由于整个Blob块数据一次准备就绪，Blob FS的数据写入模型天生就是比较简单，每次写入都请求Master分配Blob块编号及写入的机器列表，然后一次性写入到多台机器中。然而，Blob FS面临的挑战是元数据过于庞大的问题。由于Blob FS存储的Blob块个数一般很大，比如TFS中存储了百亿级的淘宝图片，假设每张图片的元数据占用20字节，所有的元数据占用空间为10G * 20 = 200GB，单机内存存放不下，并且数据量膨胀很快。因此，TFS, QFS以及Facebook
    Haystack都采取了几乎相同的思路，Blob FS不存放元数据，元数据存放到外部的系统中。比如，淘宝TFS中的元数据为图片的id，这些图片id存放在外部数据库，比如商品库中，外部数据库一般是Oracle或者Mysql sharding集群。Blob FS内部也是按照Chunk块组织数据，每个Blob文件是一个逻辑文件，内部的Chunk块是一个物理文件，多个逻辑文件共享同一个物理文件，从而减少单个工作机的物理文件的个数。由于所有物理文件的元数据都可以存放到内存中，每次读取Blob逻辑文件只需要一次磁盘IO，基本可以认为达到了最优。
  • 总之，HDFS和GFS可以认为是类似的，GFS基本覆盖了HDFS的功能，而Blob FS和GFS面临的问题不同，设计的出发点也不一样，两类系统有本质的差别。如果需要将GFS和Blob FS统一成一套系统，这套系统需要同时支持大文件和小文件，且这套系统因为存放的元数据量太大，Master节点本身也需要设计成分布式。这个大一统的系统实现复杂度非常高，目前只有GFS v2有可能可以做到。

    参考文章：GFS, HDFS, Blob File System架构对比
    • 时间： 2025-01-13 13:52:17

    分布式文件系统架构GFS、HDFS、TFS、Haystack的相关文章

    MFS分布式文件系统架构实战

    MFS文件系统的组成架构:如图元数据服务器(Master):负责管理文件系统,维护元数据:元数据日志服务器(c):备份Master服务器的变化日志文件:数据存储服务器( Chunk Server):真正存储数据的服务器:客户端(Client)可像挂载NFS一样挂载MFS文件系统 案例环境:第一步:搭建Master server准备工作:service firewalld stopsetenforce 0yum install -y zlib-develgroupadd mfsuseradd -s

    Hadoop之HDFS分布式文件系统具有哪些优点？

    随着互联网数据规模的不断增大,对文件存储系统提出了更高的要求,需要更大的容量.更好的性能以及更高安全性的文件存储系统,与传统分布式文件系统一样,HDFS分布式文件系统也是通过计算机网络与节点相连,但也有优于传统分布式文件系统的优点. 1. 支持超大文件 HDFS分布式文件系统具有很大的数据集,可以存储TB或PB级别的超大数据文件,能够提供比较高的数据传输带宽与数据访问吞吐量,相应的,HDFS开放了一些POSIX的必须接口,容许流式访问文件系统的数据. 2. 高容错性能 HDFS面向的是成百上千的

    分布式文件系统：原理、问题与方法

    本地文件系统如ext3,reiserfs等(这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源.提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用.但随着互联网企业的高速发展,这些企业对数据存储的要求越来越高,而且模式各异,如淘宝主站的大量商品图片,其特点是文件较小,但数量巨大:而类似于youtube,优酷这样的视频服务网站,其后台存储着大量的视频文件,尺寸大多在数十兆到数吉字节不等.这些应用场景都是传统文件系统不能解决的.分布式文件系统将数据存储在物理上分散的多个存储节点上,

    分布式文件系统：原理、问题与方法(转)

    本地文件系统如ext3,reiserfs等(这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源.提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用.但随着互联网企业的高速发展,这些企业对数据存储的要求越来越高,而且模式各异,如淘宝主站的大量商品图片,其特点是文件较小,但数量巨大:而类似于youtube,优酷这样的视频服务网站,其后台存储着大量的视频文件,尺寸大多在数十兆到数吉字节不等.这些应用场景都是传统文件系统不能解决的.分布式文件系统将数据存储在物理上分散的多个存储节点上,

    Mogilefs分布式文件系统-Keepalived+Nginx双主模型实现图片分布式存储、访问

    一.分布式文件系统: 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连.计算机通过文件系统管理.存储数据,单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式,在容量大小.容量增长速度.数据备份.数据安全等方面的表现都差强人意. 分布式文件系统可以有效解决数据的存储和管理难题:将固定于某个地点的某个文件系统,扩展到任意多个地点/多个文件系统,众多的节点组成一个文件系统网络.每个节点可以分布在

    分布式基础学习（1）--分布式文件系统

    分布式基础学习 所谓分布式,在这里,很狭义的指代以Google的三驾马车,GFS.Map/Reduce.BigTable为 框架核心的分布式存储和计算系统.通常如我一样初学的人,会以Google这几份经典的论文作为开端的.它们勾勒出了分布式存储和计算的一个基本蓝图,已 可窥见其几分风韵,但终究还是由于缺少一些实现的代码和示例,色彩有些斑驳,缺少了点感性.幸好我们还有Open Source,还有Hadoop.Hadoop是 一个基于Java实现的,开源的,分布式存储和计算的项目.作为这个领域最富盛

    【HDFS】Hadoop分布式文件系统：架构和设计

    引言 前提和设计目标 硬件错误 流式数据访问 大规模数据集 简单的一致性模型 "移动计算比移动数据更划算" 异构软硬件平台间的可移植性 Namenode 和 Datanode 文件系统的名字空间 (namespace) 数据复制 副本存放: 最最开始的一步 副本选择 安全模式 文件系统元数据的持久化 通讯协议 健壮性 磁盘数据错误,心跳检测和重新复制 集群均衡 数据完整性 元数据磁盘错误 快照 数据组织 数据块 Staging 流水线复制 可访问性 DFSShell DFSAdmin

    分布式文件系统比较出名的有HDFS? 和 GFS

    分布式文件系统比较出名的有HDFS  和 GFS,其中HDFS比较简单一点.本文是一篇描述非常简洁易懂的漫画形式讲解HDFS的原理.比一般PPT要通俗易懂很多.不难得的学习资料. 1.三个部分: 客户端.nameserver(可理解为主控和文件索引,类似Linux的inode).datanode(存放实际数据) 在这里,client的形式我所了解的有两种,通过Hadoop提供的api所编写的程序可以和hdfs进行交互,另外一种就是安装了hadoop的datanode其也可以通过命令行与hdfs系

    分布式文件系统--GFS

    分布式文件系统      Google File System:是由google开发并设计的一个面向大规模数据处理的一个分布式文件系统. 我们首先来简单的说明一下这个分布式,我们都知道现在要存储的数据量越来越大,但是一台电脑的存储能力是有限的,尽管我们可以通过提高某台电脑的存储能力来解决这个问题,但是这是无法根本解决这个问题,所以我们通过很多很多台廉价的电脑来分布式存储这些数据.简单说就是把要存的文件分割成一份一份存到许多台电脑上. 为了满足Google迅速增长的数据处理需求,Google设计并