云计算（六）-HDFS 用户手册（Hadoop2.2）

最新推荐文章于 2022-11-09 23:34:25 发布

duheaven

最新推荐文章于 2022-11-09 23:34:25 发布

阅读量1.9k

点赞数

分类专栏：云计算文章标签： hadoop 云计算 HDFS 用户手册

云计算专栏收录该内容

32 篇文章 1 订阅

订阅专栏

HDFS Users Guide

这篇文章作为工作在Hadoop分布式文件系统(HDFS)，无论是作为Hadoop集群的一部分还是作为一个独立的通用的分布式文件系统的用户的一个起点。HDFS设计用来在多种环境中轻松的使用，HDFS的工作知识非常有助于对一个特定集群配置的提升和诊断工作。

综述

HDFS是Hadoop应用程序所使用的主要分布式存储。一个HDFS集群主要有管理文件系统元数据的NameNode和存储真正数据的DataNode组成，HDFS的架构指南详细的描述了HDFS。用户手册主要涉及用户和管理员与HDFS集群的相互作用。HDFS的架构图描述了NameNode,DataNode,Clinets之间的基础交互。Clinets连接到Namenode提供文件元数据和文件修改，并且直接与Datanode完成文件I/O操作。

下边是一些许多用户感兴趣的显著特征：

Hadoop包括HDFS,非常适合使用普通硬件进行分布式存储和分布式处理，其具有高容错性，稳定性，并且非常容易扩展。Mapreduce以大型分布式应用程序设置的简单性和适用性而出名，其是Hadoop的一部分。
HDFS默认配置的高可配置性适合多种环境安装。大多数时候，只有非常大的集群才需要调整配置。
Hadoop由java语言编写，并且被大多数平台支持。
Hadoop支持类似shell的命令与HDFS进行交互
NameNode和DataNode都集成在web服务器中，可以很容易的检测当前集群的状态。
HDFS会定期的新增功能和改进. 以下是HDFS有用的一部分：
- 文件权限和身份认证。
- 机架感知：调度任务和分配存储时候考虑物理节点的位置。
- 安全模式：维护管理模式。
- fsck: 一个用来检测文件系统健康的工具，找到丢失的文件和区块。
- fetchdt: 一个用例获取 DelegationToken 的工具，并将其存在本地文件系统中。
- 重分配: 当数据在Datanode中被不平衡的分配时平衡分配到集群的工具。
- 升级和回滚:在意想不到的问题发生时可以回滚到升级之前的状态。
- Secondary NameNode:周期性的检查命名空间,有助于保持在Namenode上的修改的HDFS日志文件的大小在一定范围内。
- Checkpoint node:定期的检查命名空间以助于缩小在Namenode上的包含HDFS变动的日志文件的大小。
- Backup node: checkpoint的扩展. 除了checkpointing其还可以接受Namenode来的可编辑的数据流并且在内存中维护一份属于自己的namespace, 并且和激活的Namesapce的状态保持同步，只有Backup节点可以和namespace同时注册。

必备条件

以下文档描述了如何安装和配置Hadoop集群:

Single Node Setup 第一次使用的用户.
Cluster Setup 大规模分布式用户.

这篇文档其余部分假设读者可以至少在一个节点配置和运行HDFS.达到本文档的目的，NameNode和DataNode可以运行在同一台物理机器上。

Web接口

NameNode和DataNode各自运行一个内部web服务器以现实当前集群状态的基本信息.默认配置下, Namenode的访问页面 http://namenode-name:50070/ . 其列出了集群中的DataNode和集群的基本统计. Web接口也可以用与浏览文件系统(用 "文件浏览" 链接在Namenode的首页.

Shell 命令

Hadoop包含丰富的类似Shell的命令用来直接与HDFS及其他Hadoop支持的文件系统进行交互。命令 bin/hdfs dfs -help 列出了Hadoopshell支持的命令. 并且, 命令 bin/hdfs dfs -help command-name 显示命令的更多详细信息. 这些命令支持大多数的文件系统操作，像复制文件，改变权限，等等。它还支持一些HDFS的特有命令如文件的更改复制。更多的信息请参阅：.

DFSAdmin Command

The bin/hadoop dfsadmin 支持一些HDFS的相关管理操作。bin/hadoop dfsadmin -help 列出了目前所有支持的命令如下:

