该文档是用户使用Hadpoop分布式文件系统(HDFS)的起点,不论是做为hadoop集群的一部分来使用仍是独立的通用分布式文件系统。虽然在不少场景下HDFS被设计成“正常工做”便可,可是掌握更多的HDFS工做机制将有利于更好的配置以及诊断。html
HDFS是使用Hadoop程序来实现的分布式存储系统。一个HDFS集群主要包含管理文件系统命名空间的Namenode以及存储实际数据的Datanode。HDFS架构指南已经详细介绍了HDFS。本用户指南主要负责用户、管理员与HDFS集群之间交互的介绍。HDFS架构图描述了Namenode、Datanode以及客户端之间的基本交互。客户端联系NameNode以获取文件元数据或文件修改,并直接使用DataNodes执行实际文件I/O。前端
下面多是许多用户感兴趣的一些显著特性。node
下面的文档介绍如何安装和启动一个Hadoop集群:web
接下来的文档假设用户有能力搭建并运行至少有一个Datanode的HDFS。完成本文档的学习,用户能够将Namenode和Datanode放在同一台物理机上。shell
Namenode和Datanode内部都运行了web服务,用来展现集群当前状态的基本信息。默认配置下,Namenode的前端页面请访问http://namenode-name:50070/。 该页面展现Datanode列表以及集群的基本统计信息。这个web接口一样能够用来浏览文件系统(点击页面中的“Browse the file system”)。apache
Hadoop包含丰富的类 shell 命令,用来跟HDFS和其余Hadoop支持的文件系统进行直接交互。运行“bin/hdfs dfs -help”命令将列出Hadoop支持的命令。此外,运行“bin/hdfs dfs -help command-name” 展现“command-name”命令的详细信息。这些命令支持大部分普通的文件系统操做,例如拷贝文件,修改文件权限等等。它还支持一些HDFS的特定操做,例如改变文件复制。详细信息请查看 File System Shell Guide安全
“bin/hdfs dfsadmin” 命令支持一些跟HDFS管理员相关的操做。“bin/hdfs dfsadmin -help” 命令会列出当前支持的全部命令。例如:架构
更多信息,请查看 dfsadmin分布式
Namenode以日志的形式存储更新信息,该日志信息追加到本地文件edits中。当Namenode启动,它从一个称为“FsImage”的image文件中读取HDFS状态,而后使用编辑日志文件中的修改信息。随后,写入新的HDFS状态到FsImage文件中并使用一个新的空的的edits文件开始常规操做。由于Namenode只在启动的时候才合并Fsimage和edits文件,在一个工做频繁的集群上edits日志文件会变得很是庞大,这会致使Namenode下次重启时会花费很长时间。ide
Secondary NameNode按期合并Fsimage和edits文件,并保持edits文件大小在一个限定范围内。Secondary NameNode一般运行在与主Namenode不一样的机器上,由于Secondary NameNode须要相同大的内存来保证其运行。
启动运行在Secondary NameNode的检查点,主要被被两个配置参数控制:
Secondary NameNode将最新的检查点保存在与主Namenode项目的文件路径下。因此,当须要时NameNode能够随时读取Secondary NameNode上的检查点image文件。
详细信息,请查看Secondary NameNode
Namenode经过两种文件来维持命名空间:fsimage以及journal (log)。其中,fsimage是命名空间的最大检查点以及编辑文件,journal则记录自上一个检查点以后的更新操做。当NameNode启动时,它会合并fsimage和edits journal以提供文件系统元数据的最新视图。NameNode而后用新的HDFS状态覆盖fsimage并开始一个新的编辑日志。
检查点节点按期建立命名空间的检查点。它从活跃的Namenode上下载fsimage和edits,而后在本地进行合并,最后上传最新的fsimage到活跃的Namenode上。检查点节点一般运行在与主Namenode不一样的机器上,由于检查点节点须要相同大的内存来保证其运行。用户能够在配置文件指定的节点上运行“bin/hdfs namenode -checkpoint”来启动检查点节点。
“dfs.namenode.backup.address”和“dfs.namenode.backup.http-address”配置属性能够指定检查点节点的位置以及其web接口地址。
两个配置参数影响检查点的运行:
检查点节点将最新的检查点保存在与主Namenode项目的文件路径下。因此,当须要时NameNode能够随时读取检查点节点上的检查点image文件。
集群配置文件中能够同时指定多个检查点。
详细信息,请查看 namenode
备份节点跟检查点节点同样提供相同的检查功能,将相关信息保存在内存中,更新命名空间的拷贝并与活跃Namenode状态保持同步。除了接受来自NameNode的文件系统编辑的日志流并将其持久保存到磁盘以外,备份节点还将这些编辑应用到其本身的内存中命名空间的副本中,从而建立命名空间的备份。
备份节点不须要像Secondary NameNode和Checkpoint node同样从活动NameNode下载fsimage和编辑文件,以便建立检查点,由于它已经保存命名空间的最新状态在内存中。备份节点进程更高效,由于它只须要将命名空间保存到本地fsimage文件中并重置编辑。
由于备份节点须要将命名空间保存在内存中,因此它须要跟Namenode同样的内存大小。
Namenode一次只支持一个备份节点。当备份节点在使用时,咱们就无需检查点节点。同时支持多个备份节点将在将来实现。
备份节点的配置方式与检查点节点相同。咱们可使用“bin/hdfs namenode -backup”来启动备份节点。
“dfs.namenode.backup.address”和“dfs.namenode.backup.http-address”配置属性能够指定备份节点的位置以及其web接口地址。
备份节点提供了使NameNode运行时不须要进行持久化的选项,将保留命名空间状态的全部责任委派给备份节点。要执行此操做,请使用-importCheckpoint选项来启动NameNode,并为edits类型设置非持久性存储目录 dfs.namenode.edits.dir。
关于备份节点和检查点节点的产生缘由的讨论,查看 HADOOP-4539
若是fsimage和edits文件的备份丢失,咱们能够将最新的检查点导入到Namenode中。操做以下:
NameNode会从fs.checkpoint.dir目录读取检查点, 并把它保存在“dfs.name.dir”目录下。若是dfs.name.dir目录下有合法的fsimage,NameNode会启动失败。NameNode会检查“fs.checkpoint.dir”目录下镜像文件的一致性,可是不会去改动它。
相信信息,请查看 namenode
HDFS数据可能不会均匀地分布在各个Datanode上。一个常见的缘由是一个新的Datanode加入到已经存在的集群中。当须要给新的块选择位置,Namenode在选择哪些Datanode来存放前会考虑多个因素:
因为上述多种考虑须要取舍,数据可能并不会均匀分布在DataNode中。HDFS为管理员提供了一个工具,用于分析数据块分布和从新平衡DataNode上的数据分布。HADOOP-1652 的附件中的一个PDF是一个简要的rebalancer管理员指南。
详细信息,请查看 balancer