分布式文件系统Hadoop分布式文件系统和OpenStack对象存储有何不同

分布式到底是什么意思

这个比较复杂，这个属于架构方面的，大概是指客户端和服务器端的关系。

以前的程序的服务端比较集中在一块，分布式的服务器端可能分布在不同的地方，如云端等等。

。

。

哪个程序负责“hdfs”和“数据存储”？

负责“hdfs”和“数据存储”的程序是HDFS。

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件modityhardware)上的分布式文件系统。

它和现有的分布式文件系统有很多共同点。

但同时，它和其他的分布式文件系统的区别也是很明显的。

HDFS是一个高度容错性的系统，适合部署在廉价的机器上。

运行在HDFS之上的程序有很大量的数据集。

典型的HDFS文件大小是GB到TB的级别。

所以，HDFS被调整成支持大文件。

它应该提供很高的聚合数据带宽，一个集群中支持数百个节点，一个集群中还应该支持千万级别的文件。

?

大部分的HDFS程序对文件操作需要的是一次写多次读取的操作模式。

一个文件一旦创建、写入、关闭之后就不需要修改了。

这个假定简单化了数据一致的问题和并使高吞吐量的数据访问变得可能。

一个Map-Reduce程序或者网络爬虫程序都可以完美地适合这个模型。

gfs和hdfs文件系统的区别

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可以对其主要功能进行性能上的优化。

说到这里，突然想起了某件事。

曾经某个公司的Boss吹牛B：“我不关心J2EE，实际上在大公司里面用J2EE的很少，都有自己的一些框架。

测试过了，我们在用自己开发的框架时候性能就是以前用J2EE的时候的7倍左右。

”唬的我一跳一跳的，好牛啊！！后来想了一下，其实不是这个公司技术比SUN要强，而是J2EE是一个开源框架，其应用范围非常广，因此不能做到面面俱到。

而他们公司自己开发的框架肯定是对其主要业务逻辑方面做了专门的优化和改进，甚至删除了或者弱化了许多对他们来说作用不大的模块。

貌似这个和GFS与HDFS的关系好像！！

对比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，不过很难通过补偿操作将系统数据恢复到一致的状态，往往需要底层系统提供快照功能，将系统恢复到最近的某个一致状态。

总之，HDFS基本可以认为是GFS的简化版，由于时间及应用场景等各方面的原因对GFS的功能做了一定的简化，大大降低了复杂度。

什么是分布式系统，如何学习分布式系统

有一些系统设计基础的话，给你推荐几本书吧： 《面向模式的软件架构 卷4：分布式计算的模式语言》出版社：人民邮电出版社 主要讲分布式计算系统软件的设计和实现。

偏软件方向，相对较专业。

《分布式计算（第二版）》出版社：电子工业出版社 主要介绍分布式计算的数学基础和理论，揭示设计分布式系统的底层问题（通信、协调、同步及不确定）和基本的算法概念及下界技术。

容易理解，适合自学。

《分布式系统原理与范型》出版社：清华大学出版社 全书的第一部分讨论了分布式系统的原理、概念和技术，其中包括通信、进程、命名、同步、一致性和复制、容错以及安全。

第二部分给出了一些实际的分布式系统：基于对象的分布式系统、分布式文件系统、基于文档的分布式系统以及基于协作的分布式系统，介绍了一些实际系统的设计思想和实现技术。

容易理解，适合自学。

Hadoop分布式文件系统和OpenStack对象存储有何不同

最近在Quora上有人提到一个问题，有关Hadoop分布式文件系统和OpenStack对象存储的不同。

问题原文如下： “HDFS （Hadoop分布式文件系统）和OpenStack对象存储（OpenStack Object Storage）似乎都有着相似的目的：实现冗余、快速、联网的存储。

什么样的技术特性让这两种系统因而不一样？这两种存储系统最终趋于融合是否大有意义？” 问题提出之后，很快有OpenStack的开发者进行了回复。

本文在此摘抄了前两名回复进行翻译，以供各位参考。

排名第一的答案来自RackSpace的OpenStack Swift开发者Chuck Their： 虽然HDFS与Openstack对象存储（Swift）之间有着一些相似之处，但是这两种系统的总体设计却大不一样。

1. HDFS使用了中央系统来维护文件元数据（Namenode，名称节点），而在Swift中，元数据呈分布式，跨集群复制。

使用一种中央元数据系统对HDFS来说无异于单一故障点，因而扩展到规模非常大的环境显得更困难。

2. Swift在设计时考虑到了多租户架构，而HDFS没有多租户架构这个概念。

3. HDFS针对更庞大的文件作了优化（这是处理数据时通常会出现的情况），Swift被设计成了可以存储任何大小的文件。

4. 在HDFS中，文件写入一次，而且每次只能有一个文件写入；而在Swift中，文件可以写入多次；在并发操作环境下，以最近一次操作为准。

5. HDFS用Java来编写，而Swift用Python来编写。

另外，HDFS被设计成了可以存储数量中等的大文件，以支持数据处理，而Swift被设计成了一种比较通用的存储解决方案，能够可靠地存储数量非常多的大小不一的文件。

排名第二的答案来自Joshua McKenty，他是美国宇航局Nebula云计算项目的首席架构师，是OpenStack Nova软件的早期开发者之一，目前是OpenStack项目监管委员会的成员，还是这家基于OpenStack的公司的创始人。

Chuck刚才详细介绍了两者的技术差异，但是没有讨论两者可想而知的融合，OpenStack设计峰会上抛出了融合这个话题。

简而言之，HDFS被设计成可以使用Hadoop，跨存储环境里面的对象实现MapReduce处理。

对于许多OpenStack公司（包括我自己的公司）来说，支持Swift里面的处理是路线图上面的一个目标，不过不是每个人都认为MapReduce是解决之道。

我们已讨论过为HDFS编写包装器，这将支持OpenStack内部存储应用编程接口（API），并且让用户可以针对该数据来执行Hadoop查询。

还有一个办法就是在Swift里面使用HDFS。

但是这些方法似乎没有一个是理想的。

OpenStack社区方面也在开展研究开发方面的一些工作，认真研究其他替代性的MapReduce框架（Riak和CouchDB等）。

最后，现在有别的一些存储项目，目前“隶属于”OpenStack社区（SheepDog和HC2）。

充分利用数据局部性，并且让对象存储变得“更智能”，这是预计会取得进步的一个领域。