本文档是为使用Hadoop分布式文件系统(HDFS)的用户提供的入门指南,无论HDFS是作为Hadoop集群的一部分还是作为独立的通用分布式文件系统。虽然HDFS设计为能在多种环境中"开箱即用",但掌握HDFS的实用知识将极大地帮助您针对特定集群进行配置优化和故障诊断。
HDFS是Hadoop应用程序使用的主要分布式存储系统。一个HDFS集群主要由管理文件系统元数据的NameNode和存储实际数据的DataNodes组成。《HDFS架构指南》详细描述了HDFS。本用户指南主要介绍用户和管理员与HDFS集群的交互操作。HDFS架构图展示了NameNode、DataNodes和客户端之间的基本交互流程。客户端会联系NameNode获取文件元数据或进行文件修改,并直接与DataNodes执行实际的文件I/O操作。
以下是一些可能对许多用户感兴趣的重要特性。
Hadoop(包括HDFS)非常适合使用商用硬件进行分布式存储和分布式处理。它具有容错性、可扩展性,并且扩展极其简单。MapReduce以其简单性和对大量分布式应用的适用性而闻名,是Hadoop不可或缺的组成部分。
HDFS具有高度可配置性,其默认配置非常适合许多安装环境。大多数情况下,仅需针对超大规模集群进行配置调优。
Hadoop采用Java编写,支持所有主流平台。
Hadoop支持类似shell的命令来直接与HDFS交互。
NameNode和Datanode内置了Web服务器,便于检查集群的当前状态。
HDFS 中会定期实现新功能和改进。以下是 HDFS 中一些实用功能的子集:
文件权限和认证。
机架感知:在调度任务和分配存储时考虑节点的物理位置。
安全模式:一种用于维护的管理模式。
fsck
: 一个用于诊断文件系统健康状况的工具,可查找缺失的文件或数据块。
fetchdt
: 一个用于获取委托令牌并将其存储在本地系统文件中的实用工具。
Balancer: 当数据在DataNodes之间分布不均时用于平衡集群的工具。
升级与回滚:软件升级后,若出现意外问题,可回滚至升级前的HDFS状态。
Secondary NameNode: 执行命名空间的定期检查点,并帮助将包含HDFS修改日志的文件大小控制在NameNode的特定限制内。
检查点节点:定期对命名空间执行检查点操作,有助于最小化存储在NameNode中的HDFS变更日志的大小。它取代了之前由Secondary NameNode承担的角色,尽管目前尚未经过充分实战检验。只要系统中没有注册备份节点,NameNode允许同时存在多个检查点节点。
备份节点:检查点节点的扩展功能。除了执行检查点操作外,它还会从NameNode接收编辑日志流,并在内存中维护自己的命名空间副本,该副本始终与活跃NameNode的命名空间状态保持同步。同一时间只能有一个备份节点在NameNode上注册。
以下文档描述了如何安装和设置Hadoop集群:
本文档的其余部分假设用户能够设置并运行至少包含一个DataNode的HDFS。出于本文档的目的,NameNode和DataNode可以运行在同一台物理机器上。
NameNode和DataNode各自运行一个内部Web服务器,用于显示集群当前状态的基本信息。在默认配置下,NameNode的前端页面位于http://namenode-name:9870/
。它会列出集群中的DataNodes以及集群的基本统计信息。该Web界面还可用于浏览文件系统(通过NameNode前端页面上的"浏览文件系统"链接)。
Hadoop包含多种类似shell的命令,可直接与HDFS及Hadoop支持的其他文件系统交互。命令bin/hdfs dfs -help
会列出Hadoop shell支持的所有命令。此外,bin/hdfs dfs -help command-name
命令可显示某个命令的更详细帮助信息。这些命令支持大多数常规文件系统操作,如复制文件、更改文件权限等。同时还支持一些HDFS特有的操作,例如更改文件副本数。更多信息请参阅File System Shell Guide。
bin/hdfs dfsadmin
命令支持一些与HDFS管理相关的操作。bin/hdfs dfsadmin -help
命令会列出当前支持的所有命令。例如:
-report
: 报告HDFS的基本统计信息。部分信息也可在NameNode前端页面查看。
-safemode
: 虽然通常不需要,但管理员可以手动进入或离开安全模式。
-finalizeUpgrade
: 移除上次升级期间创建的集群备份。
-refreshNodes
: 更新允许连接到名称节点的数据节点集合。默认情况下,名称节点会重新读取dfs.hosts
和dfs.hosts.exclude
文件中定义的数据节点主机名。dfs.hosts
中定义的主机是集群组成部分的数据节点。如果dfs.hosts
中有条目,则只允许其中的主机向名称节点注册。dfs.hosts.exclude
中的条目是需要退役的数据节点。或者,如果将dfs.namenode.hosts.provider.classname
设置为org.apache.hadoop.hdfs.server.blockmanagement.CombinedHostFileManager
,则所有包含和排除的主机都在dfs.hosts
定义的JSON文件中指定。当所有副本从这些节点复制到其他数据节点时,数据节点完成退役。退役节点不会自动关闭,也不会被选择用于写入新副本。
-printTopology
: 打印集群的拓扑结构。显示由NameNode视角看到的机架和数据节点构成的树状结构。
有关命令用法,请参阅dfsadmin。
NameNode将对文件系统的修改以日志形式追加到本地文件系统文件edits中。当NameNode启动时,它会从镜像文件fsimage读取HDFS状态,然后应用edits日志文件中的修改。接着将新的HDFS状态写入fsimage,并开始正常操作,此时edits文件为空。由于NameNode仅在启动时合并fsimage和edits文件,在繁忙的集群上,edits日志文件可能会随时间变得非常大。edits文件过大的另一个副作用是导致NameNode下次重启耗时更长。
Secondary NameNode会定期合并fsimage和edits日志文件,并将edits日志大小控制在限定范围内。由于其对内存的需求与主NameNode处于同一量级,因此通常运行在与主NameNode不同的机器上。
在次要NameNode上启动检查点进程由两个配置参数控制。
dfs.namenode.checkpoint.period
,默认设置为1小时,指定两次连续检查点之间的最大延迟时间,以及
dfs.namenode.checkpoint.txns
,默认设置为100万,定义了NameNode上未检查点的事务数量,该数量将强制触发紧急检查点,即使尚未达到检查点周期。
辅助NameNode将最新的检查点存储在一个目录中,该目录的结构与主NameNode的目录结构相同。这样,检查点镜像在必要时随时可供主NameNode读取。
有关命令用法,请参阅secondarynamenode。
NameNode通过两个文件持久化其命名空间:fsimage(命名空间的最新检查点)和edits(自检查点以来命名空间变更的日志)。当NameNode启动时,它会合并fsimage和edits日志以提供文件系统元数据的最新视图。随后,NameNode会用新的HDFS状态覆盖fsimage,并开始一个新的edits日志。
检查点节点会定期创建命名空间的检查点。它从活跃的NameNode下载fsimage和edits文件,在本地合并它们,然后将新镜像上传回活跃的NameNode。由于检查点节点的内存需求与NameNode处于同一量级,因此它通常运行在与NameNode不同的机器上。检查点节点通过在配置文件中指定的节点上运行bin/hdfs namenode -checkpoint命令来启动。
Checkpoint(或备份)节点的位置及其配套的Web界面通过dfs.namenode.backup.address
和dfs.namenode.backup.http-address
配置变量进行设置。
检查点节点上检查点流程的启动由两个配置参数控制。
dfs.namenode.checkpoint.period
,默认设置为1小时,指定两次连续检查点之间的最大延迟
dfs.namenode.checkpoint.txns
,默认设置为100万,定义了NameNode上未检查点的事务数量,该数量将强制触发紧急检查点,即使尚未达到检查点周期。
Checkpoint节点将最新的检查点存储在与NameNode目录结构相同的目录中。这使得NameNode在必要时可以随时读取检查点镜像。请参阅导入检查点。
可以在集群配置文件中指定多个检查点节点。
有关命令用法,请参阅namenode。
备份节点(Backup node)提供与检查点节点(Checkpoint node)相同的检查点功能,同时维护一个内存中的、与活跃NameNode状态始终保持同步的最新文件系统命名空间副本。除了接收来自NameNode的文件系统编辑日志流并将其持久化到磁盘外,备份节点还会将这些编辑应用到其内存中的命名空间副本,从而创建命名空间的备份。
备份节点不需要像检查点节点或辅助名称节点那样从活动名称节点下载fsimage和编辑文件来创建检查点,因为它已经在内存中拥有命名空间状态的最新状态。备份节点的检查点过程更加高效,因为它只需要将命名空间保存到本地fsimage文件中并重置编辑日志。
由于备份节点在内存中维护命名空间的副本,其内存需求与NameNode相同。
NameNode一次仅支持一个备份节点。如果正在使用备份节点,则不能注册任何检查点节点。未来将支持同时使用多个备份节点。
备份节点的配置方式与检查点节点相同。启动时使用bin/hdfs namenode -backup
命令。
Backup(或Checkpoint)节点的位置及其配套的Web界面通过dfs.namenode.backup.address
和dfs.namenode.backup.http-address
配置变量进行设置。
使用备份节点(Backup node)提供了在不使用持久存储的情况下运行NameNode的选项,将所有持久化命名空间状态的责任委托给备份节点。为此,在启动NameNode时需使用-importCheckpoint
选项,同时不在NameNode配置中指定edits类型的持久存储目录dfs.namenode.edits.dir
。
有关创建备份节点和检查点节点背后动机的完整讨论,请参阅HADOOP-4539。有关命令用法,请参阅namenode。
如果镜像和编辑文件的所有其他副本都丢失了,可以将最新的检查点导入到NameNode。为此,应执行以下操作:
在配置变量dfs.namenode.name.dir
中指定的位置创建一个空目录;
在配置变量dfs.namenode.checkpoint.dir
中指定检查点目录的位置;
并使用-importCheckpoint
选项启动NameNode。
NameNode将从dfs.namenode.checkpoint.dir
目录上传检查点,然后将其保存到dfs.namenode.name.dir
中设置的NameNode目录。如果dfs.namenode.name.dir
中包含合法镜像,NameNode将失败。NameNode会验证dfs.namenode.checkpoint.dir
中的镜像是否一致,但不会以任何方式修改它。
有关命令用法,请参阅namenode。
HDFS数据可能不会总是均匀分布在各个DataNode上。一个常见原因是向现有集群添加新的DataNode。在放置新块(文件数据以一系列块的形式存储)时,NameNode在选择接收这些块的DataNode之前会考虑各种参数。其中一些考虑因素包括:
策略是将块的其中一个副本保留在与写入该块的节点相同的节点上。
需要将块的不同副本分布在不同的机架上,这样集群才能在整机架故障时存活下来。
其中一个副本通常会被放置在与写入文件的节点相同的机架上,以减少跨机架网络I/O。
将HDFS数据均匀分布在集群中的各个DataNode上。
由于存在多种相互竞争的考量因素,数据可能无法均匀分布在各个DataNode上。HDFS为管理员提供了一个工具,用于分析块分布情况并在DataNode之间重新平衡数据。关于平衡器的简要管理员指南可在HADOOP-1652查阅。
Balancer支持两种模式:作为工具运行或作为长期运行的服务运行:
在工具模式下,它将尽力平衡集群,并在以下情况下退出:
所有集群均处于平衡状态。
多次迭代后仍未移动任何字节(默认值为5次)。
无法移动任何数据块。
集群正在升级中。
其他错误。
在服务模式下,balancer将作为长期运行的守护进程服务运行。其工作原理如下:
对于每一轮,它将尝试平衡集群直到成功或在出错时返回。
您可以配置每轮之间的间隔时间,该间隔由dfs.balancer.service.interval
设置。
当遇到意外异常时,它会尝试多次后才停止服务,重试次数由dfs.balancer.service.retries.on.exception
参数设置。
有关命令用法,请参阅balancer。
一个HDFS集群可以识别放置各个节点的机架拓扑结构。配置此拓扑结构对于优化数据容量和使用非常重要。更多详情,请查阅通用文档中的rack awareness。
在启动过程中,NameNode会从fsimage和编辑日志文件加载文件系统状态。随后它会等待DataNode上报其数据块信息,以避免在集群中已存在足够副本的情况下过早开始复制块数据。在此期间,NameNode将保持安全模式。NameNode的安全模式本质上是HDFS集群的只读模式,此时不允许对文件系统或数据块进行任何修改。通常情况下,当DataNode报告大多数文件系统块可用后,NameNode会自动退出安全模式。如果需要,可以使用bin/hdfs dfsadmin -safemode
命令显式地将HDFS置于安全模式。NameNode前端页面会显示安全模式是否开启。更详细的说明和配置可参阅setSafeMode()
的JavaDoc文档。
HDFS supports the fsck command to check for various inconsistencies. It is designed for reporting problems with various files, for example, missing blocks for a file or under-replicated blocks. Unlike a traditional fsck utility for native file systems, this command does not correct the errors it detects. Normally NameNode automatically corrects most of the recoverable failures. By default fsck ignores open files but provides an option to select all files during reporting. The HDFS fsck command is not a Hadoop shell command. It can be run as bin/hdfs fsck
. For command usage, see fsck. fsck can be run on the whole file system or on a subset of files.
HDFS支持fetchdt命令来获取委托令牌并将其存储在本地系统的文件中。该令牌后续可用于从非安全客户端访问安全服务器(例如NameNode)。该工具使用RPC或HTTPS(基于Kerberos)来获取令牌,因此需要在运行前存在Kerberos票据(运行kinit获取票据)。HDFS fetchdt命令不是Hadoop shell命令。可以运行bin/hdfs fetchdt DTfile
来执行。获取令牌后,通过将环境变量HADOOP_TOKEN_FILE_LOCATION
指向委托令牌文件,即可在没有Kerberos票据的情况下运行HDFS命令。有关命令用法,请参阅fetchdt命令。
通常,您需要配置多个元数据存储位置。这样,如果某个存储位置损坏,您可以从其他存储位置之一读取元数据。
然而,如果可用的存储位置都已损坏,您该怎么办?在这种情况下,有一种特殊的NameNode启动模式称为恢复模式,可能允许您恢复大部分数据。
你可以按如下方式以恢复模式启动NameNode: namenode -recover
在恢复模式下,NameNode会在命令行交互式提示您可能采取的数据恢复操作方案。
如果不希望被提示,可以使用-force
选项。该选项将强制恢复模式始终选择第一个选项。通常情况下,这将是最合理的选择。
由于恢复模式可能导致数据丢失,在使用前应始终备份编辑日志和fsimage。
在现有集群上升级Hadoop时,与任何软件升级一样,可能存在新错误或不兼容变更影响现有应用程序,而这些问题是之前未被发现的。对于任何重要的HDFS部署而言,丢失数据都是不可接受的选项,更不用说从零开始重启HDFS。HDFS允许管理员回退到早期版本的Hadoop,并将集群回滚至升级前的状态。关于HDFS升级的更多细节详见Hadoop Upgrade维基页面。HDFS一次只能保留一个此类备份。升级前,管理员需要使用bin/hadoop dfsadmin -finalizeUpgrade
命令移除现有备份。以下简要描述典型的升级流程:
在升级Hadoop软件之前,请确认是否已存在备份。
停止集群并分发新版本的Hadoop。
使用-upgrade
选项运行新版本(sbin/start-dfs.sh -upgrade
)。
大多数情况下,集群运行良好。当新HDFS被认为运行稳定后(可能需要运行数天),即可完成升级。请注意,在集群完成最终确认前,删除升级前存在的文件并不会真正释放DataNodes上的磁盘空间。
如果需要回退到旧版本,
停止集群并分发早期版本的Hadoop。
在namenode上运行回滚命令 (bin/hdfs namenode -rollback
)。
使用回滚选项启动集群。(sbin/start-dfs.sh -rollback
).
升级到新版本的HDFS时,必须重命名或删除新版本HDFS中保留的所有路径。如果NameNode在升级过程中遇到保留路径,它将打印如下错误:
/.reserved 是当前版本 HDFS 中的保留路径,.snapshot 是保留路径组件。请回滚并删除或重命名该路径,或者在升级时使用 -renameReserved [键值对] 选项来自动在升级过程中重命名这些路径。
指定-upgrade -renameReserved [可选键值对]
会使NameNode在启动时自动重命名所有保留路径。例如,要将所有名为.snapshot
的路径重命名为.my-snapshot
,以及将.reserved
重命名为.my-reserved
,用户应指定-upgrade -renameReserved .snapshot=.my-snapshot,.reserved=.my-reserved
。
如果未使用-renameReserved
指定键值对,NameNode将为保留路径添加.
后缀,例如.snapshot.-51.UPGRADE_RENAMED
。
这个重命名过程有一些注意事项。如果可能的话,建议在升级前先执行hdfs dfsadmin -saveNamespace
。这是因为如果编辑日志操作引用了自动重命名文件的目标位置,可能会导致数据不一致。
Datanode支持热插拔驱动器。用户无需关闭DataNode即可添加或替换HDFS数据卷。以下简要描述典型的热插拔驱动器流程:
如果有新的存储目录,用户应对其进行格式化并正确挂载。
用户更新DataNode配置dfs.datanode.data.dir
以反映将要活跃使用的数据卷目录。
用户运行dfsadmin -reconfig datanode HOST:PORT start
来启动重新配置过程。用户可以使用dfsadmin -reconfig datanode HOST:PORT status
查询重新配置任务的运行状态。除了HOST:PORT外,我们还可以为datanode指定livenodes。这将允许在所有存活的datanode上启动或查询重新配置,而指定HOST:PORT则只允许在由HOST:PORT表示的特定datanode上启动或查询重新配置。livenodes查询的示例是dfsadmin -reconfig datanode livenodes start
和dfsadmin -reconfig datanode livenodes status
。
重新配置任务完成后,用户可以安全地umount
已移除的数据卷目录并物理移除磁盘。
文件权限的设计类似于Linux等其他常见平台上的文件权限。目前,安全性仅限于简单的文件权限。启动NameNode的用户被视为HDFS的超级用户。未来版本的HDFS将支持Kerberos等网络认证协议,用于用户身份验证和数据传输加密。具体细节请参阅《权限指南》。
Hadoop目前可在数千个节点组成的集群上运行。PoweredBy维基页面列出了部分在大型集群中部署Hadoop的组织机构。每个HDFS集群配置一个NameNode。当前NameNode的可用内存总量是主要扩展性限制因素。在超大规模集群中,增加HDFS存储文件的平均大小有助于在不增加NameNode内存需求的情况下扩展集群规模。默认配置可能不适用于超大规模集群。FAQ维基页面列出了针对大型Hadoop集群的配置优化建议。
本用户指南是开始使用HDFS的良好起点。虽然用户指南在不断改进,但关于Hadoop和HDFS已有大量丰富的文档资料。以下列表可作为进一步探索的起点: