7种分布式文件系统介绍

blk_.meta保存的是数据块的属性信息：版本信息，类型信息，和checksum 

当一个目录中的数据块到达一定数量的时候，则创建子文件夹来保存数据块及数据块属性

文件读写

1.读取文件

1.1 读取文件示意图

1.2 文件读取的过程

使用HDFS提供的客户端开发库，向远程的Namenode发起RPC（Remote Procedure    Call）请求； 

Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的datanode地址； 

客户端开发库会选取离客户端最接近的datanode来读取block； 

读取完当前block的数据后，关闭与当前的datanode连接，并为读取下一个block寻找最佳的datanode； 

当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。 

读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读。 

2.写入文件

2.1 写入文件示意图

2.2 写入文件的过程

1）使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求； 

2）Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常； 

3）当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表，列表的大小根据在Namenode中对replication的设置而定。 

4）开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个datanode，该datanode把该packet存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个datanode，这种写数据的方式呈流水线的形式。 

5）最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。 

如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas设定的数量。 

HDFS不能提供的特点

1.低延时访问

　　HDFS不太适合于那些要求低延时（数十毫秒）访问的应用程序，因为HDFS是设计用于大吞吐量数据的，这是以一定延时为代价的。HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有延时。当前，对于那些有低延时要求的应用程序，HBase是一个更好的选择。现在HBase的版本是0.20，相对于以前的版本，在性能上有了很大的提升，它的口号就是goes real time。

　　使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。

2.大量小文件

因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Map task，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Map tasks，会有很大的线程开销；若每个split为100M，则只有100个Map tasks，每个Map task将会有更多的事情做，而线程的管理开销也将减小很多。

　　要想让HDFS能处理好小文件，有不少方法：

　　1、利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。

　　2、横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。

　　3、多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。

附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。

3.多用户写，任意文件修改

　　目前Hadoop只支持单用户写，不支持并发多用户写。可以使用Append操作在文件的末尾添加数据，但不支持在文件的任意位置进行修改。这些特性可能会在将来的版本中加入，但是这些特性的加入将会降低Hadoop的效率。利用Chubby、ZooKeeper之类的分布式协调服务来解决一致性问题。

TFS

TFS简介

Taobao File System（TFS）作为淘宝内部使用的分布式文件系

统，是一个高可扩展、高可用、高性能、面向互联网服务的分布式文

件系统，其设计目标是“支持海量的非结构化数据”。针对海量小文

件的随机读写访问性能做了特殊优化，承载着淘宝主站所有图片、商

品描述等数据存储。

TFS系统的基本情况

1.完全扁平化的数据组织结构，抛弃了传统文件系统的目录结构。

2.在块设备基础上建立自有的文件系统，减少EXT3等文件系统数据碎片带来的性能损耗。

3.单进程管理单块磁盘的方式，摒除RAID5机制。

4.带有HA机制的控制节点，在安全稳定和性能复杂度之间取得平衡。

5.尽量缩减元数据大小，将元数据全部加载入内存，提升访问速度。

6.跨机架和IDC的负载均衡和冗余安全策略。

7.完全平滑扩容。

应用规模

达到“数百台PCServer，PB级数据量，百亿数据级别”

性能参数

TFS在淘宝的部署环境中前端有两层缓冲，到达TFS系统的请求非常离散，所以TFS内部是没有任何数据的内存缓冲的，包括传统文件系统的内存缓冲也不存在......基本上可以达到单块磁盘随机IOPS（即I/O per second）理论最大值的60%左右，整机的输出随盘数增加而线性增加。

TFS的逻辑架构图

下载 (129.26 KB)

2010-9-29 22:39

结合架构图做了进一步说明

1.TFS尚未对最终用户提供传统文件系统API，需要通过TFSClient进行接口访问，现有JAVA、JNI、C、PHP的客户端

2.TFS的NameServer作为中心控制节点，监控所有数据节点的运 

行状况，负责读写调度的负载均衡，同时管理一级元数据用来帮助客户端定位需要访问的数据节点

3.TFS的DataServer作为数据节点，负责数据实际发生的负载均衡和数据冗余，同时管理二级元数据帮助客户端获取真实的业务数据。

TFS的不足之处

