目的
本文档可以作为使用Hadoop分布式文件系统用户的起点，无论是将HDFS应用在一个Hadoop集群中还是作为一个单独的分布式文件系统使用。HDFS被设计成可以马上在许多环境中工作起来，那么一些HDFS的运行知识肯定能大大地帮助你对一个集群做配置改进和诊断。
HDFS是Hadoop应用的主要分布式存储。一个HDFS集群由一个管理文件系统元数据的NameNode，和存储实际数据的一些Datanode组成。HDFS的架构在这里有详细描述。这个用户指南主要提供给需要跟HDFS集群打交道的用户或者管理员。HDFS架构文章中的图描绘了Namenode、Datanode和客户端们之间的基本交互。本质上，客户端与Namenode通讯获取或者修改文件的元数据，与 Datanode进行实际的IO操作。
下面的列表应该是大多数用户关心的HDFS突出特点。斜体字的术语将在后面详细描述。
1）Hadoop，包括HDFS，非常适合廉价机器上的分布式存储和分布式处理。它是容错的、可伸缩的，并且非常易于扩展。并且，以简单性和适用性著称的Map-Reduce是Hadoop不可或缺的组成部分。
2）HDFS的默认配置适合于大多数安装的应用。通常情况下，只有在一个非常大规模的集群上才需要修改默认配置。
3）HDFS是用java编写的，支持大多数平台。
4）支持shell命令行风格的HDFS目录交互。
5）Namenode和Datanode都内建了web服务器，可以方便地查看集群的状态
6）HDFS经常性地实现新的特性和改进，下面是HDFS中的一些有用特性的子集：
文件许可和授权
Rack awareness :当调度任务和分配存储的时候将节点的物理位置考虑进去。
Safemode(安全模式） ：用于维护的一个管理状态
fsck ： 诊断文件系统的一个工具，用来查找丢失的文件或者block
Rebalancer :当数据在Datanode间没有均匀分布的时候，用于重新平衡集群的工具
升级和回滚 ：当Hadoop软件升级，在升级遇到不可预期的问题的时候，可以回滚到HDFS升级前的状态
二级Namenode ：帮助Namenode维持包含了HDFS修改的日志的文件（edits日志文件,下文谈到）大小在限制范围内。
下面的文档描述了一个Hadoop集群的安装和设置：
- Hadoop Quickstart ，给初次使用用户
- Hadoop Cluster Setup 大规模、分布式集群
本文档的剩余部分假设你已经搭设并运行了一个至少拥有一个Datanode的HDFS。基于本文档的目的，Namenode和Datanode可以运行在同一台机器上。
Namenode和Datanode分别跑了一个内置的web服务器，来展现集群当前状态的一些基本信息。在默认配置下，Namenode的首页地址是http://namenode:50070（namenode就是Namenode节点所在机器IP或者名称）。这个页面列出了集群中的所有datanode以及集群的基本统计。web接口同样可以用于浏览文件系统（点击Namenode首页上的“Browse the file system"链接）。
Hadoop包括了多种shell风格的命令，用于跟HDFS或者Hadoop支持的其他文件系统交互。命令 bin/hadoop fs -help 可以列出Hadoop shell支持的命令。更进一步，bin/hadoop fs -help command 可以展现特定命令command的帮助细节。这些命令支持一般文件系统的操作，例如拷贝文件、修改文件权限等。同时也支持了部分HDFS特有的命令，例如修改文件的replication因子。
'bin/hadoop dfsadmin' 命令支持一些HDFS管理功能的操作。'bin/hadoop dfsadmin -help'可以列出所有当前支持的命令。例如：
- -report : 报告HDFS的基本统计信息。部分信息同时展现在Namenode的web首页上。
- -safemode : 尽管通常并不需要，管理员还是可以通过手工操作进入或者离开safemode状态
- -finalizeUpgrade : 移除上一次升级时集群所做的备份。
Namenode将对文件系统的修改存储在一个原生文件系统文件中（名为edits的文件）。当Namenode启动的时候，它从映像文件（fsimage)读取HDFS的状态，然后将edits日志文件中的修改作用在此内存状态上，接着将得到的新的HDFS状态写回 fsimage，后续的正常操作开始于一个空的edits日志文件。由于Namenode仅仅在启动的时候将fsimage和edits合并，因此在一个大的集群上经过一定时间操作后，edits文件将会非常大。由此带来的一个副作用就是下次Namenode的重新启动将花费很长时间。二级 Namenode就是为了解决这个问题，它会周期性地合并fsimage和edits日志文件，并且将edits日志文件的大小保持在限制范围内。通常它会跑在另一个机器上，因为它的内存要求跟主namenode一样。二级Namenode可以通过'bin/start-dfs.sh'启动在conf /masters配置文件里配置的节点上。
HDFS的数据可能不会总是在Datanode之间分布得很一致。一个常见的原因是往现有的集群中加入了新的Datanode。当分配block的时候，Namenode依据几个参数来决定哪个datanode来接受这些block。一些需要考虑的因素如下：
1）一个block的副本存放在正在写该block的节点上
2）需要将一个block的副本扩展到其他机架上，防止因为整个机架故障导致的数据丢失。
3）副本之一通常放在同一个机架的另一个节点上，减少跨机架的网络IO
4）将HDFS数据均匀一致地分布在集群中的datanode上。
基于这些相互竞争的因素，数据可能不会在Datanode之间扩展得一致。HDFS给管理员提供了一个工具，用来分析block的分配情况和在datanode之间重新平衡数据。这个功能暂未实现，它的描述可以在这个 PDF 文档中看到，记录编号HADOOP-1652 .
典型的大规模Hadoop集群是部署在数个机架上的，那么显然同一个机架内的节点间的网络通讯比之不同机架间节点间的网络通讯更可取。另外，Namenode会尝试将block的副本分布在数个机架中以提高容错性。Hadoop让集群管理员来决定某个节点从属于哪个机架，通过配置变量dfs.network.script来实现。当这个脚本有配置的时候，每个节点都运行该脚本来决定它的rackid。默认安装假设所有的节点从属于同一个机架。这个特性和配置进一步的阐述在这个PDF 文档，编号为 HADOOP-692 。
当Namenode启动的时候，它从fsimage和edits日志两个文件中加载文件系统的状态。然后等待 datanode报告他们的block信息，以便防止Namenode在确认block副本是否足够前过早地开始复制block。这段时间的 Namenode就是处于所谓safemode状态。处于safemode的Namenode也是HDFS集群的只读模型，此时不允许任何对文件系统或者 block的修改。正常情况下，Namenode会在开始后自动退出safemode。如果有需要，HDFS可以通过'bin/hadoop dfsadmin -safemode'命令显式地进入safemode状态。Namenode的web首页显示当前的safemode是否打开。更详细的描述和配置可以参考setSafeMode() 方法的JavaDoc。
译注：详细介绍下safemode的配置参数，在safemode状态，Namenode会等待所有的datanode报告他们自己的block信息，看看所有的block的副本是否达到最低要求的数目，这个数目可以通过dfs.replication.min参数配置，默认是1,也就是至少要求有一个副本。当报告合格的Datanode的数目达到一定百分比，Namenode才会离开safemode状态。这个百分比也是可配置的，通过 dfs.safemode.threshold.pct参数，默认是0.999f(也就是要求99.9%的Datanode 合格）。Namenode在合格的datanode数目达到要求的时候，并不是马上离开safemode状态，会有一个扩展时间，让剩余的 datanode来报告block信息，这个扩展时间默认是30秒，可以通过 dfs.safemode.extension参数配置，单位是毫秒。
HDFS提供了fsck命令用来检测各种各样的不一致性。fsck被设计用来报告各种文件的问题，例如某个文件丢失的 block，block的副本数目是否低于设置等。不同于传统的一般原生文件系统的fsck命令，hdfs的fsck命令并不修正所检测到的错误。通常情况下，Namenode会自动修正大多数可以被修复的错误，HDFS的fsck不是Hadoop shel的命令，可以通过'bin/hadoop fsck'执行，可以运行在整个文件系统上或者一个文件子集上。
当升级某个集群的Hadoop的时候，正如任何软件的升级一样，可能会引入新的bug或者不兼容的修改导致现有的应用出现过去没有发现的问题。在所有重要的HDFS安装应用中，是不允许出现因丢失任何数据需要从零开始重启HDFS的情况。HDFS允许管理员恢复到 Hadoop的早期版本，并且将集群的状态回滚到升级前。HDFS的升级细节请参考 upgrade wiki 。HDFS在任何时间只能有一个备份，因此在升级前，管理员需要通过'bin/hadoop dfsadmin -finalizeUpgrade'命令移除现有的备份。下面简要描述了典型的升级过程：
1）在升级Hadoop前，如果已经存在备份，需要先结束（finalize)它。可以通过'dfsadmin -upgradeProgress status'命令查询集群是否需要执行finalize
2)停止集群，分发部署新版本的Hadoop
3）执行新版本的hadoop，通过添加 -upgrade 选项，例如/bin/start-dfs.sh -upgrade
4)大多数情况下，集群在升级后可以正常运行。一旦新的HDFS在运行若干天的操作后没有出现问题，那么就可以结束(finalize)这次升级。请注意，在升级前删除的文件并不释放在datanode上的实际磁盘空间,直到集群被结束（finalize)升级前。
5）如果有需要回到老版本的Hadoop，那么可以：
a)停止集群，分发部署老版本的Hadoop
b)通过rollback选项启动集群，例如bin/start-dfs.sh -rollback
文件许可的设计与其他平台(如linux) 的文件系统类似。在当前实现，安全被限制在简单的文件许可上。启动Namenode的用户被作为HDFS的超级用户。HDFS的未来版本将支持网络验证，例如Kerberos方案（译注：MIT开发的一个验证系统）的用户验证以及数据传输的加密。更详细的讨论参考Permissions User and Administrator Guide 。
Hadoop正运行在成千上万个节点的集群上。 PoweredBy Hadoop 列出了一些部署Hadoop在大规模集群上的组织和机构。HDFS在每个集群上只有一个Namenode节点，Namenode节点上可用内存是当前伸缩性的主要限制。在非常大规模的集群上，增加HDFS中存储的文件的平均大小，将可以帮助提高集群的大小而不用增加Namenode的内存需求。默认的配置可能不适合非常大规模的集群应用。Hadoop FAQ 页列出了对于大规模Hadoop集群的配置改进建议。
本用户指南可作为使用HDFS很好的一个起点，在本文档持续改进的同时，有一些非常有价值的关于Hadoop和HDFS的文档资料可供参考。下列资料可作为进一步探索的起点：
- Hadoop Home Page : Hadoop一切的起始页。
- Hadoop Wiki :由社区维护的wiki文档。
- FAQ from Hadoop Wiki.
- Hadoop JavaDoc API .
- Hadoop User Mailing List : core-user[at]hadoop.apache.org .
- 浏览conf/hadoop-default.xml 文件，它包括了当前可用配置变量的概括介绍。
...)
