Hadoop分布式文件系统：架构和设计要点
Hadoop分布式文件系统：架构和设计要点
原文：https://www.doczj.com/doc/407930314.html,/core/docs/current/hdfs_design.html
一、前提和设计目标
1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。
4、 HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。
6、在异构的软硬件平台间的可移植性。
二、Namenode和Datanode
HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode 组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。Namenode和Datanode 都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部署在很大围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。
单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理所有的HDFS元数据，因而用户数据就不需要通过Namenode（也就是说文件数据的读写是直接在Datanode上）。
三、文件系统的namespace
HDFS支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。HDFS不支持user quotas和访问权限，也不支持（link)，不过当前的架构并不排除实现这些特性。Namenode维护文件系统的namespace，任何对文件系统namespace和文件属性的修改都将被Namenode记录下来。应用可以设置HDFS保存的文件的副本数目，文件副本的数目称为文件的 replication因子，这个信息也是由Namenode保存。
四、数据复制
HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block序列，除了最后一个block，所有的block都是同样的大小。文件的所有block为了容错都会被复制。每个文件的block大小和replication因子都是可配置的。Replication因子可以在文件创建的时候配置，以后也可以改变。HDFS中的文件是write-one，并且严格要求在任何时候只有一个writer。Namenode全权管理block的复制，它周期性地从集群中的每个Datanode
接收心跳包和一个Blockreport。心跳包的接收表示该Datanode节点正常工作，而Blockreport 包括了该Datanode上所有的block组成的列表。
1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架的两个节点间的带宽会比不同机架间的两台机器的带宽大。
通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到多个机架。
在大多数情况下，replication因子是3，HDFS的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个机架上，其他保存在剩下的机架中，这一策略改进了写的性能。
2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数据中心，那么reader也将首先尝试读本地数据中心的副本。
3、SafeMode
Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳包和Blockreport。Blockreport 包括了某个Datanode所有的数据块列表。每个block都有指定的最小数目的副本。当Namenode 检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode
状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些block复制到其他Datanode。
五、文件系统元数据的持久化
Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如，在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样，修改文件的replication因子也将往 Editlog插入一条记录。Namenode在本地OS的文件系统中存储这个Editlog。整个文件系统的namespace，包括block到文件的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode 所在系统的文件系统上。
Namenode在存中保存着整个文件系统namespace和文件Blockmap的映像。这个关键的元数据设计得很紧凑，因而一个带有4G存的 Namenode足够支撑海量的文件和目录。当Namenode 启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用（apply)在存中的FsImage ，并将这个新版本的FsImage从存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将实现支持周期性的checkpoint。
Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。 Datanode并不在同一个目录
创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。
六、通讯协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通过一个可配置的端口连接到Namenode，通过ClientProtocol与 Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和 Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和 Datanode 的RPC请求。
七、健壮性
HDFS的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：Namenode failures, Datanode failures和网络分割（network partitions)。
1、硬盘数据错误、心跳检测和重新复制
每个Datanode节点都向Namenode周期性地发送心跳包。网络切割可能导致一部分Datanode跟Namenode失去联系。 Namenode通过心跳包的缺失检测到这一情况，并将这些Datanode标记为dead，不会将新的IO请求发给它们。寄存在dead Datanode上的任何数据将不再有效。Datanode的死亡可能引起一些block的副本数目低于指定值，Namenode不断地跟踪需要复制的 block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个Datanode 节点失效，某个副本遭到损坏，Datanode上的硬盘错误，或者文件的replication因子增大。
2、集群均衡
HDFS支持数据的均衡计划，如果某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。这些均衡计划目前还没有实现。
3、数据完整性
从某个Datanode获取的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了HDFS文件容的校验和。当某个客户端创建一个新的HDFS文件，会计算这个文件每个block的校验和，并作为一个单独的隐藏文件保存这些校验和在同一个HDFS namespace下。当客户端检索文件容，它会确认从Datanode
获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择从其他Datanode获取该block的副本。
4、元数据磁盘错误
FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多个FsImage和Editlog的拷贝。任何对FsImage 或者Editlog的修改，都将同步到它们的副本上。这个同步操作可能会降低 Namenode每秒能支持处理的namespace事务。这个代价是可以接受的，因为HDFS是数据密集的，而非元数据密集。当Namenode重启的时候，它总是选取最近的一致的FsImage和Editlog使用。
Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。目前，在另一台机器上重启因故障而停止服务的Namenode这个功能还没实现。
5、快照
快照支持某个时间的数据拷贝，当HDFS数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能。
八、数据组织
1、数据块
兼容HDFS的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。HDFS支持文件的write- once-read-many语义。一个典型的block 大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的 Datanode
2、步骤
某个客户端创建文件的请求其实并没有立即发给Namenode，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到这个临时文件。当这个临时文件累积的数据超过一个block的大小（默认64M)，客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中，并且分配一个数据块给它，然后返回Datanode的标识符和目标数
Hadoop分布式文件系统：架构和设计 引言 (2) 一前提和设计目标 (2) 1 hadoop和云计算的关系 (2) 2 流式数据访问 (2) 3 大规模数据集 (2) 4 简单的一致性模型 (3) 5 异构软硬件平台间的可移植性 (3) 6 硬件错误 (3) 二HDFS重要名词解释 (3) 1 Namenode (4) 2 secondary Namenode (5) 3 Datanode (6) 4 jobTracker (6) 5 TaskTracker (6) 三HDFS数据存储 (7) 1 HDFS数据存储特点 (7) 2 心跳机制 (7) 3 副本存放 (7) 4 副本选择 (7) 5 安全模式 (8) 四HDFS数据健壮性 (8) 1 磁盘数据错误，心跳检测和重新复制 (8) 2 集群均衡 (8) 3 数据完整性 (8) 4 元数据磁盘错误 (8) 5 快照 (9)
引言 云计算（cloud computing)，由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。在此过程中被服务者只是提供需求并获取服务结果，对于需求被服务的过程并不知情。同时服务者以最优利用的方式动态地把资源分配给众多的服务请求者，以求达到最大效益。 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS 能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。 一前提和设计目标 1 hadoop和云计算的关系 云计算由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。针对海量文本数据处理,为实现快速文本处理响应,缩短海量数据为辅助决策提供服务的时间,基于Hadoop云计算平台,建立HDFS分布式文件系统存储海量文本数据集,通过文本词频利用MapReduce原理建立分布式索引,以分布式数据库HBase 存储关键词索引,并提供实时检索,实现对海量文本数据的分布式并行处理.实验结果表 明,Hadoop框架为大规模数据的分布式并行处理提供了很好的解决方案。 2 流式数据访问 运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3 大规模数据集 运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
６苏州大学学报（工科版）第３０卷 图１Ｉ－ＩＤＦＳ架构 ２ＨＤＦＳ与ＬｉｎｕｘＦＳ比较 ＨＤＦＳ的节点不管是ＤａｔａＮｏｄｅ还是ＮａｍｅＮｏｄｅ都运行在Ｌｉｎｕｘ上，ＨＤＦＳ的每次读／写操作都要通过ＬｉｎｕｘＦＳ的读／写操作来完成，从这个角度来看，ＬｉｎｕｘＰＳ是ＨＤＦＳ的底层文件系统。 ２．１目录树（ＤｉｒｅｃｔｏｒｙＴｒｅｅ） 两种文件系统都选择“树”来组织文件，我们称之为目录树。文件存储在“树叶”，其余的节点都是目录。但两者细节结构存在区别，如图２与图３所示。 一二 Ｒｏｏｔ ＼ 图２ＩｔＤＦＳ目录树围３ＬｉｎｕｘＦＳ目录树 ２．２数据块（Ｂｌｏｃｋ） Ｂｌｏｃｋ是ＬｉｎｕｘＦＳ读／写操作的最小单元，大小相等。典型的ＬｉｎｕｘＦＳＢｌｏｃｋ大小为４ＭＢ，Ｂｌｏｃｋ与ＤａｔａＮ－ｏｄｅ之间的对应关系是固定的、天然存在的，不需要系统定义。 ＨＤＦＳ读／写操作的最小单元也称为Ｂｌｏｃｋ，大小可以由用户定义，默认值是６４ＭＢ。Ｂｌｏｃｋ与ＤａｔａＮｏｄｅ的对应关系是动态的，需要系统进行描述、管理。整个集群来看，每个Ｂｌｏｃｋ存在至少三个内容一样的备份，且一定存放在不同的计算机上。 ２．３索引节点（ＩＮｏｄｅ） ＬｉｎｕｘＦＳ中的每个文件及目录都由一个ＩＮｏｄｅ代表，ＩＮｏｄｅ中定义一组外存上的Ｂｌｏｃｋ。 ＨＤＰＳ中ＩＮｏｄｅ是目录树的单元，ＨＤＦＳ的目录树正是在ＩＮｏｄｅ的集合之上生成的。ＩＮｏｄｅ分为两类，一类ＩＮｏｄｅ代表文件，指向一组Ｂｌｏｃｋ，没有子ＩＮｏｄｅ，是目录树的叶节点；另一类ＩＮｏｄｅ代表目录，没有Ｂｌｏｃｋ，指向一组子ＩＮｏｄｅ，作为索引节点。在Ｈａｄｏｏｐ０．１６．０之前，只有一类ＩＮｏｄｅ，每个ＩＮｏｄｅ都指向Ｂｌｏｃｋ和子ＩＮ－ｏｄｅ，比现有的ＩＮｏｄｅ占用更多的内存空间。 ２．４目录项（Ｄｅｎｔｒｙ） Ｄｅｎｔｒｙ是ＬｉｎｕｘＦＳ的核心数据结构，通过指向父Ｄｅｎ姆和子Ｄｅｎｔｒｙ生成目录树，同时也记录了文件名并 指向ＩＮｏｄｅ，事实上是建立了＜ＦｉｌｅＮａｍｅ，ＩＮｏｄｅ＞，目录树中同一个ＩＮｏｄｅ可以有多个这样的映射，这正是连
太原理工大学 硕士学位论文 基于Hadoop的分布式搜索引擎研究与实现 姓名：封俊 申请学位级别：硕士 专业：软件工程 指导教师：胡彧 20100401
基于Hadoop的分布式搜索引擎研究与实现 摘要 分布式搜索引擎是一种结合了分布式计算技术和全文检索技术的新型信息检索系统。它改变了人们获取信息的途径，让人们更有效地获取信息，现在它已经深入到网络生活的每一方面，被誉为上网第一站。 目前的搜索引擎系统大多都拥有同样的结构——集中式结构，即系统所有功能模块集中部署在一台服务器上，这直接导致了系统对服务器硬件性能要求较高，同时，系统还有稳定性差、可扩展性不高的弊端。为了克服以上弊端就必须采购极为昂贵的大型服务器来满足系统需求，然而并不是所有人都有能力负担这样高昂的费用。此外，在传统的信息检索系统中，许多都采用了比较原始的字符串匹配方式来获得搜索结果，这种搜索方式虽然实现简单，但在数据量比较大时，搜索效率非常低，导致用户无法及时获得有效信息。以上这两个缺点给搜索引擎的推广带来了很大的挑战。为应对这个挑战，在搜索引擎系统中引入了分布式计算和倒排文档全文检索技术。 本文在分析当前几种分布式搜索引擎系统的基础上，总结了现有系统的优缺点，针对现有系统的不足，提出了基于Hadoop的分布式搜索引擎。主要研究工作在于对传统搜索引擎的功能模块加以改进，对爬行、索引、搜索过程中的步骤进行详细分析，将非顺序执行的步骤进一步分解为两部分：数据计算和数据合并。同时，应用Map/Reduce编程模型思想，把数据计算任务封装到Map函数中，把数据合并任务封装到Reduce函数中。经过以上改进的搜索引擎系统可以部署在廉价PC构成的Hadoop分布式环境中，并具有较高的响应速度、可靠性和扩展性。这与分布式搜索引擎中的技术需求极为符合，因此本文使用Hadoop作为系统分布式计算平台。此外，系
1DFS系统 (DFS) 是AFS的一个版本，作为开放软件基金会(OSF)的分布 分布式文件系统 式计算环境(DCE)中的文件系统部分。 如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式： 只读共享任何客户机只能访问文件，而不能修改它，这实现起来很简单。 受控写操作采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。 并发写操作这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。 NFS和AFS的区别 NFS和AFS的区别在于对并发写操作的处理方法上。当一个客户机向服务器请求一个文件(或数据库记录)，文件被放在客户工作站的高速缓存中，若另一个用户也请求同一文件，则它也会被放入那个客户工作站的高速缓存中。当两个客户都对文件进行修改时，从技术上而言就存在着该文件的三个版本(每个客户机一个，再加上服务器上的一个)。有两种方法可以在这些版本之间保持同步： 无状态系统在这个系统中，服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。这种方法在大的环境中会产生额外的LAN通信开销，但对小型LAN来说，这是一种令人满意的方法。NFS 就是个无状态系统。 回呼(Callback)系统在这种方法中，服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用一种叫回叫应答(callbackpromise)的技术通知其它客户机。这种方法减少了大量网络通信。AFS(及OSFDCE的DFS)就是回叫系统。客户机改变文件时，持有这些文件拷贝的其它客户机就被回叫并通知这些改变。 无状态操作在运行性能上有其长处，但AFS通过保证不会被回叫应答充斥也达到了这一点。方法是在一定时间后取消回叫。客户机检查回叫应答中的时间期限以保证回叫应答是当前有效的。回叫应答的另一个有趣的特征是向用户保证了文件的当前有效性。换句话说，若
Hadoop测试题 一．填空题，1分（41空），2分（42空）共125分 1.(每空1分) datanode 负责HDFS数据存储。 2.(每空1分)HDFS中的block默认保存 3 份。 3.(每空1分)ResourceManager 程序通常与NameNode 在一个节点启动。 4.(每空1分)hadoop运行的模式有：单机模式、伪分布模式、完全分布式。 5.(每空1分)Hadoop集群搭建中常用的4个配置文件为：core-site.xml 、hdfs-site.xml 、mapred-site.xml 、yarn-site.xml 。 6.(每空2分)HDFS将要存储的大文件进行分割，分割后存放在既定的存储块 中，并通过预先设定的优化处理，模式对存储的数据进行预处理，从而解决了大文件储存与计算的需求。 7.(每空2分)一个HDFS集群包括两大部分，即namenode 与datanode 。一般来说，一 个集群中会有一个namenode 和多个datanode 共同工作。 8.(每空2分) namenode 是集群的主服务器，主要是用于对HDFS中所有的文件及内容 数据进行维护，并不断读取记录集群中datanode 主机情况与工作状态，并通过读取与写入镜像日志文件的方式进行存储。 9.(每空2分) datanode 在HDFS集群中担任任务具体执行角色，是集群的工作节点。文 件被分成若干个相同大小的数据块，分别存储在若干个datanode 上，datanode 会定期向集群内namenode 发送自己的运行状态与存储内容，并根据namnode 发送的指令进行工作。 10.(每空2分) namenode 负责接受客户端发送过来的信息，然后将文件存储位置信息发 送给client ，由client 直接与datanode 进行联系，从而进行部分文件的运算与操作。 11.(每空1分) block 是HDFS的基本存储单元，默认大小是128M 。 12.(每空1分)HDFS还可以对已经存储的Block进行多副本备份，将每个Block至少复制到 3 个相互独立的硬件上，这样可以快速恢复损坏的数据。 13.(每空2分)当客户端的读取操作发生错误的时候，客户端会向namenode 报告错误，并 请求namenode 排除错误的datanode 后，重新根据距离排序，从而获得一个新的的读取路径。如果所有的datanode 都报告读取失败，那么整个任务就读取失败。14.(每空2分)对于写出操作过程中出现的问题，FSDataOutputStream 并不会立即关闭。 客户端向Namenode报告错误信息，并直接向提供备份的datanode 中写入数据。备份datanode 被升级为首选datanode ，并在其余2个datanode 中备份复制数据。 NameNode对错误的DataNode进行标记以便后续对其进行处理。 15.(每空1分)格式化HDFS系统的命令为：hdfs namenode –format 。 16.(每空1分)启动hdfs的shell脚本为：start-dfs.sh 。 17.(每空1分)启动yarn的shell脚本为：start-yarn.sh 。 18.(每空1分)停止hdfs的shell脚本为：stop-dfs.sh 。 19.(每空1分)hadoop创建多级目录（如：/a/b/c）的命令为：hadoop fs –mkdir –p /a/b/c 。 20.(每空1分)hadoop显示根目录命令为：hadoop fs –lsr 。 21.(每空1分)hadoop包含的四大模块分别是：Hadoop common 、HDFS 、
分布式文件系统架构设计 1. 前言...................................................... 3.
2. HDFS1 (3) 3. HDFS2 (5) 4. HDFS3 ............................................................................................. 1 1 5. 结语..................................................... 1.5
1. 刖言 Hadoop 是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 Hadoop 实现了一个分布式文件系统(Hadoop Distributed File System )，简称HDFS，解 决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce ，解决了海量数据如何计 算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。而我 们今天重点给大家介绍的是Hadoop 里享誉世界的优秀的分布式文件系统-HDFS。 Hadoop 重要的比较大的版本有:Hadoop1 ,Hadoop2 , hadoop3 。同时也相对应的有HDFS1 ，HDFS2，HDFS3三个大版本。后面的HDFS的版本，都是对前一个版本的架构进行了调整优 化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我 们的系统架构能力。 2. HDFS1
Hadoop面试题目及答案(附目录) 选择题 1.下面哪个程序负责HDFS 数据存储。 a)NameNode b)Jobtracker c)Datanode d)secondaryNameNode e)tasktracker 答案C datanode 2. HDfS 中的block 默认保存几份？ a)3 份b)2 份c)1 份d)不确定 答案A 默认3 份 3.下列哪个程序通常与NameNode 在一个节点启动？ a)SecondaryNameNode b)DataNode c)TaskTracker d)Jobtracker 答案D 分析：hadoop 的集群是基于master/slave 模式，namenode 和jobtracker 属于master，datanode 和tasktracker 属于slave，master 只有一个，而slave 有多个SecondaryNameNode 内存需求和NameNode 在一个数量级上，所以通常secondaryNameNode（运行在单独的物理机器上）和NameNode 运行在不同的机器上。 JobTracker 和TaskTracker JobTracker 对应于NameNode，TaskTracker 对应于DataNode，DataNode 和NameNode 是针对数据存放来而言的，JobTracker 和TaskTracker 是对于MapReduce 执行而言的。mapreduce 中几个主要概念，mapreduce 整体上可以分为这么几条执行线索：jobclient，JobTracker 与TaskTracker。 1、JobClient 会在用户端通过JobClient 类将应用已经配置参数打包成jar 文件存储到hdfs，并把路径提交到Jobtracker,然后由JobTracker 创建每一个Task（即MapTask 和ReduceTask）并将它们分发到各个TaskTracker 服务中去执行。 2、JobTracker 是一个master 服务，软件启动之后JobTracker 接收Job，负责调度Job 的每一个子任务task 运行于TaskTracker 上，并监控它们，如果发现有失败的task 就重新运行它。一般情况应该把JobTracker 部署在单独的机器上。 3、TaskTracker 是运行在多个节点上的slaver 服务。TaskTracker 主动与JobTracker 通信，接收作业，并负责直接执行每一个任务。TaskTracker 都需要运行在HDFS 的DataNode 上。 4. Hadoop 作者 a)Martin Fowler b)Kent Beck c)Doug cutting 答案C Doug cutting 5. HDFS 默认Block Size a)32MB b)64MB c)128MB 答案：B 6. 下列哪项通常是集群的最主要瓶颈 a)CPU b)网络c)磁盘IO d)内存 答案：C 磁盘 首先集群的目的是为了节省成本，用廉价的pc 机，取代小型机及大型机。小型机和大型机
Hadoop云计算平台及相关组件搭建安装过程详细教程 ——Hbase+Pig+Hive+Zookeeper+Ganglia+Chukwa+Eclipse等 一．安装环境简介 根据官网，Hadoop已在linux主机组成的集群系统上得到验证，而windows平台是作为开发平台支持的，由于分布式操作尚未在windows平台上充分测试，所以还不作为一个生产平台。Windows下还需要安装Cygwin，Cygwin是在windows平台上运行的UNIX模拟环境，提供上述软件之外的shell支持。 实际条件下在windows系统下进行Hadoop伪分布式安装时，出现了许多未知问题。在linux系统下安装，以伪分布式进行测试，然后再进行完全分布式的实验环境部署。Hadoop完全分布模式的网络拓补图如图六所示： （1）网络拓补图如六所示： 图六完全分布式网络拓补图 （2）硬件要求：搭建完全分布式环境需要若干计算机集群，Master和Slaves 处理器、内存、硬盘等参数要求根据情况而定。 （3）软件要求 操作系统64位版本:
并且所有机器均需配置SSH免密码登录。 二． Hadoop集群安装部署 目前，这里只搭建了一个由三台机器组成的小集群，在一个hadoop集群中有以下角色：Master和Slave、JobTracker和TaskTracker、NameNode和DataNode。下面为这三台机器分配IP地址以及相应的角色： ——master，namenode，jobtracker——master（主机名） ——slave，datanode，tasktracker——slave1（主机名） ——slave，datanode，tasktracker——slave2（主机名） 实验环境搭建平台如图七所示：
龙源期刊网 https://www.doczj.com/doc/407930314.html, 基于Hadoop的分布式文件系统 作者：陈忠义 来源：《电子技术与软件工程》2017年第09期 摘要HDFS是Hadoop应用用到的一个最主要的分布式存储系统，Hadoop分布式文件系 统具有方便、健壮、可扩展性、容错性能好、操作简单、成本低廉等许多优势。。深入了解HDFS的工作原理对在特定集群上改进HDFS的运行性能和错误诊断都有极大的帮助。本文介绍了HDFS的主要设计理念、主要概念及其高可靠性的实现等。 【关键词】Hadoop 分布式文件系统 Hadoop是新一代的大数据处理平台，在近十年中已成为大数据革命的中心，它不仅仅承担存储海量数据，还通过分析从中获取有价值信息。进行海量计算需要一个稳定的，安全的数据容器，管理网络中跨多台计算机存储的文件系统称为分布式文件系统。Hadoop分布式文件系统（Hadoop Distributed File System）运应而生，它是Hadoop的底层实现部分，存储Hadoop 集群中所有存储节点上的文件。 1 HDFS的设计理念 面对存储超大文件，Hadoop分布式文件系统采用了流式数据访问模式。所谓流式数据，简单的说就是像流水一样，数据一点一点“流”过来，处理数据也是一点一点处理。如果是全部收到数据以后再进行处理，那么延迟会很大，而且会消耗大量计算机内存。 1.1 存储超大文件 这里的“超大文件”通常达到几百GB甚至达到TB大小的文件。像大型的应用系统，其存储超过PB级数据的Hadoop集群比比皆是。 1.2 数据访问模式 最高效的访问模式是一次写入、多次读取。HDFS的构建思路也是这样的。HDFS存储的数据集作为Hadoop的分析对象。在数据集生成以后，采用各种不同分析方法对该数据集进行长时间分析，而且分析涉及到该数据集的大部分数据或者全部数据。面对庞大数据，时间延迟是不可避免的，因此，Hadoop不适合运行低时间延迟数据访问的应用。 1.3 运行在普通廉价的服务器上 HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。
由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署（即lvs+keepalived的方式），但仍然有用户反馈访问慢的问题。通过排查个服务器的情况，发现问题的根源在于共享存储服务器NFS。在我这个网络环境里，N个服务器通过nfs方式共享一个服务器的存储空间，使得 NFS服务器不堪重负。察看系统日志，全是nfs服务超时之类的报错。一般情况下，当nfs客户端数目较小的时候，NFS性能不会出现问题；一旦NFS服务器数目过多，并且是那种读写都比较频繁的操作，所得到的结果就不是我们所期待的。 下面是某个集群使用nfs共享的示意图： 这种架构除了性能问题而外，还存在单点故障，一旦这个NFS服务器发生故障，所有靠共享提供数据的应用就不再可用，尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份，但这对提高整个系统的性能毫无帮助。基于这样一种需求，我们需要对nfs服务器进行优化或采取别的解决方案，然而优化并不能对应对日益增多的客户端的性能要求，因此唯一的选择只能是采取别的解决方案了；通过调研，分布式文件系统是一个比较合适的选择。采用分布式文件系统后，服务器之间的数据访问不再是一对多的关系（1个NFS服务器，多个NFS 客户端），而是多对多的关系，这样一来，性能大幅提升毫无问题。 到目前为止，有数十种以上的分布式文件系统解决方案可供选择，如 lustre,hadoop,Pnfs等等。我尝试了 PVFS,hadoop,moosefs这三种应用，参看了lustre、KFS等诸多技术实施方法，最后我选择了moosefs（以下简称MFS）
这种分布式文件系统来作为我的共享存储服务器。为什么要选它呢？我来说说我的一些看法： 1、实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说，要简单和容易得多。看看lustre 700多页的pdf文档，让人头昏吧。 2、不停服务扩容。MFS框架做好后，随时增加服务器扩充容量；扩充和减少容量皆不会影响现有的服务。注：hadoop也实现了这个功能。 3、恢复服务容易。除了MFS本身具备高可用特性外，手动恢复服务也是非常快捷的，原因参照第1条。 4、我在实验过程中得到作者的帮助，这让我很是感激。 MFS文件系统的组成 1、元数据服务器。在整个体系中负责管理管理文件系统，目前MFS只支持一个元数据服务器master，这是一个单点故障，需要一个性能稳定的服务器来充当。希望今后MFS能支持多个master服务器，进一步提高系统的可靠性。 2、数据存储服务器chunkserver。真正存储用户数据的服务器。存储文件时，首先把文件分成块，然后这些块在数据服务器chunkserver之间复制（复制份数可以手工指定，建议设置副本数为3）。数据服务器可以是多个，并且数量越多，可使用的“磁盘空间”越大，可靠性也越高。 3、客户端。使用MFS文件系统来存储和访问的主机称为MFS的客户端，成功挂接MFS文件系统以后，就可以像以前使用NFS一样共享这个虚拟性的存储了。 元数据服务器安装和配置
外文翻译 原文来源The Hadoop Distributed File System: Architecture and Design 中文译文Hadoop分布式文件系统：架构和设计 姓名 XXXX 学号 200708202137 2013年4月8 日
英文原文 The Hadoop Distributed File System: Architecture and Design Source：https://www.doczj.com/doc/407930314.html,/docs/r0.18.3/hdfs_design.html Introduction The Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems. However, the differences from other distributed file systems are significant. HDFS is highly fault-tolerant and is designed to be deployed on low-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large data sets. HDFS relaxes a few POSIX requirements to enable streaming access to file system data. HDFS was originally built as infrastructure for the Apache Nutch web search engine project. HDFS is part of the Apache Hadoop Core project. The project URL is https://www.doczj.com/doc/407930314.html,/core/. Assumptions and Goals Hardware Failure Hardware failure is the norm rather than the exception. An HDFS instance may consist of hundreds or thousands of server machines, each storing part of the file system’s data. The fact that there are a huge number of components and that each component has a non-trivial probability of failure means that some component of HDFS is always non-functional. Therefore, detection of faults and quick, automatic recovery from them is a core architectural goal of HDFS. Streaming Data Access Applications that run on HDFS need streaming access to their data sets. They are not general purpose applications that typically run on general purpose file systems. HDFS is designed more for batch processing rather than interactive use by users. The emphasis is on high throughput of data access rather than low latency of data access. POSIX imposes many hard requirements that are not
实验七 zookeeper分布式的配置 tar -zxvf zookeeper-3.4.5.tar.gz mv zookeeper-3.4.5 zookeeper cd zookeeper mkdir data mkdir logs 三、集群模式 集群模式就是在不同主机上安装zookeeper然后组成集群的模式；下边以在192.168.1.1，192.168.1.2，192.168.1.3三台主机为例。 zookeeper 配置 1.Zookeeper服务集群规模不小于三个节点，要求各服务之间系统时间要保持一致。 2.在master的/home/chenlijun目录下，解压缩zookeeper（执行命令tar –zvxf zooke eper.tar.gz） 3.设置环境变量 打开/etc/profile文件！内容如下：
[html]view plain copy 1.#set java & hadoop 2. 3.export JAVA_HOME=/home/chenlijun/java/ 4. 5.export HADOOP_HOME=/home/chenlijun/hadoop 6. 7.export ZOOKEEPER_HOME=/home/chenlijun/zookeeper 8. 9.export PATH=.:$HADOOP_HOME/bin:$ZOOKEEPER_HOME/bin:$JAVA_HOME/bin:$PATH 注：修改完后profile记得执行source /etc/profile 4.在解压后的zookeeper的目录下进入conf目录修改配置文件 更名操作：mv zoo_sample.cfg zoo.cfg 5.编辑zoo.cfg (vi zoo.cfg) 修改dataDir=/home/chenlijun/zookeeper/data/ 新增server.0=master:2888:3888 server.1=slave1:2888:3888 server.2=slave2:2888:3888 文件如下：
第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH，一种拟算法来分配文件的locaiton，其核心是 RADOS（resilient automatic distributed object storage)，一个对象集群存储，本身提供对象的高可用，错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块： a)Client：每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇：用于存储所有的数据和元数据。 c)元数据服务簇：协调安全性、一致性与耦合性时，管理命名空间（文件名和 目录名） 1.3 架构原理 Client：用户 I/O：输入/输出 MDS：Metadata Cluster Server 元数据簇服务器 OSD：Object Storage Device 对象存储设备
Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式： 1. 直接通过Client实例连接到Client； 2. 通过一个文件系统连接到Client。 当一个进行打开一个文件时，Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点（inode），并获得节点号、模式（mode）、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权，则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权（如果该Client还没有的话）。目前操作权有四种，分别通过一个bit表示：读（read）、缓冲读（cache read）、写（write）、缓冲写（buffer write）。在未来，操作权会增加安全关键字，用于client向OSD证明它们可以对数据进行读写（目前的策略是全部client 都允许）。之后，包含在文件I/O中的MDS被用于限制管理能力，以保证文件的一致性与语义的合理性。 CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH（著名的映射函数）分配给OSD。例如，如果一个或多个Client打开同一个文件进行读操作，一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小，Client可以命名或分配所有包含该文件数据的对象，并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的，如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client 关闭文件时，会自动放弃这种能力，并向MDS提供新的文件大小（写入时的最大偏移）。它重新定义了那些存在的并包含文件数据的对象的集合。 CEPH的设计思想有一些创新点主要有以下两个方面： 第一，数据的定位是通过CRUSH算法来实现的。
Hadoop分布式文件系统：架构和设计要点 Hadoop分布式文件系统：架构和设计要点 原文：https://www.doczj.com/doc/407930314.html,/core/docs/current/hdfs_design.html 一、前提和设计目标 1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。 2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。 4、 HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。 5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。 6、在异构的软硬件平台间的可移植性。 二、Namenode和Datanode HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode 组成。Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创建、删除和复制。Namenode和Datanode 都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部署在很大围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排除一台机器上跑多个Datanode，不过这比较少见。
毕业设计（论文） 中文题目:基于hadoop的分布式存储平台的搭建与验证 英文题目:Setuping and verification distributed storage platform based on hadoop 学院：计算机与信息技术 专业：信息安全 学生姓名： 学号： 指导教师： 2018 年06 月01 日 1
任务书 题目：基于hadoop的分布式文件系统的实现与验证 适合专业：信息安全 指导教师（签名）： 毕业设计（论文）基本内容和要求： 本项目的目的是要在单独的一台计算机上实现Hadoop多节点分布式计算系统。 基本原理及基本要求如下： 1.实现一个NameNode NameNode 是一个通常在 HDFS 实例中的单独机器上运行的软件。它负责管理文件系统名称空间和控制外部客户机的访问。NameNode 决定是否将文件映射到 DataNode 上的复制块上。 实际的 I/O 事务并没有经过 NameNode，只有表示 DataNode 和块的文件映射的元数据经过 NameNode。当外部客户机发送请求要求创建文件时，NameNode 会以块标识和该块的第一个副本的 DataNode IP 地址作为响应。这个 NameNode 还会通知其他将要接收该块的副本的 DataNode。 2。实现若干个DataNode DataNode 也是一个通常在 HDFS 实例中的单独机器上运行的软件。Hadoop 集群包含一个 NameNode 和大量 DataNode。DataNode 通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。Hadoop 的一个假设是：机架内部节点之间的传输速度快于机架间节点的传输速度。 DataNode 响应来自 HDFS 客户机的读写请求。它们还响应来自NameNode 的创建、删除和复制块的命令。NameNode 依赖来自每个DataNode 的定期心跳（heartbeat）消息。每条消息都包含一个块报告，NameNode 可以根据这个报告验证块映射和其他文件系统元数据。如果DataNode 不能发送心跳消息，NameNode 将采取修复措施，重新复制在该节点上丢失的块。 具体设计模块如下：
实验报告封面 课程名称： Hadoop大数据处理课程代码： JY1124 任课老师：宁穗实验指导老师: 宁穗 实验报告名称：实验3 Hadoop安装与配置2 学生： 学号： 教学班： 递交日期： 签收人： 我申明，本报告的实验已按要求完成，报告完全是由我个人完成，并没有抄袭行为。我已经保留了这份实验报告的副本。 申明人(签名): 实验报告评语与评分： 评阅老师签名：
一、实验名称：Hadoop安装与配置 二、实验日期：2015年9 月25 日 三、实验目的： Hadoop安装与配置。 四、实验用的仪器和材料： 安装环境:以下两个组合之一 1.硬件环境：存ddr3 4G及以上的x86架构主机一部 系统环境：windows 、linux或者mac os x 软件环境：运行vmware或者virtualbox (2) 存ddr 1g及以上的主机两部及以上 五、实验的步骤和方法： 本次实验重点在ubuntu中安装jdk以及hadoop。 一、关闭防火墙 sudo ufw disable iptables -F 二、jdk的安装 1、普通用户下添加grid用户
2、准备jdk压缩包，把jdk压缩包放到以上目录（此目录可自行设置） 3、将jdk压缩包解压改名 改名为jdk：mv jdk1.7.0_45 jdk 移动到/usr目录下：mv jdk /usr（此目录也可自行设置，但需与配置文件一致）4、设置jdk环境变量 此采用全局设置方法，更改/etc/profile文件 sudo gedit /etc/profile 添加（根据情况自行设置） export JA VA_HOME=/usr/jdk export JRE_HOME=/usr/ jdk/jre export CLASSPATH=.:$JA V A_HOME/lib:$JRE_HOME/lib:$CLASSPATH export PA TH=$JA V A_HOME/bin: $JRE_HOME/ bin: $PATH 然后保存。 5、检验是否安装成功 java -version 二、ssh免密码 1、退出root用户，su grid 生成密钥 ssh-keygen –t rsa
分布式文件系统（DFS）解决方案 一“分布式文件系统（DFS）”概述 DFS并不是一种文件系统，它是Windows Server System上的一种客户/服务器模式的网络服务。它可以让把局域网中不同计算机上的不同的文件共享按照其功能组织成一个逻辑的分级目录结构。系统管理员可以利用分布式文件系统(DFS)，使用户访问和管理那些物理上跨网络分布的文件更加容易。通过DFS，可以使分布在多个服务器或者不同网络位置的文件在用户面前显示时，就如同位于网络上的一个位置。用户在访问文件时不再需要知道和指定它们的实际物理位置。 例如，如果您的销售资料分散在某个域中的多个存储设备上，您可以利用DFS 使其显示时就好像所有的资料都位于同一网络共享下，这样用户就不必到网络上的多个位置去查找他们需要的信息。 二部署使用“分布式文件系统（DFS）”的原因 ●访问共享文件夹的用户分布在一个站点的多个位置或多个站点上； ●大多数用户都需要访问多个共享文件夹； ●通过重新分布共享文件夹可以改善服务器的负载平衡状况； ●用户需要对共享文件夹的不间断访问；
●您的组织中有供内部或外部使用的Web 站点； ●用户访问共享文件需要权限。 三“分布式文件系统（DFS）”类型 可以按下面两种方式中的任何一种来实施分布式文件系统： 1．作为独立的分布式文件系统。 ●不使用Active Directory。 ●至多只能有一个根目录级别的目标。 ●使用文件复制服务不能支持自动文件复制。 ●通过服务器群集支持容错。 2．作为基于域的分布式文件系统。 ●必须宿主在域成员服务器上。 ●使它的DFS 名称空间自动发布到Active Directory 中。 ●可以有多个根目录级别的目标。 ●通过FRS 支持自动文件复制。 ●通过FRS 支持容错。 四分布式文件系统特性 除了Windows Server System 中基于服务器的DFS 组件外，还有基于客户的DFS 组件。DFS 客户程序可以将对DFS 根目录或DFS 链接的引用缓存一段时间，该时间由管理员指定。此存储和读取过程对于