TFS与目前一些主流的开源分布式文件系统设计思想是相似的，如HDFS, MFS, KFS, Sector。其高可扩展、高可用性是很好的，然而也存在一定不足，如通用性、用户接口、性能等方面。

1、通用性方面。

TFS目前只支持小文件的应用，大文件应用是不支持的。对小图片、网页等几十KB内的数据存储非常适用，但对视频点播VOD、文件下载等应用暂时无法适用。

2、性能方面。

Client写文件是同步处理的，需要等所有dataserver写成功后才能返回，这很是影响性能。

3、用户接口。

TFS没有提供POSIX接口，提供的API也与标准接口不一致。另外，TFS有自己的文件命名规则，如果用户使用自定义的文件名，则需要自已维护文件名与TFS文件名之间的映射关系。

4、代码方面。

使用了C++实现，感觉相对臃肿一点，如果用纯C实现应该会简洁不少。代码注释基本没有，代码质量也不是很好。

5、技术文档。

官方有一些文档，但显然非常不够深入和全面。

6、小文件优化。

官方称针对海量小文件的随机读写访问性能做了特殊优化，现在只看到把众多小文件存放与一个Block中，这与Squid中的COSS原理相似。其他特殊优化措施未知，LOFS(Lost of small files)是个难点问题。

MooseFS（简称MFS）

MFS简介

MFS是一款网络分布式 文件系统。它把数据分散在多台服务器上，

但对于用户来讲，看到的只是一个源。MFS也像其他类unix文件系

统一样，包含了层级结构（目录树），存储着文 件属性（权限，最

后访问和修改时间），可以创建特殊的文件（块设备，字符设备，管

道，套接字），符号链接，硬链接。 

MFS的优点

1.免费开源

2.通用文件系统，不需要修改上层应用就可以使用 

3.可以在线扩容，体系架构可伸缩性极强 

4.部署简单

5.体系架构高可用，所有组件无单点故障

6.文件对象高可用，可任意设置文件的冗余程度，而绝对不会影响读或写

   的性能，只会加速。

7.提供windows回收站的功能

8.提供类似java 语言的垃圾回收（GC）

9.提供netapp,emc,ibm等商业存储的snapshot特性。

10.GFS的一个c实现

11.提供web gui监控接口

12.提高随机读或写的效率

13.提高海量小文件的读写效率

网络示意图(如下)

MFS文件系统结构

包含的4种角色 

◆管理服务器managing server (master) 

负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝

◆元数据日志服务器Metalogger serve（Metalogger）

负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs，以便于在master server出问题的时候接替其进行工作。元数据存储在Master的内存中，同时会保存一份在硬盘上（作为临时更新的二进制文件和立即更新的增量日志方式）

◆数据存储服务器data servers (chunkservers) 

负责连接管理服务器,听从管理服务器调度,提供存储空间，并为客户提供数据传输. 数据文件被分成Mb大小的块，每个块被分散的存储在块服务器的硬盘上，同时块服务器上还会存储其他块服务器上块文件的副本。

◆客户端client computers  

通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器,.看起来共享的文件系统和本地unix文件系统使用一样的效果. 客户端只需要mount上MFS就可像操作其他文件系统的文件一样操作MFS中的文件了。操作系统的内核把对文件的操作传递给FUSE模块，这个模块用来和mfsmount进程进行通信。mfsmount进程后续通过网络和管理服务器和数据块服务器进行通信。整个过程对用户来讲是透明的。

4种角色的协作过程

在对所有元数据文件（文件创建，文件删除，读文件夹，读取和更改属性，改变文件大小等等涉及到在MFSMETA上的特殊文件）进行操作的过程中，mfsmount和管理服务器建立通信，然后开始读取和写入数据。数据发送到所有数据服务器中有相关文件块的一台上。在完成写操作之后，管理服务器收到文件长度和最后修改时间的更新信息。而且，数据服务器之间进行复制通信，保证每个块在不同的块服务器上都有拷贝。因为文件块存在多个拷贝，所以，任何一台数据服务器不可用都是不会影响到文件的正常访问的。整体来看moosfs，他的设计理念还是很符合gfs的，从架构图来看，整个系统实现起来还是很容易的。不过有一点值得注意的还是，对于master主机来说，这个是一个单点，会存在隐患，在正式环境应用的时候，如何解决这里，是个关键。