-report: 报告HDFS的基础数据统计，其中的一些信息在Namenode的首页也可以现实。
-safemode: 尽管不常用，但是管理员可以用来管理进入和离开的安全级别。
-finalizeUpgrade：移除在最后一次升级中的集群备份。
-refreshNodes: 更新Namenode允许Datanodes链接到Namenode. Namenode重新读取定义在dfs.hosts, dfs.hosts.exclude Datanode的主机名称.定义在 dfs.hosts中的主机是作为集群一部分的Datanodes. 如果有条目在 dfs.hosts中,只有其中列出的主机才允许注册Namenode。dfs.hosts.exclude中的条目 中定义需要退役的Datanodes.。 Datnodes完全退役是在它的所有副本都复制到其他datanodes时候。退役的节点不会自动关机并且不允许选择写入新副本.
-printTopology :输出集群的拓扑.现实一个机架树和datanodes关联的以Namenode作为的trackes（这句话还是看原版吧）。

更多的命令使用请参考 .

Secondary NameNode

Namenode存储文件系统的西修改作为日志添加在本地文件系统。当一个Namenode启动, 它从镜像对去HDFS的状态, fsimage,然后从编辑日志文件编辑. 然后它向fsimage写入HDFS的新状态，并且对空的可编辑文件进行操作。Namenode只有在启动时候合并fsimage和edits files，在一个繁忙的集群中日志文件会随着时间变得非常大。大的日志文件另一方面的影响是下次重启Namenode需要更长的时间。

Secondary Namenode 定期合并fsimage和日志文件并保持其大小在一定范围内。它经常运行于与primary NameNode不同的机器上，由于它的内存需要和primary Node具有相同的顺序。

在secondary namenode上的checkpoint进程启动由两个配置控制：

dfs.namenode.checkpoint.period, 默认设在1小时, 指定两个相邻checkpoint的最大延迟。
dfs.namenode.checkpoint.txns, 默认设置1000000 ，定义为在NameNode 没有进行checkpoint的事物的数量，即使checkpoint period 没有达到也会进行紧急的checkpoint

Secondary Namenode把最后的checkpoints存入字典和primary Namenode具有相同的组织形式。所以如果需要的话checkpointed image随时都可被primary Namenode读取。

更多用法请参考。

Checkpoint Node

Namenode用两个文件保存其配置: fsimage,namespace的最后一个checkpoint，记录从checkpoint开始的namespce的变化的日志。当一个NameNode启动，它合并fsimage和edits日志用来提供一个文件系统元数据的最新视图。Namenode之后以HDFS的状态重写fsimage并且开始新的日志记录。

Checkpoint 定时的为namespace创建检查点。它从正在激活的NameNode下载fsimage和编辑日志，在本地合并他们，并且上传新的image到正在激活的Namenode。CheckPoint通常和Namenode运行在不同的主机上因为它的内存要求和Namenode具有相同的顺序。Checkpoint由配置文件中指定的bin/hdfs namenode -checkpoint开始。

Checkpoint (or Backup)节点的位置和随同的Web借口通过配置 dfs.namenode.backup.address 和 dfs.namenode.backup.实现，http-address 配置变量。

Checkpoint 节点上的checkpoint启动由一下两个配置参数控制：

dfs.namenode.checkpoint.period, 默认设在1小时, 指定两个相邻checkpoint的最大延迟。

dfs.namenode.checkpoint.txns, 默认设置1000000 ，定义为在NameNode 没有进行checkpoint的事物的数量，即使checkpoint period 没有达到也会进行紧急的checkpoint

Checkpoint节点采取和Namenode的字典相同的组织方式把最后的checkpoint存储进字典。这样checkpointed image就可以随时被Namenode所读取了。参考checkpoint的重要。

多数的checkpoint 节点要在集群配置文件中指定。

注（为了方便理解，非原文档）：

Checkpoint Node和Secondary NameNode的作用以及配置完全相同，可能是由于Secondary NameNode这个名字给人带来的混淆，Hadoop后面的版本（1.0.4 ）建议不要使用Secondary NameNode，而使用CheckPoint Node。

fsimage：文件系统元数据的一个永久性检查点，包含文件系统中的所有目录和文件idnode的序列化信息。

edits：文件系统的写操作首先把它记录在edit中

hadoop将文件系统个元数据操作分开操作，是为了提升处理效率。如果不分开处理，即所有的写操作均记录在一个文件中，比如，fsimage中，那么每个操作都会对这个文件进行修改，因为这个文件可能会很大，所以每次进行写操作的时候就会很慢，随着fsimage越来越大，速度便会越来越低。

Hadoop的解决方案是辅助Namenode节点，文件系统的写操作不是直接被修改到fsimage中，二是edits中，辅助Namenode节点负责将两者在自己的内存中整合然后进行相应的替换操作，这样会频繁的对edits进行修改而不是fsimage，而edits文件的大小是可以接受的，而且大小也不会不断增加。具体的checkpoint执行过程如下：

以下即是checkpoint过程：

