分布式文件存储系统调研

分布式文件存放系统调研北京无线天利移动信息技术股份有限企业5月北京

文档变更统计：版本序号更新时间版本号变更类型更新内容变更人1-5-201.0.0创建

1. 需求分析 41.1. 大数据时代 41.2. 调研范围 41.3. 名词解释 52. 谷歌GFS 62.1. 系统架构 72.2. 相关技术 82.2.1. 租赁机制 82.2.2. 一致性模型 82.2.3. 追加流程 92.2.4. 容错机制 102.2.5. Master内存占用 112.2.6. 负载均衡 112.2.7. 垃圾回收 122.2.8. 快照 122.2.9. ChunkServer 122.3. GFS学习总结 133. 开源分布式文件存放系统 133.1. 序言 133.2. HadoopHDFS 143.2.1. 介绍 143.2.2. 特点 143.2.3. 性能 143.3. KFS 143.4. 流行开源文件存放系统比较 153.5. 开源分布式文件存放学习总结 184. 参考资料 18

需求分析大数据时代我们早已处于数字时代。而今，我们迎来了数据爆炸时代，这就是所谓大数据时代。，大数据元年。大数据四个特征：数据量大第一个特征是数据量大。大数据起始计量单位最少是P（1000个T）、E（100万个T）或Z（10亿个T）。类型繁多第二个特征是数据类型繁多。包含网络日志、音频、视频、图片、地理位置信息等等，多类型数据对数据处理能力提出了更高要求。价值密度低第三个特征是数据价值密度相对较低。如伴随物联网广泛应用，信息感知无处不在，信息海量，但价值密度较低，怎样经过强大机器算法更加快速地完成数据价值“提纯”，是大数据时代亟待处理难题。速度快时效高第四个特征是处理速度快，时效性要求高。这是大数据区分于传统数据挖掘最显著特征。现有技术架构和路线，已经无法高效处理如此海量数据，而对于相关组织来说，假如投入巨大采集信息无法经过及时处理反馈有效信息，那将是得不偿失。能够说，大数据时代对人类数据驾驭能力提出了新挑战，也为人们取得更为深刻、全方面洞察能力提供了前所未有空间与潜力。当前，分布式文件存放系统是处理大数据时代利器。调研范围为了应对大数据到来，不一样背景企业有不一样处理方案。传统关系型数据库（OldSQL）、新型列存放-关系型数据库（NewSQL）和基于NoSQL云存放，都针对云存放提出了对应处理方案。这是一个多元化时代，三个处理方案各有优缺点，互为补充愈加适合大数据需要。相比之下，OldSQL已经比较成熟，NewSQL技术比较封闭比较商业化，都不是此次研究对象。此次技术调研，主要包括基于NoSQL分布式文件存放系统。NoSQL领域技术繁多，各种概念层出不穷，虽涉足不深但已经常感觉头晕目眩。为了便于调研，我将NoSQL包括各个组件、产品分为三部分：分布式文件存放系统NoSQL数据库云计算应用分布式文件存放是另外两个部分基础，此篇文章将聚焦于分布式文件存放系统。名词解释大数据：指是所包括资料量规模巨大到无法透过现在主流软件工具，在合理时间内达成撷取、管理、处理、并整理成为帮助企业经营决议更主动目标资讯。简单说，最少要达成TB级别数据。云存放：云存放是与云计算同时兴起一个概念。云存放通常包含两个含义：云存放是云计算存放部分，即虚拟化、易于扩展存放资源池。用户经过云计算使用存放资源池，但不是全部云计算存放部分都是能够分离。云存放意味着存放能够作为一个服务，经过网络提供给用户。用户能够经过若干种方式来使用存放，并按使用（时间、空间或二者结合）付费。NoSQL：NotOnlySQL，泛指这么一类数据库和数据存放，它们不遵照经典关系型数据库原理，且常与Web规模大型数据集关于。NewSQL：新型关系型数据库；不一样于传统关系型数据库，NewSQL阵营普遍采取了列存放技术，是介于传统关系型数据库和NoSQL之间产品。这类产品有可能代表未来发展方向，不过现在尚不普及。DFS：分布式文件系统（DistributedFileSystem），指文件系统管理物理存放资源不一定直接连接在当地节点上，而是经过计算机网络与节点相连。HDFS：Hadoop分布式文件系统（HadoopDistributedFileSystem），是一个高度容错性系统，适合布署在廉价机器上。KFS：Kosmosdistributedfilesystem，是一个专门为数据密集型应用（搜索引擎，数据挖掘等）而设计存放系统，类似于谷歌GFS和HadoopHDFS分布式文件系统。KFS使用C++实现，支持客户端包含C++，Java和Python。KFS系统由三部分组成，分别是metaserver、chunkserver和clientlibrary。流式数据访问：流式读取最小化了硬盘寻址开销，只需要寻址一次，然后就一直读啊读。硬盘物理结构造成寻址开销优化跟不上读取开销。所以流式读取愈加适合硬盘本身特征。当然大文件特点也更适合流式读取。随机数据访问：要求定位、查询或修改数据延迟较小，比较适合于创建数据后再数次读写情况，传统关系型数据库很符合这一点。POSIX：可移植操作系统接口（PortableOperatingSystemInterface），最初开发POSIX标准，是为了提升UNIX环境下应用程序可移植性。然而，POSIX并不局限于UNIX，许多系统都支持。因为分布式文件存放系统很多是用C/C++开发，支持POSIX也就意味着它文件操作在大部分UNIX和Linux操作系统之间是可移植。对于Java开发文件存放系统则不需要关心。FUSE：用户态文件系统（FilesysteminUserspace），是操作系统中概念，指完全在用户态实现文件系统。现在Linux经过内核模块对此进行支持。传统上操作系统在内核层面上对文件系统提供支持。而通常内核态代码难以调试，生产率较低。在用户空间实现文件系统能够大幅提升生产率，简化了为操作系统提供新文件系统工作量，尤其适适用于各种虚拟文件系统和网络文件系统。上述ZFS和glusterfs都属于网络文件系统。不过，在用户态实现文件系统必定会引入额外内核态/用户态切换带来开销，对性能会产生一定影响。（针对C/C++，Java系统则不需要关心）谷歌GFS提起分布式文件存放系统，最有名莫过于谷歌技术“三宝”之一：谷歌文件系统GFS。谷歌文件系统（谷歌FileSystem，GFS）是构建在廉价服务器之上大型分布式系统。它将服务器故障视为正常现象，经过软件方式自动容错，在确保系统可靠性和可用性同时，大大降低了系统成本。GFS是谷歌云存放基石，其它存放系统，如谷歌Bigtable，谷歌Megastore，谷歌Percolator均直接或者间接地构建在GFS之上。另外，谷歌大规模批处理系统MapReduce也需要利用GFS作为海量数据输入输出。系统架构GFS将整个系统节点分为三种角色：GFSMaster（总控服务器），GFSChunkserver（数据块服务器，简称CS）以及GFSClient（客户端）。GFS文件被划分为固定大小数据块（Chunk），由Master在创建时分配一个64位全局唯一Chunk句柄。CS以普通Linux文件形式将Chunk存放在磁盘中。为了确保可靠性，Chunk在不一样机器中复制多份，默认为三份。Master中维护了系统元数据，包含文件及Chunk名字空间，GFS文件到Chunk之间映射，Chunk位置信息。它也负责整个系统全局控制，如Chunk租约管理，垃圾回收无用Chunk，Chunk复制，等等。Master会定时与CS经过心跳方式交换信息。Client是GFS提供给应用程序访问接口，它是一组专用接口，不恪守POSIX规范，以库文件形式提供。Client访问GFS时，首先访问Master节点，获取与之进行交互CS信息，然后直接访问这些CS，完成数据存取工作。需要注意是，GFS中客户端不缓存文件数据，只缓存Master中获取元数据，这是由GFS应用特点决定。GFS最主要应用有两个：MapReduce与Bigtable。对于MapReduce，GFS客户端使用方式为次序读写，没有缓存文件数据必要；而Bigtable作为云表格系统，内部实现了一套缓存机制。另外，怎样维护客户端缓存与实际数据之间一致性是一个极其复杂问题。下面讨论GFS架构中几个关键技术。相关技术租赁机制GFS数据追加以统计为单位，每个统计大小为几十KB到几MB，假如每次统计追加都需要请求Master，那么Master显然会成为系统性能瓶颈，所以，GFS系统中经过Lease机制将chunk写操作授权给ChunkServer。获取Lease授权ChunkServer称为PrimaryChunkServer，其它副本所在ChunkServer称为SecondaryChunkServer。Lease授权针对单个chunk，在Lease使用期内，对该chunk写操作都有PrimaryChunkServer负责，从而降低Master负担。通常来说，Lease使用期比较长，比如60秒，只要没有出现异常，PrimaryChunkServer能够不停向Master请求延长Lease使用期直到整个chunk写满。假设有ChunkA在GFS中保留了三个副本A1，A2，A3，其中，A1是Primary。假如副本A2所在ChunkServer下线后又重新上线，而且在A2下线过程中，副本A1和A3有新更新，那么，A2需要被Master当成垃圾回收掉。GFS经过对每个chunk维护一个版本号来处理，每次给Chunk进行Lease授权或者PrimaryChunkServer重新延长Lease使用期时，Master会将Chunk版本号加1。A2下线过程中，副本A1和A3有新更新，说明PrimaryChunkServer向Master重新申请Lease并增加了A1和A3版本号，等到A2重新上线后，Master能够发觉A2版本号太低，从而将A2标识为可删除chunk，Master垃圾回收任务会定时检验，并通知ChunkServer将A2回收掉。总结：GFS经过租赁机制来缓解Master性能瓶颈。一致性模型GFS主要是为了追加（Append）而不是改写（Overwrite）而设计。首先是因为是改写需求比较少，或者能够经过追加来实现，比如能够只使用GFS追加功效构建分布式表格系统Bigtable；另首先是因为追加一致性模型相比改写要愈加简单有效。考虑ChunkA三个副本A1，A2，A3，有一个改写操作修改了A1，A2但没有修改A3，这么，落到副本A3读操作可能读到不正确数据；对应地，假如有一个追加操作往A1，A2上追加了一个统计不过追加A3失败，那么即使读操作落到副本A3也只是读到过期而不是不正确数据。我们只讨论追加一致性。假如不发生异常，追加成功统计在GFS各个副本中是确定而且严格一致；不过假如出现了异常，可能出现一些副本追加成功而一些副本没有成功情况，失败副本可能会出现一些可识别填充(padding)统计。GFS客户端追加失败将重试，只要返回用户追加成功，说明在全部副本中都最少追加成功了一次。当然，可能出现统计在一些chunk副本中被追加了数次，即重复统计；也可能出现一些可识别填充统计，应用层需要能够处理这些问题。另外，因为GFS支持多个客户端并发追加，那么多个客户端之间次序是无法确保，同一个客户端连续追加成功多个统计也可能被打断，比如客户端先后追加成功统计R1和R2，因为追加R1和R2这两条统计过程不是原子，中途可能被其它客户端打断，那么GFSchunk中统计R1和R2可能不连续，中间夹杂着其它客户端追加数据。GFS这种一致性模型是追求性能造成，这也增加了应用程序开发难度。对于MapReduce应用，因为其批处理特征，能够先将数据追加到一个暂时文件，在暂时文件中维护索引统计每个追加成功统计偏移，等到文件关闭时一次性将暂时文件更名为最终文件。总结：GFS提倡一次写入数次读取，对改写一致性处理性能不高。对于追加，它采取是一个宽松一致性模型，追加过程可能会造成少许重复统计，也可能出现一些可识别填充统计。追加流程追加流程是GFS系统中最为复杂地方，而且，高效支持统计追加对于基于GFS实现Bigtable是至关主要。追加流程大致以下：客户端向Master请求chunk每个副本所在ChunkServer，其中PrimaryChunkServer持有修改Lease。假如没有ChunkServer持有Lease，说明该chunk最近没有写操作，Master会发起一个任务，按照一定策略将chunkLease授权给其中一台chunkServer。Master返回客户端Primary和其它ChunkServer位置信息，客户端将缓存这些信息供以后使用。假如不出现故障，客户端以后读写该chunk都不需要再次请求Master。客户端将要追加统计发送到每一个副本。每一个ChunkServer会在内部LRU结构中缓存这些数据。GFS中采取数据流和控制流分离方法，从而能够基于网络拓扑结构愈加好地调度数据流传输。当全部副本都确认收到了数据，客户端发起一个写请求控制命令给Primary。因为Primary可能收到多个客户端对同一个chunk并发追加操作，Primary将确定这些操作次序并写入当地；Primary把写请求提交给全部Secondary副本。每一个Secondary会依照Primary确定次序执行写操作；Secondary副本成功完成后应答Primary；Primary应答客户端，假如有副本发生错误，将出现Primary写成功不过一些Secondary不成功情况，客户端将重试。GFS追加流程有两个特色：流水线及分离数据流与控制流。流水线操作用来降低延时。当一个ChunkServer接收到一些数据，它就立刻开始转发。因为采取全双工网络，立刻发送数据并不会降低接收数据速率。抛开网络阻塞，传输B个字节到R个副本理想时间是B/T+RL，其中T是网络吞吐量，L是亮点之间延时。假设采取千兆网络，L通常小于1ms，传输1MB数据到多个副本时间小于80ms。分离数据流与控制流主要是为了优化数据传输，每一个机器都是把数据发送给网络拓扑图上”最近”还未收到数据数据。举个例子，假设有三台ChunkServerS1，S2和S3，S1与S3在同一个机架上，S2在另外一个机架，客户端布署在机器S1上。假如数据先从S1转发到S2，再从S2转发到S3，需要经历两次跨机架数据传输；相对地，按照GFS中策略，数据先发送到S1，接着从S1转发到S3，最终转发到S2，只需要一次跨机架数据传输。总结：GFS追加流程非常精巧：控制与数据分离，利用流水线（pipeline）方式进行数据传输，传输拓扑结构精心设计。这一系列方法都是尽最大可能降低系统瓶颈，加紧网络传输速度，以提升整体性能。容错机制Master容错与传统方法类似，经过操作日志加checkpoint方式进行，而且有一台称为”ShadowMaster”实时热备。Master上保留了三种元数据信息：(1)命名空间（NameSpace），也就是整个文件系统目录结构以及chunk基本信息；(2)文件到chunk之间映射；(3)Chunk副本位置信息，每个Chunk通常有三个副本；GFSMaster修改操作总是先统计操作日志，然后再修改内存，当Master发生故障重启时，能够经过磁盘中操作日志恢复内存数据结构；另外，为了降低Master宕机恢复时间，Master会定时将内存中数据以checkpoint文件形式转储到磁盘中，从而降低回放日志量。为了深入提升Master可靠性和可用性，GFS中还会执行实时热备，全部元数据修改操作都必须确保发送到实时热备才算成功。远程实时热备将实时接收Master发送操作日志并在内存中回放这些元数据操作。假如Master宕机，还能够秒级切换到实时备机继续提供服务。为了确保同一时刻只有一个Master，GFS依赖谷歌内部Chubby服务进行选主操作。Master需要持久化前两种元数据，即命令空间及文件到chunk之间映射关系；对于第三种元数据，即Chunk副本位置信息，Master能够选择不进行持久化，这是因为ChunkServer维护了这些信息，即使Master发生故障，也能够在重启时经过ChunkServer汇报来获取。GFS采取复制多个副本方式实现ChunkServer容错，每一个Chunk有多个存放副本，分别存放在不一样ChunkServer上。对于每一个Chunk，必须将全部副本全部写入成功，才视为成功写入。假如相关副本出现丢失或不可恢复情况，Master自动将给副本复制到其它ChunkServer，从而确保副本保持一定个数。另外，ChunkServer会对存放数据维持校验和。GFS以64MB为Chunk大小来划分文件，每一个Chunk又以Block为单位进行划分，大小为64KB，每一个Block对应一个32位校验和。当读取一个Chunk副本时，ChunkServer会将读取数据和校验和进行比较，假如不匹配，就会返回错误，客户端将选择其它ChunkServer上副本。总结：MasterServer和ChunkServer都提供了对应容错机制，能实现完全自动容错处理和切换，响应切换速度为秒级。Master内存占用Master维护了系统中元数据，包含文件及chunk名字空间，文件到chunk映射，chunk副本位置信息。其中前两种元数据需要持久化到磁盘，chunk副本位置信息不需要持久化，能够经过ChunkServer汇报获取。内存是Master稀有资源，下面估算Master内存使用量。Chunk元信息包含全局唯一ID，版本号，每个副本所在ChunkServer编号，引用计数等。GFS系统中每个chunk大小为64MB，默认存放3份，每个chunk元数据小于64字节。那么1PB数据chunk元信息大小不超出1PB*3/64MB*64=3GB。另外，Master对命名空间进行了压缩存放，比如有两个文件foo1和foo2都存放在目录/home/very_long_directory_name/中，那么目录名在内存中只需要存放一次。压缩存放后，每个文件在文件名字空间元数据也不超出64字节，因为GFS中文件通常都是大文件，所以，文件名字空间占用内存不多。这也就说明了Master内存容量不会成为GFS系统瓶颈。总结：为了提升性能，MasterServer需要将部分元数据缓存到内存，所以需要较大内存。ChunkServer则不需要进行数据缓存。负载均衡GFS中副本分布策略需要考虑多个原因，如网络拓扑，机架分布，磁盘利用率等等。为了提升系统可用性，GFS会防止同一个chunk全部副本都存放在同一个机架情况。系统中有三种需要创建chunk副本情况：chunk创建，chunk重新复制（re-replication）以及重新平衡（rebalancing）。当Master创建了一个chunk，它会依照以下原因来选择chunk副本初始位置：(1)新副本所在ChunkServer磁盘利用率低于平均水平；(2)限制每个ChunkServer”最近”创建数量。（3）每个chunk全部副本不能在同一个机架。第二点轻易忽略但却很主要，因为创建完chunk以后通常需要马上写入数据，假如不限制”最近”创建数量，当一台空ChunkServer上线时，因为磁盘利用率低，可能造成大量chunk瞬间迁移到这台机器从而将它压垮。当Chunk副本数量小于一定数量后，Master会尝试重新复制一个chunk副本。可能原因包含ChunkServer宕机或者ChunkServer汇报自己副本损坏，或者它某个磁盘故障，或者用户动态增加了Chunk副本数，等等。每一个chunk复制任务都有一个优先级，按照优先级从高到低在Master排队等候执行。比如，只有一个副本chunk需要优先复制，又如，有效文件chunk复制优先级比最近删除文件chunk高，最终，GFS会提升全部阻塞客户端操作chunk复制任务优先级，比如客户端正在往一个只有一个副本chunk追加数据，假如限制最少需要追加成功两个副本，那么这个chunk复制任务会阻塞客户端写操作，需要提升优先级。最终，Master会定时扫描当前副本分布情况，假如发觉磁盘使用量或者机器负载不均衡，将执行重新平衡操作。不论是chunk创建，chunk重新复制，还是重新平衡，它们选择chunk副本位置策略都是相同，而且需要限制重新复制和重新平衡任务拷贝速度，不然可能影响系统正常读写服务。总结：GFS负载均衡策略十分完备，已被众多开源实现所模仿。垃圾回收GFS采取延迟删除机制，也就是说，当文件被删除后，GFS并不要求立刻偿还可用物理存放，而是在元数据中将文件更名为一个隐藏名字，而且包含一个删除时间戳。Master定时检验，假如发觉文件删除超出一段时间（默认为3天，可配置），那么它会把文件从内存元数据中删除，以后ChunkServer和Master心跳消息中，每一个ChunkServer都将汇报自己chunk集合，Master会回复在Master元数据中已经不存在chunk信息，这时，ChunkServer会释放这些Chunk副本。为了减轻系统负载，垃圾回收通常在服务低峰期执行，比如天天晚上凌晨1:00开始。另外，Chunk副本可能会因为ChunkServer失效期间丢失了对Chunk修改操作而造成过期。系统对每个Chunk都维护了版本号，过期Chunk能够经过版本号检测出来。Master依然经过正常垃圾回收机制来删除过期副本。总结：GFS垃圾回收机制被众多开源实现所模仿。快照快照（Snapshot）操作是对源文件/目录进行一个”快照”操作，生成该时刻源文件/目录一个瞬间状态存放与目标文件/目录中。GFS中使用标准copy-on-write机制生成快照，也就是说，”快照”只是增加GFS中chunk引用计数，表示这个chunk被快照文件引用了，等到客户端修改这个chunk时，才需要在ChunkServer中拷贝chunk数据生成新chunk，后续修改操作落到新生成chunk上。为了对某个文件做Snapshot，首先需要停顿这个文件写服务，接着增加这个文件全部chunk引用计数，以后修改这些chunk时会拷贝生成新chunk。对某个文件执行Snapshot大致步骤以下：1,经过Lease机制收回对文件每一个chunk写权限，停顿对文件写服务；2,Master拷贝文件名等元数据生成一个新Snapshot文件；3,对执行Snapshot文件全部chunk增加引用计数；比如，对文件foo执行快照操作生成foo_backup，foo在GFS中有三个chunkC1，C2和C3。Master首先需要收回C1，C2和C3写Lease，从而确保文件foo处于一致状态，接着Master复制foo文件元数据生成foo_backup，foo_backup一样指向C1，C2和C3。快照前，C1，C2和C3只被一个文件foo引用，所以引用计数为1；执行快照操作后，这些chunk引用计数增加为2。以后客户端再次往C3追加数据时，Master发觉C3引用计数大于1，通知C3所在ChunkServer此次拷贝C3生成C3′，客户端追加操作也对应地转向C3′。总结：GFS采取快照技术来实现数据回滚。ChunkServerChunkServer管理大小均为64MBchunk，存放时候需要确保chunk尽可能均匀地分布在不一样磁盘之中，可能考虑原因包含磁盘空间，最近新建chunk数，等。另外，Linux文件系统删除64MB大文件消耗时间太长，且没有必要，删除Chunk能够只将对应chunk文件移动到每个磁盘中回收站，以后新建chunk时候能够重用。ChunkServer是一个磁盘和网络IO密集型应用，为了最大程度地发挥机器性能，需要能够做到将磁盘和网络操作异步化，这会增加代码实现难度。总结：GFS并不是直接保留源文件，而是将文件分块存放。对于基于大文件应用，普遍都采取类似技术进行存放。对于小文件，则实现方案不一。ChunkServer磁盘IO是瓶颈之一，采取追加方式，防止随机写是比较普遍处理方案。GFS学习总结谷歌GFS论文详细介绍了谷歌分布式文件系统各个实现方案和动机，以上仅是个人选择认为比较主要几点加以描述，详细描述只能是去拜读第一手资料了。经过近期学习，对于分布式文件系统，有了那么一些粗浅体会。传统关系型数据库是单机应用产物，分布式文件系统是当前大数据应用主流。容错机制、负载均衡、垃圾回收、数据一致性是云存放基本要求。没有这些机制系统不是云存放系统。对于云存放系统，通常都有类似MasterServer这么元数据管理Server，对它访问是否优化，直接影响到系统性能。大部分系统都有MasterServer冗余备份，有是主备机制，有是平行机制。主备机制，有支持故障服务自动切换，有则需要人工干预。有系统提供类似快照回滚机制，有则不具备。多数系统采取类似ChunkServer这么分块存放，也有直接保留原文件。分布式文件系统语言实现多个多样，但以Java和C居多。Java移植性好，C性能卓越。对于基于C实现系统，就要检验它在文件操作上是否支持POSIX或者FUSE，这直接决定了它在各操作系统之间移植性问题。很不幸，出于性能考虑，不少产品没有实现POSIX或者FUSE，因而安装上往往很不方便。性能和易用，就看哪个产品处理得好了。开源分布式文件存放系统序言开源分布式文件存放系统非常多，也多有各自用户群体。这么短调研时间不足以将全部产品挖掘出来，只能重点列举几个，再重点横向比较一些。本文优先介绍那些流行产品，不过我在调研过程深深感到，这个互联网领域炽热应用发展实在太快了，相对来说也太纷乱了些，今天总结结果可能过段时间就变了，有愈加好产品出现了。HadoopHDFS介绍编程语言：JavaHadoop是当前互联网上最流行海量数据分布式处理软件框架。Hadoop包含很多模块，其中HDFS是它分布式文件存放系统。HDFS是模仿谷歌GFS实现两个产品之一，另一个是KFS。HDFS设计理念和GFS是高度一致，所以，了解了GFS架构，你就能了解HDFS架构。特点流行，几乎全部流行分布式系统都能够和HDFS进行对接；强大小区支持，资料完备齐全。流式数据访问，设计中更多考虑了数据批处理，而不是用户交互处理。更多考虑高吞吐量，而不是数据访问低延迟。更适合上G甚至上T大文件。一次写入数次读取，文件在经过创建、写入和关闭后就不需要改变，简化了数据一致性问题。采取master/slave架构。当前稳定版本1.0.4存在master单独故障问题，需要人工切换。不过HDFS版本繁多，有版本则具备快速自动切换功效。通信协议：基于TCP/IP长链接。健壮性：支持：数据安全（容错机制）；集群均衡；数据完整性检验和恢复；横向扩展不支持：Master节点自动恢复；快照性能HDFS作为一个Java语言开发产品，有着鲜明优缺点。开源合作更轻易，更流行。资源占用率高，系统内存缓存量很大几乎等于全部内存，iowait也很高，这点和C++产品没法比。KFS开发语言：C++，可用C++、Java和Python访问客户端。与HDFS相同，KFS也是以谷歌GFS理论为基础实现。所以和HDFS有这相同架构和特点。区分：KFS本身性能优于HDFS，但若集成到hadoop中，性能却未必出众。站在开源角度，不及HDFS活跃。流行开源文件存放系统比较比较表一：HDFSKFSMooseFSMogileFSFastDFSTFSCephGlusterFS开发语言JavaC++CPerlCC++C++C支持Client语言C/C++、Java、Python支持thriftC++、Java、PythonC、Java、PerlPerl、Java、Ruby、PHP、PythonC、Java、PHPC++、Java文件系统操作放宽了POSIX约束（怀疑包括当地实现）支持FUSE，能够直接使用mount命令挂载（怀疑包括当地实现）支持FUSE，能够直接使用mount命令挂载支持POSIX支持FUSE，能够直接使用mount命令挂载支持软链接和硬链接支持FUSE不支持POSIX、FUSE、不能mount使用能够在做了RAID服务器上运转，不过认为没有必要不支持POSIX支持POSIX支持FUSE，能够直接使用mount命令挂载支持软链接和硬链接支持POSIX支持FUSE，能够直接使用mount命令挂载磁盘上保留client上传原文件容错机制支持支持支持支持支持支持支持支持集群/负载均衡支持支持支持支持支持支持支持支持扩容能力支持动态增减支持动态增减支持动态增减支持动态增减支持动态增减支持动态增减支持动态增减高可