MFS读写进程

MFS读进程

MFS写进程

PS: MFS提供文件系统级回收站的配置，这个回收站在整个文件系统工作。那样如果用户删除一个文件，这个文件可以一直存在回收站中，只要管理员想留着它。回收站中的文件会在一段配置时间之后自动清理。

KFS

KFS简介

KFS（KOSMOS DISTRIBUTED FILE SYSTEM），一个类似GFS、Hadoop中HDFS 的一个开源的分布式文件系统。可以应用在诸如图片存储、搜索引擎、网格计算、数据挖掘这样需要处理大数据量的网络应用中。与hadoop集成得也比较好，这样可以充分利用了hadoop一些现成的功能，基于C++。

KFS的特性

1.自动存储扩充

添加新的chunckserver,系统自动感知 

2.有效性

复制机制保证文件有效性，一般文件会被以三种方式存储，当其中一个chunkserver出现错误的时候，不会影响数据的读取； 

3.文件复制粒度

可以配置文件复制的粒度，最大可以被复制份 

4.还原复制

  当其中一个Chunckserver出现故障的时候，Metaserver会强制使用其他的chunckserver 

5.负载平衡

系统周期地检查chunkservers的磁盘利用，并重新平衡chunkservers的磁盘利用，HDFS现在还没有支持 

6.数据完整性

当要读取数据时检查数据的完整性，如果检验出错使用另外的备份覆盖当前的数据 

7.文件写入

当一个应用程序创建了一个文件，这个文件名会被立刻写入文件系统，但为了性能，写入的数据会被缓存在kfs客户端.并且周期性的从缓存中把数据更 新到chunkserver中。当然，应用程序也可以强制把数据更新到服务器上。一旦数据被更新到服务器，就可以被有效的读取了。（我怎么能知道这个文件什么时候可以读取了呢？） 

8.契约

使用契约来保证Client缓存的数据和文件系统中的文件保持一致性 

9.支持FUSE

在linux系统下，可以通过Fuse 映射一个文件夹，从而可以很方便的读取kfs的文件 

10.支持C++,Java,Python方式的调用 

11.提供了丰富的工具程序

如kfsshell,cp2kfs等 

12.提供了启动和停止服务的脚本 

KFS高级特性

1.支持同一文件多次写入和Append，不过不能在文件中间插入数据。 （HDFS支持一次写入多次读取，不支持Append） 

2.文件及时生效，当应用程序创建一个文件时,文件名在系统马上有效。（HDFS文件只当输入流关闭时才在系统中有效，因此，如果应用程序在关闭前出现异常导致没有关闭输入流，数据将会丢失。)

这一点好像也不是很好，如果输入流中断，在kfs里会留下一个错误的文件，当读取时会出现错误，好像也没有太大的意义。 

KFS与HDFS的比较

1.体系结构图的比较

2.特点的比较

两者都是GFS的开源实现，而HDFS 是Hadoop 的子项目，用Java实现，为Hadoop上层应用提供高吞吐量的可扩展的大文件存储服务。KFS 是一个高性能的分布式文件系统，主要针对网络规模的应用，例如存储日志数据，Map/Reduce 数据等. 用C++实现。它们的元数据管理采用集中式方式实现，数据实体先分片然后分布式存储。

Ceph

Ceph 的目标

　　1. 可轻松扩展到数 PB 容量

　　2. 对多种工作负载的高性能（每秒输入/输出操作[IOPS]和带宽）

3.高可靠性

不幸的是，这些目标之间会互相竞争（例如，可扩展性会降低或者抑制性能或者影响可靠性）。Ceph 开发了一些非常有趣的概念（例如，动态元数据分区，数据分布和复制），这些概念在本文中只进行简短地探讨。Ceph 的设计还包括保护单一点故障的容错功能，它假设大规模（PB 级存储）存储故障是常见现象而不是例外情况。最后，它的设计并没有假设某种特殊工作负载，但是包括适应变化的工作负载，提供最佳性能的能力。它利用 POSIX 的兼容性完成所有这些任务，允许它对当前依赖 POSIX 语义（通过以 Ceph 为目标的改进）的应用进行透明的部署。最后，Ceph 是开源分布式存储，也是主线 Linux 内核（2.6.34）的一部分。