辅助Namenode请求主Namenode停止使用edits文件，暂时将新的写操作记录到一个新文件中，如edits.new。
辅助Namenode节点从主Namenode节点获取fsimage和edits文件（采用HTTP GET）
辅助Namenode将fsimage文件载入到内存，逐一执行edits文件中的操作，创建新的fsimage文件
辅助Namenode将新的fsimage文件发送回主Namenode（使用HTTP POST）
主Namenode节点将从辅助Namenode节点接收的fsimage文件替换旧的fsimage文件，用步骤1产生的edits.new文件替换旧的edits文件（即改名）。同时更新fstime文件来记录检查点执行的时间

Backup Node

Backup 节点提供和Checkpoint节点一样的检测功能，同样维护一个与激活的NameNode同步的在内存中，时时更新的命名空间文件系统。 Backup节点提供和checkpoint节点一样的功能，同样维护一个内存中的，时时的与激活状态的Namenode状态一致的命名空间的文件副本。随着从Namenode接受一个可编辑的文件日志并持久化到硬盘，Backup节点同样适用于这些这些命名空间在内存中的拷贝，创建一个命名空间的备份。

Backup节点不需要为了创建checkpoint从激活的Namenode下载fsimage和edits，而Checkpont节点和Secondary NameNode需要是需要的，因为它已经有一个在内存中时时的命名空间的状态。Backup节点的进程更高效，因为它只需要把命名空间存储到本地的fsimage和重至edits。

Backup节点在内存中维护一个命名空间的副本，它的RAM要求和Namenode一致。

NameNode一次只支持一个Backup节点，Checkpoint节点不允许注册如果Backup节点在使用。使用多个Backup节点会在不久的将来进行支持。

Backup节点和Checkpont节点在同一个管理器，用 bin/hdfs namenode -backup启动。

Backup节点的位置和web借口通过dfs.namenode.backup.address和dfs.namenode.backup.http-address配置。

Backup节点提供了选项支持运行Namenode节点不持久化到硬盘，代理所有的命名空间持久化状态的请求到Backup节点。为了做到这样，启动Namenode和命令 -importCheckpoint 选项，随着指定没有持久化存储目录通过dfs.namenode.edits.dir f配置。

更全面的讨论Backup节点和Checkpont节点背后的机制，请参考 HADOOP-4539. 更多资料请参考。

同时可以参考http://share.blog.51cto.com/278008/1033994

Import Checkpoint

如果其他备份的image和edits文件丢失，可以导入最新的checkpoint到NameNode ，我们可以这么做：

建立一个 dfs.namenode.name.dir 配置所指定的文件夹

在配置文件中设定dfs.namenode.checkpoint.dir到一个特殊的文件夹

启动NameNode使用 -importCheckpoint选项

NameNode 会上传checkpoint从dfs.namenode.checkpoint.dir所指定的目录，并保存到 dfs.namenode.name.dir所指定的目录，如果已经有一个image在dfs.namenode.name.dir目录下，那么NameNode将会失败，NameNode会验证dfs.namenode.checkpoint.dir NameNode的image的一致性,但不以任何方式修改它

Rebalancer

HDFS中的数据在各个DataNode之间并不总是一致的，一个常见的原因就是添加一些新的DataNode到集群里面，当安置一些新的块（数据文件通常是以一些块的形式储存的），NameNode可以通过一些参数选择DataNodes去接受这些块，具体如下：

正在写该Block的数据节点会保留一份该Block
要把该Block分散到不同机架，达到容灾需求
将Block存一份到与正在写该Block所属文件的节点同机架的节点，以减少机架间的网络传输
HDFS数据在集群中平均分配

基于很多权衡考虑，数据在DataNodes间可能不是平均分配。HDFS提供一个分析Block位置和在节点间均衡数据的管理工具。Rebalancer的简要介绍在HADOOP-1652的一个PDF中。

Rack Awareness(机架感知)

大型的hadoop集群会安排在同一个机架上的的不同node的交互多余分布在不同机架上的交互。另外NameNode会放置一些block在不同的机架上用于容错，管理员可以通过配置变量net.topology.script.file.name来决定哪个机架的节点，当这个脚本被配置之后，每个节点都会运行这个脚本确定它对应的机架id，默认的安装会假设所用的node在一个机架上。这个功能和描述可以参考HADOOP-692中的PDF。

注（非原文档）：可以参考以下链接：

http://blog.csdn.net/hjwang1/article/details/6592714

Safemode

当NameNode启动时会从fsimage和edits日志文件中加载文件系统的状态，并且等待DataNode报考block的情况，DataNode不会提早进行任何的复制操作，在此期间NameNode处于Safemode。Safemode对于NameNode来说是一个只读模式，他不允许任何的任何修改，一般当DataNode报告了大多数系统的block是活动状态后NameNode会自动离开Safemode，如有需要，HDFS 可以通过bin/hadoop dfsadmin -safemode命令启动Safemode，NameNode 的前端页面是否显示取决于Safemode是开还是关，更多的细节和配置请参考一个 setSafeMode()的API文档。

