本文是官方文档的翻译 本文固定链接是：https://www.askmac.cn/archives/hadoop-hdfs-user-guide.html
原文链接：http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
1.目的
这个文档的出发点是为了那些使用HDFS的用户，不管是集群环境或者是作为独立的通用分布式文件系统。当在许多环境中使用HDFS时，HDFS的工作知识帮助对一个特定的群集上的配置进行改进和诊断
2.综述：
HDFS是Hadoop应用程序使用的主要分布式存储。一个HDFS集群只要包括一个NameNode 来管理文件系统的元数据，dataNode来存储实际数据。HDFS构架指导详细的描述了HDFS。这个用户指导主要用于处理HDFS集群中的用户和管理者的交互。HDFS构架图标描述了NameNode，DataNode和客户端之间的基本交互。客户端为了文件远数据或者修改文件描述而联系nameNode，直接通过DataNode来执行实际的文件I/O。
下面的一些特征，很多用户可能会感兴趣。
- Hadoop,包括HDFS，非常适用于使用标准硬件来进行分布式存储和分布式处理。它是容错的，可扩展的，并且扩展非常简单。分布式计算（MapReduce），众所周知，它非常简单的适用于大型分布式应用程序，它是hadoop的一个组成部分。
- HDFS是高度可配置的，作为默认的配置对于很多安装来说是非常合适的。大多数时候，仅仅对于大型集群需要对配置进行调整。
- Hadoop是JAVA写的，支持所有的平台。
- Hadoop支持类型shell的命令来直接和HDFS进行交互。
- NameNode和Datanode内置web服务器，这样便于检查集群当前状态。
- 在HDFS中会定期的实施新特性和改进。以下是HDFS的一个有用功能的子集：
.文件权限和验证。
. 构架意识（rack awareness）：在调度任务和分配存储时，将节点的物理位置考虑在内。
.安全模块（safemode）：一个维护的管理模块。
.fsck:一个诊断文件系统健康的工具，用来找出丢失的文件或块。
.fetchd：一个获得Delegation token的工具，并且存储到本地文件系统的一个文件中。
.平衡（blancer）:当DataNodes中的数据是不均衡分布时，一个平衡集群的工具。
.第二个 NameNode（secondary namenode）：执行定期的命名空间检查点,并且在NameNode中，有助于保持HDFS修改日志文件大小在一定限额内。
.检查点节点(checkpoint node): 执行定期的命名空间检查点，并且在NameNode中，有助于保持HDFS修改日志的最小的大小。以往这个角色由secondary namenode所替代，虽然它还没有被增强。NameNode允许同时多个检查点节点，只要没有备份的节点注册到系统中。
.备份节点（backup node）：检查点节点的延伸。除此之外，它也从NameNode接受编辑流，并且维护自己再命名空间的内存副本，其总是与活跃的NameNode命名空间状态一致。只有一个备份节点可以与NameNode进行一次注册。
3.先决条件：
下面文档描述了如何安装和配置一个Hadoop集群：
- 第一次单节点安装。
- 为大型，分布式集群配置集群。
本文档其余部分假设用户已经配置和运行了一个HDFS，至少有一个DataNode。本文档的目标，NameNode和DataNode可以在相同的物理机上运行。
4.WEB接口
NameNode和DataNode 每个都在内部运行了WEB服务，用来显示集群现状的基本信息。在默认配置下，NameNode的首页是：http://namenode-name:50070.它列出了再集群中的数据节点和集群的基本情况。web接口也可以用于游览文件系统（在NameNode首页上使用 “Browse the file system” 链接）
5.shell 命令
Hadoop 包含类似于shell命令的命令，来直接让HDFS于那些hadoop支持的文件系统进行交互。bin/hdfs dfs -help命令列出了hadoop shell支持的命令。此外，bin/hdfs dfs -help command-name命令显示了更多关于命令的信息。这些命令支持一些和普通文件系统类似的命令，例如拷贝文件，更改文件权限等等。它也支持一些HDFS特定的操作，例如文件的变更复制。更多信息可以参见 文件系统shell指导。
5.1 DFSAdmin 命令
bin/hdfs dfsadmin命令支持一些管理员相关的操作。bin/hdfs dfsadmin -hel命令列出了当前所有支持的命令。例如：
- -report：打印HDFS基本的统计信息。一些信息也可以在NameNode 首页上看到。
- -safemode:虽然通常并不需要，管理员可以手动加载或卸载安全模块。
- -finalizeUpgrade: 删除上次集群升级过程中所做的备份。
- -refreshNode:在namenode上更新那些允许连接到namenode的datanodes。Namenodes 重新读取到在df.hosts中定义的dfs.hosts,dfs.hosts.exclude中的datanode主机名。如果配置了dfs.hosts，那么只有其中的主机允许注册到namenode。配置在dfs.hosts.exclude的那些datanodes是需要被剔除掉的。当datanode上的副本完全复制到其他datanode上时，节点才完全的被剔除。被剔除的节点不会自动的关闭，并且不会选择写入新的副本。
（用于剔除节点和再次加进集群）
- -printTopology:打印集群拓扑。显示一个树形构架，datanode会作为Namenode的一个视图添加到构架中。
（这个命令只会显示当前存在的拓扑，如果节点没注册到namenode，或者集群未启动 不会显示）
更多命令使用，可以参考hdfs命令指导
6.Secondary NameNode
NameNode存储了文件系统的修改，作为日志增加到本地文件系统中，编辑。当一个NameNode启动，它从一个镜像文件,fsimage中读取HDFS状态，然后应用编辑日志文件中的编辑（edits）。然后写入新HDFS状态到fsimage，在一个空的编辑文件中开始普通的操作。由于只有在启动的时候，nameNode才合并edits文件和fsimage，在一个繁忙的集群系统中edits日志文件可能会非常大。较大的edits文件的另一个副作用是在下次重启NameNode需要更长的时间。
secondary NameNode 合并fsimage和之前的edits日志文件，保持edits日志大小在一个限制内。它经常运行在另外的机器上，对比主NameNode 上的内存请求是和主NameNode上的顺序一样。
在secondary NameNode上启动检查点进程是由两个配置参数控制。
- dfs.namenode.checkpoint.period,默认设置是1小时，指定两个连续检查点的最大延时。
- dfs.namenode.checkpoint.txns,默认是1百万，定义了NameNode上未检查点事务的数量，将会强制进行紧急检查点，即使没达到检查点时间。
secondary NameNode 在一个和主NameNode中结构相同目录中存储了最近检查点。因此，如果必要的话，检查点镜像总是准备去从NameNode去读。
更多命令使用，可以参考hdfs命令指导
7.检查点节点（checkpoint Node）
NameNode 坚持它的命名空间使用两种文件：fsimage,是最近一次命名空间和edits的检查点，由于检查点，一个日志（log）的变化到命名空间。当一个NameNode启动时，它会合并fsimage和edits日志来为文件系统元数据提供一个最新的视图。NameNode然后使用新HDFS状态覆盖fsimage，然后开始一个新的edits日志。
检查点 节点定期地为命名空间创建检查点。它会从活动地NameNode上下载fsimage和edits，在本地合并他们，然后将新的image上传到活动地NameNode。检查点节点通常运行在不同的主机上，对比主NameNode 上的内存请求是和主NameNode上的顺序一样。在配置文件中指定的节点上，使用bin/hdfs namenode -checkpoint命令来启动检查点节点。
检查点（或者备份）节点，它们伴随的web接口的位置是通过,dfs.namenode.backup.address和dfs.name.backup.http-address的值来配置。
在检查点 节点上启动检查点进程是由两个配置参数控制。
- dfs.namenode.checkpoint.period,默认设置是1小时，指定两个连续检查点的最大延时。
- dfs.namenode.checkpoint.txns,默认是1百万，定义了NameNode上未检查点事务的数量，将会强制进行紧急检查点，即使没达到检查点时间。
checkpoint node 在一个和主NameNode中结构相同目录中存储了最近检查点。这使得检查点 镜像在需要的时候随时可以通过Namenode读取。参考 导入 检查点。
复合检查点 节点可以在集群配置中被定义。
更多命令使用，可以参考hdfs命令指导
8.备份节点（Backup Node）
备份节点提供了和检查点 节点一样的检查点功能，同时在内存中维护一个从活动NameNode 拷贝的副本，总是同步最新的文件系统副本。随着从NameNode接收文件系统的日志流和保持它们到磁盘，备份节点也应用这些edite，到自己内存里命名空间的副本中，这样就生成了一个命名空间的备份。
备份节点不需要为了创建一个检查点，而从活动地NameNode上下载fsimage和edits文件，作为一个检查点节点和secondary nameNode是需要的，因为它已经拥有了内存中的命名空间的最新状态。备份节点检查点进程更有效，只需要保存命名空间到本地fsimage文件和重置edites。
最为备份节点要在内存中维护一份命名空间的拷贝，它们的RAM（内存大小）需要和NameNode节点一样。
NameNode 在同一时间只支持一个备份节点。如果使用了一个备份节点，那么不能将检查点节点注册。同时使用多个备份节点将在未来被支持。
备份节点和检查点节点的配置一样。它使用bin/hdfs namenode -backup命令启动。
备份（或者检查点）节点，它们伴随的web接口的位置是通过,dfs.namenode.backup.address和dfs.name.backup.http-address的值来配置。
使用一个备份节点提供了选项在运行NameNode时，将非持久性存储，所有命名空间状态持久性的责任，抛给了备份节点。为了做这些，开启NameNode使用-importCheckPoint选项，同时在NameNode中，为edits类型设置非持久性存储目录 dfs.namenode.edits.dir
查看创建备份节点和检查点节点背后的动机，可以参考HADOOP-4539这个完全的讨论（https://issues.apache.org/jira/browse/HADOOP-4539）。
更多命令使用，可以参考hdfs命令指导
9.导入检查点（Import Checkpoint）
如果所有的image拷贝和edits文件都丢失了，最近的检查点可以被导入到NameNode。
为了做到这一点需要：
- 创建一个在dfs.namenode.name.dir中配置值的空路径；
- 在dfs.namenode.checkpoint.dir配置的值中指定检查点目录的位置；
- 使用-importCheckpoint选项启动NameNode
NameNode将从dfs.namenode.checkoint.dir路径中上传检查点，并且保存它到dfs.namenode.name.dir中配置的NameNode 目录。如果在dfs.namenode.name.dir中存在一个合法的image，NameNode将失败。 NameNode验证 dfs.namenode.checkpoint.dir中image一致性，但不以任何方式修改它。
更多命令使用，可以参考hdfs命令指导
10.平衡（balancer）
HDFS数据可能并不是在DataNode中被放置的是均匀的。一个常见的原因是新的DataNode添加到现存的集群中。当放置新块时（文件的数据被存储为一系列的块），NameNode在选择DataNodes来接受这些块之前，要考虑多个参数。一些注意事项：
- 保持一个在同一节点上的块的副本，作为写入该块到节点的策略。
- 需要通过构架来传播不同块的副本，这样机器可以在整个构架丢失的情况下存活下来。
- 其中一个副本通常是放在同一个构架上，作为写入文件的节点，这样就减少了网络构架的I/O。
- 在集群中HDFS数据均匀的传播到DataNode
由于多种竞争性的考虑，数据可能并不是均衡的放置在DataNode中。HDFS提供了一个工具给管理员来分析块放置和对DataNode中的数据再平衡。一个简短的管理员手册对于平衡是可用的（HADOOP-1653 https://issues.apache.org/jira/browse/HADOOP-1652）
更多命令使用，可以参考hdfs命令指导
11.构架意识
通常大型Hadoop集群被安排在一些机架上，集群被不同节点之前的网络流量比不同机架间的网络流量更可取。另外，NameNode试图放置块的副本在不同机架上来提高容错。hadoop可以让集群管理员通过配置变量net.topology.scrript.file.name的值来决定节点属于哪个机架。当这个脚本被配置，每个节点运行这个脚本来决定它们的机架id。默认安装时假设所有的节点属于一个机架。这个特性和配置进一步在HADOOP-692中附带的PDF中介绍（https://issues.apache.org/jira/browse/HADOOP-692）
12.安全模块（safemode）
在启动NameNode期间会从fsimage和edits日志文件中，加载文件系统状态。然后它会等待DataNode汇报它们的块，这样它并未过早的开始复制块，虽然集群中已经存在足够的复制。在这个期间，NameNode 位于安全模式。安全模式对于NameNode本质上来说，是对HDFS集群的只读模式，它不允许任何修改文件系统或块。通常呢，在NameNode接收到DataNode的报告,所有文件系统块是可用的之后，会自动脱离安全模式。如果需要，HDFS可以被放置到安全模式，通过明确指定 bin/hdfs dfsadmin -safemode 命令。NameNode首页显示了安全模式是否是开或关。更详细的描述和配置可以参考JavaDoc中setSafeMode().
13 .修复（fsck）
HDFS提供了fsck命令来检查各种不一致。它被设置为各种文件报告出错误，例如，一个文件丢失块或者在复制块后。不同于传统的本地文件系统中的用途，这个命令不会修正检测到的错误。通常情况下，NameNode自动的修正那些可恢复故障。默认情况下，fsck会忽略打开文件，但是提供一个选项来在报告中选择所有文件。HDFS fsck命令不是一个Hadoop shell命令。它可以使用 bin/hdfs fsck来运行。fsck可以运行在整个文件系统上，或者一个文件子集上。
更多命令使用，可以参考hdfs命令指导
14 . fetchdt
HDFS通过fetchdt命令来获得Delegation Token，然后存储到一个本地文件系统的文件中。这个token可以在之后从一个非安全客户端来访问安全服务器（例如NameNode）。程序使用RPC或者HTTPS来获得token，因此在运行之前需要存在kerberos tickets（运行kinit来获得tickets）。HDFS fetchdt命令不是一个Hadoop shell命令。可以使用bin/hdfs fetchdt DTfile来运行。在你获得token之后，可以允许一个HDFS命令而没有kerberos tickets，通过制定HADOOP_TOKEN_FILE_LOCATION环境变量来表示token文件。
更多命令使用，可以参考hdfs命令指导
15.恢复模块（recovery mode）
通常，你将配置多个元数据存储位置。这样，如果一个存储位置坏了，你可以从其他存储位置来读取元数据。
但是，唯一存储位置损坏了，你能够做些什么？在这个场景下，可以指定NameNode启动模式调用Recovery mode，可能会让你恢复你的大部分数据。
你可以在恢复模式开启NameNode，例如这样：namenode -recover
当在恢复模式时，NameNode将会以交互式的提示你在命令行，采取可能的行动来恢复你的数据。
如果你不想被体制，你可以使用 -force选项。这个选项将强制恢复模式总是选择第一个选项。通常情况下，这些都是合理的选择。
因为恢复模式会导致丢失数据，你需要在使用它之前备份你的edit日志和fsimage。
16.升级和回滚
当Hadoop在现有的集群上进行升级，作为任何升级的软件，它可能有一些在之前没有发现的，新的bug或不兼容的变更，从而影响现有的应用。在任何非普通地HDFS安装中，松散任何数据并不是一个选项，更不用说从头开始重启HDFS。HDFS允许管理员去回退到更早的Hadoop版本，并且回滚集群的状态到升级之前。关于hadoop升级的详细描述可以参考(http://wiki.apache.org/hadoop/Hadoop_Upgrade).HDFS可以同时有这样一个备份。在升级之前，管理员需要移除现有的备份使用 bin/hadoop dfsadmin -finalizeUpgrade 命令。下面简要的介绍了典型的升级过程：
- 在升级Hadoop软件之前，最后确定这里是否存在备份。dfsadmin -upgradeProgress状态可以说明集群是否需要最后确定。
- 停止集群，然后分布新的hadoop版本
- 使用新版本选项-upgrafe（bin/start-dfs.sh -upgrade）
- 在大多数情况，集群运行的很好。一旦新的HDFS被认为工作正常（在许多天操作之后），完成升级。注意直到集群被确认，在升级之前删除存在的文件不会真正的在DataNodes上释放磁盘空间.
- 如果这里需要回退到之前旧的版本，
.关闭集群然后分布早期的hadoop版本。
.在namenode上运行回退命令（bin/hdfs namenode -rollback）。
.启动集群使用rollback选项(sbin/start-dfs.sh -rollback)。
当升级到一个新版本的HDFS时，对保留在新版本HDFS中的任何路径进行重命名或者删除是必要的。如果NameNode在升级过程中遇到了一个保留的路径，他会打印一个错误如下：
/.reserved is a reserved path and .snapshot is a reserved path component in this version of HDFS. Please rollback and delete or rename this path, or upgrade with the -renameReserved [key-value pairs] option to automatically rename these paths during upgrade.
指定-upgrade -renameReserved [optional key-value pairs]可以让NameNode来自动重命名任何在启动中发现的保留路径。例如，重命名所有路径.snapshot 到 .my-snapshot ， .reserved 到 .my-reserved。用户需要指定-upgrade -renameReserved .snapshot=.my-snapshot,.reserved=.my-reserved.
如果在-renameReserved中没有指定键值对，NameNode将使用后缀.<LAYOUT-VERSION>.UPGRADE_RENAMED,例如.snapshot.-51.UPGRADE_RENAMED.
在重命名过程中会有一些警告。建议在可能的情况下， 首先在升级前hdfs dfsadmin -saveNamespace。这是因为如果一个edit日志操作是关联到一个自动重命名文件目标端，可能会出现数据不一致。
17.DataNode 热插拔驱动（Hot Swap Drive）
DataNode支持热插拔驱动。用户可以在不关闭DataNode下增加或替换HDFS数据卷。下面简要介绍了典型的热插拔驱动程序：
- 如果是新存储目录，用户需要格式化它们并适当地挂载它们。
- 用户更新DataNode 配置dfs.datanode.data.dir来反映将使用的数据卷的目录
- 用户运行dfsadmin -reconfig datanode HOST:PORT start来启动配置进程。用户可以使用dfsadmin -reconfig datanode HOST:PORT status来查询配置任务的运行状态。
- 一旦配置任务完毕，用户可以使用umount来溢出数据卷目录和物理移除磁盘。
18.文件权限和安全
文件权限配置被设计和其他属性平台上类似，例如linux。目前，安全性仅限于简单的文件权限。启动NameNode的用户被视为HDFS的超级用户。未来的HDFS版本将会支持网络认证协议例如Kerberos，为用户认证和传输数据加密。详细的讨论可以参考权限指导。
19.可扩展性
Hadoop目前能运行上千节点的集群。在wiki页面（http://wiki.apache.org/hadoop/PoweredBy）上列出了一些部署了大型hadoop的组织。对于每个机器来说，HDFS有一个NameNode。目前来说NameNode上总的内存大小是拓展性的限制。在一个非常大的集群中，增加存储在HDFS中文件平均大小，有助于与集群的增加而不增加NameNode的内存需求。默认的配置可能不使用太大的集群。FAQ（http://wiki.apache.org/hadoop/FAQ）wiki页面列出了提升大hadoop集群的建议配置。
20.相关文件
本用户指南是使用HDFS的一个很好的起点，随着用户指南的延伸，这里有大量丰富的Hadoop和HDFS文档。下面列出一些进一步查找的起点：
http://hadoop.apache.org/
http://wiki.apache.org/hadoop/FrontPage
http://wiki.apache.org/hadoop/FAQ
http://hadoop.apache.org/docs/r2.7.1/api/index.html
http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml
http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html
Comment