Ceph 生态系统

可以大致划分为四部分

1. 客户端（数据用户），

2. 元数据服务器（缓存和同步分布式元数据），

3.一个对象存储集群（将数据和元数据作为对象存储，执行其他关键职能）

4. 集群监视器（执行监视功能）。

 Ceph 生态系统的概念架构

架构视图1

如上图1所示，客户使用元数据服务器，执行元数据操作（来确定数据位置）。元数据服务器管理数据位置，以及在何处存储新数据。值得注意的是，元数据存储在一个存储集群（标为 “元数据 I/O”）。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来，更高层次的 POSIX 功能（例如，打开、关闭、重命名）就由元数据服务器管理，不过 POSIX 功能（例如读和写）则直接由对象存储集群管理。

架构视图 2

一系列服务器通过一个客户界面访问 Ceph 生态系统，这就明白了元数据服务器和对象级存储器之间的关系。分布式存储系统可以在一些层中查看，包括一个存储设备的格式（Extent and B-tree-based Object File System [EBOFS] 或者一个备选），还有一个设计用于管理数据复制，故障检测，恢复，以及随后的数据迁移的覆盖管理层，叫做 Reliable Autonomic Distributed Object Storage（RADOS）。最后，监视器用于识别组件故障，包括随后的通知。

Ceph 组件

Ceph 和传统的文件系统之间的重要差异之一就是，它将智能都用在了生态环境而不是文件系统本身。

　　图 3 显示了一个简单的 Ceph 生态系统。Ceph Client 是 Ceph 文件系统的用户。Ceph Metadata Daemon 提供了元数据服务器，而 Ceph Object Storage Daemon 提供了实际存储（对数据和元数据两者）。最后，Ceph Monitor 提供了集群管理。要注意的是，Ceph 客户，对象存储端点，元数据服务器（根据文件系统的容量）可以有许多，而且至少有一对冗余的监视器。

Ceph 客户端

　　内核或用户空间 

　　早期版本的 Ceph 利用在 User SpacE（FUSE）的 Filesystems，它把文件系统推入到用户空间，还可以很大程度上简化其开发。但是今天，Ceph 已经被集成到主线内核，使其更快速，因为用户空间上下文交换机对文件系统 I/O 已经不再需要。

　　因为 Linux 显示文件系统的一个公共界面（通过虚拟文件系统交换机 [VFS]），Ceph 的用户透视图就是透明的。管理员的透视图肯定是不同的，考虑到很多服务器会包含存储系统这一潜在因素。从用户的角度看，他们访问大容量的存储系统，却不知道下面聚合成一个大容量的存储池的元数据服务器，监视器，还有的对象存储设备。用户只是简单地看到一个安装点，在这点上可以执行标准文件 I/O

Ceph 文件系统 — 或者至少是客户端接口 — 在 Linux 内核中实现。值得注意的是，在大多数文件系统中，所有的控制和智能在内核的文件系统源本身中执行。但是，在 Ceph 中，文件系统的智能分布在节点上，这简化了客户端接口，并为 Ceph 提供了大规模（甚至动态）扩展能力。

　　Ceph 使用一个有趣的备选，而不是依赖分配列表（将磁盘上的块映射到指定文件的元数据）。Linux 透视图中的一个文件会分配到一个来自元数据服务器的 inode number（INO），对于文件这是一个唯一的标识符。然后文件被推入一些对象中（根据文件的大小）。使用 INO 和 object number（ONO），每个对象都分配到一个对象 ID（OID）。在 OID 上使用一个简单的哈希，每个对象都被分配到一个放置组。放置组（标识为 PGID）是一个对象的概念容器。最后，放置组到对象存储设备的映射是一个伪随机映射，使用一个叫做 Controlled Replication Under Scalable Hashing（CRUSH）的算法。这样一来，放置组（以及副本）到存储设备的映射就不用依赖任何元数据，而是依赖一个伪随机的映射函数。这种操作是理想的，因为它把存储的开销最小化，简化了分配和数据查询。

　　分配的最后组件是集群映射。集群映射 是设备的有效表示，显示了存储集群。有了 PGID 和集群映射，您就可以定位任何对象。

Ceph 元数据服务器