注（非原文档）：可以参考以下链接：

http://blog.csdn.net/hguisu/article/details/7261480

fsck

HDFS支持fsck命令用来检测系统的一致性，他被设计用来报告众多文件的问题，例如，一个文件缺少block或者存在的block低于备份块数。不同于传统的为了普通文件系统的工具，这个命令不会纠正发现的错误，一般来说NameNode 会自动的纠正大多数可以恢复的错误，默认的fsck会忽略打开的文件，但是提供了一个选项可以选择所有的文件。fsck 命令并不是一个hadoop shell 命令，他可以以bin/hadoop fsck的方式运行，他可以运行与整个文件系统或一堆文件上。

fetchdt

HDFS 支持fetchdt 命令用来获取代理令牌并保存到本地文件系统，这个令牌可以用来进入安全的服务器（比如Namenode）从一个不安全的客户端，一般利用RPC或者https（通过 Kerberos）在需要出示令牌之前去获得令牌。这个命令并不是一个hadoop shell 命令,他可以通过 bin/hadoop fetchdt DTfile的方式运行，如果在命令后没有加载任何的Kerberos纳闷会通过 HADOOP_TOKEN_FILE_LOCATION 这个配置去找令牌文件。

注：可以参考http://blog.csdn.net/nachuang/article/details/8729729

Recovery Mode

一般会配置多个元数据的位置如果一个被毁坏，可以从其他位置上读取，但是如果仅有的一个活动的位置被损坏了呢，在这个case里面就需要一个特殊的NameNode启动方式，叫做Recovery mode这种模式能使你恢复大部分数据。

你可以以recovery mode的方式启动Namenode像这样：namenode -recover

在恢复模式下,NameNode将在命令行交互提示您可能采取的行动,帮助恢复你的数据。

如果你不想被提示,你可以给- force选项。这个选项将迫使恢复模式总是选择第一个选择。通常情况下,这将是最合理的选择。

因为恢复模式可以让你丢失数据,您应该备份你的编辑日志和fsimage之前使用它。

Upgrade and Rollback

当在一个已有集群上升级Hadoop时，像其他的软件升级一样，可能会有新的bug或一些会影响到现有应用的非兼容性变更出现。在任何有实际意义的HDSF系统上，丢失数据是不被允许的，更不用说重新搭建启动HDFS了。HDFS允许管理员退回到之前的Hadoop版本，并将集群的状态回滚到升级之前。更多关于HDFS升级的细节在升级wiki上可以找到。HDFS在一个时间可以有一个这样的备份。在升级之前，管理员需要用bin/hadoop dfsadmin -finalizeUpgrade（升级终结操作）命令删除存在的备份文件。下面简单介绍一下一般的升级过程：

升级 Hadoop 软件之前，请检查是否已经存在一个备份，如果存在，可执行升级终结操作删除这个备份。通过dfsadmin -upgradeProgress status命令能够知道是否需要对一个集群执行升级终结操作。
停止集群并部署新版本的Hadoop。
使用-upgrade选项运行新的版本（bin/start-dfs.sh -upgrade）。
在大多数情况下，集群都能够正常运行。一旦我们认为新的HDFS运行正常（也许经过几天的操作之后），就可以对之执行升级终结操作。注意，在对一个集群执行升级终结操作之前，删除那些升级前就已经存在的文件并不会真正地释放DataNodes上的磁盘空间。
如果需要退回到老版本，
- 停止集群并且部署老版本的Hadoop。
- 用回滚选项启动集群（bin/start-dfs.h -rollback）。

File Permissions and Security

这里的文件权限和其他常见平台如Linux的文件权限类似。目前，安全性仅限于简单的文件权限。启动NameNode的用户被视为HDFS的超级用户。HDFS以后的版本将会支持网络验证协议（比如Kerberos）来对用户身份进行验证和对数据进行加密传输。具体的细节请参考权限使用管理指南。

Scalability

现在，Hadoop已经运行在上千个节点的集群上。Powered By Hadoop页面列出了一些已将Hadoop部署在他们的大型集群上的组织。HDFS集群只有一个NameNode节点。目前，NameNode上可用内存大小是一个主要的扩展限制。在超大型的集群中，增大HDFS存储文件的平均大小能够增大集群的规模，而不需要增加NameNode的内存。默认配置也许并不适合超大规模的集群。Hadoop FAQ页面列举了针对大型Hadoop集群的配置改进。