　　元数据服务器（cmds）的工作就是管理文件系统的名称空间。虽然元数据和数据两者都存储在对象存储集群，但两者分别管理，支持可扩展性。事实上，元数据在一个元数据服务器集群上被进一步拆分，元数据服务器能够自适应地复制和分配名称空间，避免出现热点。如图 4 所示，元数据服务器管理名称空间部分，可以（为冗余和性能）进行重叠。元数据服务器到名称空间的映射在 Ceph 中使用动态子树逻辑分区执行，它允许 Ceph 对变化的工作负载进行调整（在元数据服务器之间迁移名称空间）同时保留性能的位置。

但是因为每个元数据服务器只是简单地管理客户端人口的名称空间，它的主要应用就是一个智能元数据缓存（因为实际的元数据最终存储在对象存储集群中）。进行写操作的元数据被缓存在一个短期的日志中，它最终还是被推入物理存储器中。这个动作允许元数据服务器将最近的元数据回馈给客户（这在元数据操作中很常见）。这个日志对故障恢复也很有用：如果元数据服务器发生故障，它的日志就会被重放，保证元数据安全存储在磁盘上。

元数据服务器管理 inode 空间，将文件名转变为元数据。元数据服务器将文件名转变为索引节点，文件大小，和 Ceph 客户端用于文件 I/O 的分段数据（布局）。

Ceph 监视器

　　Ceph 包含实施集群映射管理的监视器，但是故障管理的一些要素是在对象存储本身中执行的。当对象存储设备发生故障或者新设备添加时，监视器就检测和维护一个有效的集群映射。这个功能按一种分布的方式执行，这种方式中映射升级可以和当前的流量通信。Ceph 使用 Paxos，它是一系列分布式共识算法。

Ceph 对象存储

　　和传统的对象存储类似，Ceph 存储节点不仅包括存储，还包括智能。传统的驱动是只响应来自启动者的命令的简单目标。但是对象存储设备是智能设备，它能作为目标和启动者，支持与其他对象存储设备的通信和合作。

　　从存储角度来看，Ceph 对象存储设备执行从对象到块的映射（在客户端的文件系统层中常常执行的任务）。这个动作允许本地实体以最佳方式决定怎样存储一个对象。Ceph 的早期版本在一个名为 EBOFS 的本地存储器上实现一个自定义低级文件系统。这个系统实现一个到底层存储的非标准接口，这个底层存储已针对对象语义和其他特性（例如对磁盘提交的异步通知）调优。今天，B-tree 文件系统（BTRFS）可以被用于存储节点，它已经实现了部分必要功能（例如嵌入式完整性）。

　　因为 Ceph 客户实现 CRUSH，而且对磁盘上的文件映射块一无所知，下面的存储设备就能安全地管理对象到块的映射。这允许存储节点复制数据（当发现一个设备出现故障时）。分配故障恢复也允许存储系统扩展，因为故障检测和恢复跨生态系统分配。Ceph 称其为 RADOS（见 图 3）。

其他有趣功能

　　如果文件系统的动态和自适应特性不够，Ceph 还执行一些用户可视的有趣功能。用户可以创建快照，例如，在 Ceph 的任何子目录上（包括所有内容）。文件和容量计算可以在子目录级别上执行，它报告一个给定子目录（以及其包含的内容）的存储大小和文件数量。

Ceph 的地位和未来

　　虽然 Ceph 现在被集成在主线 Linux 内核中，但只是标识为实验性的。在这种状态下的文件系统对测试是有用的，但是对生产环境没有做好准备。但是考虑到 Ceph 加入到 Linux 内核的行列，还有其创建人想继续研发的动机，不久之后它应该就能用于解决您的海量存储需要了。

其他分布式文件系统

　　Ceph 在分布式文件系统空间中并不是唯一的，但它在管理大容量存储生态环境的方法上是独一无二的。分布式文件系统的其他例子包括 Google File System（GFS），General Parallel File System（GPFS），还有 Lustre，这只提到了一部分。Ceph 背后的想法为分布式文件系统提供了一个有趣的未来，因为海量级别存储导致了海量存储问题的唯一挑战。

展望未来

Ceph 不只是一个文件系统，还是一个有企业级功能的对象存储生态环境。

补充：Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统，使数据能容错和无缝的复制。