HDFS的一些概念

大数据 HDFS

原文：http://hadoop.apache.org/docs/r2.6.4/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html

介绍

HDFS是个分布式文件系统，包含几个特点（区别于普通分布式文件系统）：高容错、高吞吐。高容错可以使得系统部署在廉价硬件上，而高吞吐则非常适合做大规模数据集的应用。

概述

HDFS是Hadoop应用程序运行的主要分布式存储。一个HDFS集群包含一个NameNode来管理集群文件系统的元数据metadata，包含很多DataNode来实际存储数据data。

• HDFS是高度可配置的，HDFS的默认配置适用于一般场景，只有在非常大规模的集群环境下配置需要调优。
• Hadoop是Java写的，适用于所有的平台。
• Hadoop支持类似Shell的命令直接与HDFS交互。
• NameNode和DataNode已经支持并构建了Web server，可以很容易的检查集群的当前状态。

Secondary NameNode

NameNode把修改（modifications）像记录本地文件系统日志文件一样append到文件系统里，作为edits。当NameNode启动后，它读取一个镜像文件——fsimage，从中读取HDFS的状态，然后从edits的日志文件里将edits恢复。恢复后把心的HDFS状态写到fsimage并且启用一个空的edits文件来记录普通操作。既然NameNode只在启动时合并fsimage和edits，这样就会导致edits日志文件在集群繁忙时变得越来越大。带来的副作用就是在下一次NameNode启动时造成更长时间的edits和fsimage的合并。

Secondary NameNode周期性的合并fsimage和edits日志，保持edits文件大小在一个限定的范围内。它一般运行在Primary NameNode以外的另一台机器上，因为运行时所需要的内存要保证和Primary NameNode同样优先。Secondary NameNode的检查点checkpoint启动的时机由两个配置参数决定。

• dfs.namenode.checkpoint.period默认设置为1小时，表明两个连续checkpoint的最大延时，
• dfs.namenode.checkpoint.txns默认设置1百万，声明了未设置checkpoint的transaction的最大数量，当达到这个数值时，就算没有到达前一个参数配置的时间间隔，也会强制做一个checkpoint。

Secondary NameNode把最新的checkpoint存入一个字典，这和Primary的处理方式是一样的。这样就保证了在Primary需要时可以随时读取被checkpoint的image。

Checkpoint Node

NameNode把它的namespace持久化到两类文件里：fsimage，这是namespace的最新的checkpoint，另一个是edtis日志，这是自从checkpoint后的一系列针对namespace的变动日志。当一个NameNode启动后，它会合并fsimage和edits日志从而提供一个文件系统元数据的最新的版本。然后NameNode会复写fsimage，把这个最新的HDFS的状态写入进去，同时会开启一个新的edits日志文件用来记录之后的变化。

Checkpoint Node会周期性的创建一些namespace的checkpoint。它会从当前活跃的NameNode上下载fsimage和edits，然后在本地合并并且上传新的image回到NameNode。Checkpoint Node通常运行在NameNode外的另一台机器上，因为它对内存的要求和NameNode具有同样的优先级。Checkpoint Node是通过bin/hdfs namenode -checkpoint 命令启动的，具体启动的节点由配置文件指定。

Checkpoint Node的地址配置以及其自带的web界面配置是通过dfs.namenode.backup.address和dfs.namenode.backup.http-address配置来指定的。

Checkpoint Node的checkpoint启动进程是由下面两个参数来配置并控制的。

• dfs.namenode.checkpoint.period默认设置为1小时，表明两个连续checkpoint的最大延时，
• dfs.namenode.checkpoint.txns默认设置1百万，声明了未设置checkpoint的transaction的最大数量，当达到这个数值时，就算没有到达前一个参数配置的时间间隔，也会强制做一个checkpoint。

Checkpoint Node把最新的checkpoint存入一个字典，这和NameNode的处理方式是一样的。这样就保证了在NameNode需要时可以随时读取被checkpoint的image。（看到这里，Checkpoint和Secondary不是长得一样吗）

可以在集群配置文件里配置多个Checkpoint Node。

Backup Node

Backup Node提供和Checkpoint Node同样的checkpoint的功能，包括状态内存保持，与NameNode同步的最新的文件系统namespace拷贝。除了与NameNode持久化到磁盘一致，Backup Node还会把edits的副本保存在内存中，以此来创建一个namespace的内存backup。

BackupNode不需要像Secondary NameNode和Checkpoint Node一样去下载fsimage和edits，因为在内存中已经保持了最新的namespace状态。所以Backup Node的checkpoint进程效率更高，因为它只会把namespace状态保存到本地fsimage并且reset edits。

显而易见的是Backup Node的内存需求和NameNode是一样的。

NameNode一次只支持一个Backup Node。当Backup Node启用时，不允许再添加Checkpoint node。目前还不支持并发多个Backup Node。

Backup Node和Checkpoint node的配置方式完全相同，也是通过bin/hdfs namenode -backup 启动。

Backup Node的地址配置以及其自带的web界面配置是通过dfs.namenode.backup.address和dfs.namenode.backup.http-address配置来指定的。

使用Backup node将不再需要NameNode启动时提供任何持久化的存储，NameNode会把所有状态持久的事情委托给Backup node。要想做到这点，在启动NameNode时需要加上-importCheckpoint选项，同时在NameNode的配置项dfs.namenode.edits.dir中声明不需要持久存储。

Import Checkpoint

当所有的image和edits的拷贝全部丢失时，最新的checkpoint会被import到NameNode。为了确保这种行为，需要：

• 按照dfs.namenode.name.dir的配置创建一个空的目录；
• 在dfs.namenode.checkpoint.dir声明好checkpoint的目录位置；
• 并且使用-importCheckpoint选项启动NameNode。

NameNode会从dfs.namenode.checkpoint.dir上传checkpoint，然后把checkpoint保存到dfs.namenode.name.dir。当一个合法的image存在dfs.namenode.name.dir时，NameNode会fail。NameNode会校验dfs.namenode.checkpoint.dir里的镜像是否是一致的，但是不会修改它。

Balancer

HDFS上的数据一般不会均匀的分布在各个DataNode上。通常这是因为为已知集群添加新的DataNode导致的。当分配block的时候（数据存到文件是以一系列的block形式存在的），NameNode在确定哪个DataNode来接受数据时需要考虑很多参数。比如：

• 确保一个block的一个副本在被写的这个block的同一台机器上的策略。
• 需要延展一个block的不同的副本分布到不同的rack，从而保证集群可以在整个rack失效的情况下可用。
• 一般要有一个副本是被写到目标文件所在的机器的同一个rack的，这样可以减少跨rack的网络I/O。
• 尽可能的使数据均匀分布在集群的各个DataNode上。

基于多种考虑，数据也许不会被均匀分布。HDFS提供给管理员一个工具来分析block的分布情况并且可以重新分配DataNode的data来保证balance。具体详见HADOOP-1652。

Rack Awareness

典型的大型Hadoop集群会是一个多rack的场景，并且更加需要同一rack的node通信而不是跨rack的node网络通信。NameNode试图分配block的副本到不同的rack，当然这样的目标是提升fault tolerance。Hadoop让集群管理员通过配置net.topology.script.file.name来决定一台机器属于哪个rack。当这个脚本文件配置好后，每个node运行这个脚本来决定自己的rack id。默认的安装是要求所有的node都在一个rack里。更多的描述在HADOOP-692。

Safemode

在启动过程中，NameNode会从fsimage和edits日志文件里加载文件系统状态。然后NameNode会等待各个DataNode来汇报它们的block，所以它不会提前启动复制这些block，尽管集群已经存在足够的副本数。在这段时间，NameNode进入安全模式。NameNode的安全模式本质上是一个HDFS集群的只读模式，它不会允许对文件系统或者block进行任何修改。正常状况下，NameNode会在大多数DataNode汇报完其文件系统的block状态可用后脱离保护模式。如果有必要，HDFS可以通过bin/hdfs dfsadmin -safemode命令显式地进入保护模式。 NameNode的首页会显示保护模式的开关状态。

fsck

HDFS支持fsck命令来检查不一致状态。它被设计用来利用不同的文件汇报问题，比如在文件或者未备份block下丢失block。不像传统文件系统本地的fsck应用，HDFS的fsck不会修复检测到的错误。通常NameNode会自动修复大多数可恢复的错误。默认情况fsck会忽略open files，但也提供一个选项可以在汇报时支持选择所有文件。fsck命令不是一个Hadoop shell命令。它可以通过bin/hdfs fsck来运行。fsck可以运行在整个文件系统下，也可以是一个文件的子集。

fetchdt

HDFS支持fetchdt命令来获取Delegation Token并且将其存储到本地系统的一个文件里。这个token可以用来从一个非安全的client访问安全的服务器（举例来说就是NameNode）。应用可以使用RPC或者HTTPS（通过Kerberos）来获取token，然后请求kerberos ticket来确保在run前可用。HDFS的fetchdt不是一个HDFS的shell命令。通过bin/hdfs fetchdt DTfile来运行。在获取了token后，你可以通过指定HADOOP_TOKEN_FILE_LOCATION环境变量为委托的token文件，在不需要Kerberos ticket的情况下运行HDFS命令。

Recovery Mode

典型的场景下，你需要配置多个元数据存储。那么，如果其中一个崩溃了，你就可以通过读取另一个元数据存储来保证正常服务。

然而如果只配置了一个元数据存储，这时崩溃会怎么办呢？在这种情况下，一种特殊的NameNode启动模式——Recovery模式可以允许你恢复你的大多数数据。

你可以用这样的命令来启动recovery模式：namenode -recover

当处于恢复模式时，NameNode会在命令行提示你选择可能的操作来恢复你的数据。

如果不想被通知，可以指定-force选项。这个选项会强制恢复模式选择第一个操作选项。正常情况下，这会是最合理的一个选择。

因为恢复模式会导致你丢失数据，所以在启用时请备份你的edit log和fsimage。

Upgrade and Rollback

当Hadoop在已知集群中升级后，可能会导致带来新的bug或者不兼容的变更影响已有的应用。在任意的非试用的HDFS安装下，丢失数据都是不可用的，更别说是从一个软件重启HDFS。HDFS允许管理员回滚Hadoop到集群之前的版本。HDFS升级在Hadoop Upgrade Wiki页面有详细的描述。HDFS一次可以有一个备份。在升级前，管理员需要用bin/hadoop dfsadmin -finalizeUpgrade命令来移除已经存在的备份。具体的升级步骤简略描述如下：

• 在升级Hadoop软件前，清除掉已有的备份。通过dfsadmin -upgradeProgress status 可以知道集群是否需要删除备份。
• 停止集群，并且安装Hadoop的新版本。
• 使用bin/start-dfs.sh -upgrade选项运行新版本。
• 大多数时候，集群已经正常运行了。一旦新的HDFS运行良好（也许要经过几天的正常操作才能确认），清除升级。注意，直到集群清除之前，删除的已经存在的升级前的文件并不会真正释放DataNode上的磁盘空间。
• 如果需要回滚到老的版本，停止集群并且安装Hadoop的之前的版本。使用rollback选项启动集群（bin/start-dfs.sh -rollback）。

当HDFS升级到新版本后，有必要rename或者delete新版本下已经有的保留的目录。如果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自动重命名在启动过程中发现的保留路径。比如，如果一个用户像这样声明参数：-upgrade -renameReserved .snapshot=.my-snapshot,.reserved=.my-reserved，那么系统会rename所有.snapshot命名的路径为.my-snapshot以及.reserved会重命名为.my-reserved。

如果没有key-value对与-renameReserved一起声明，那么NameNode会自动前缀保留路径，前缀形式为..UPGRADE_RENAMED，比如 .snapshot.-51.UPGRADE_RENAMED.

对于这个重命名的过程有一些需要预防错误的说明。如果允许的话，推荐在升级前先使用hdfs dfsadmin -saveNamespace。这是因为在自动重命名文件时涉及到目的文件的edit log操作会引发数据不一致性。

File Permissions and Security

HDFS的文件权限与其他类似Linux的平台的文件权限设计方式类似。当前的安全设计局限于简单的文件权限。负责启动NameNode的用户被认为是HDFS的超级用户。未来新版本的HDFS会支持类似Kerberos的网络鉴权协议用来做用户鉴权和数据加密传输。

Scalability

Hadoop在集群的上千台机器上运行。HDFS每个集群有一个NameNode。当前状况下，NameNode上的可用内存大小成了主要的扩展性限制。在非常大的集群下，HDFS存储的文件慢慢变大，这可以帮助集群在不增加内存需求的情况下扩容。默认的配置可能不适合非常大的集群。

关联文档

Hadoop Site: Hadoop首页
Hadoop Wiki: Hadoop Wiki首页
FAQ: The FAQ Wiki page.
Hadoop JavaDoc API.
Hadoop User Mailing List: user[at]hadoop.apache.org.
Explore hdfs-default.xml. It includes brief description of most of the configuration variables available.
HDFS Commands Guide: HDFS commands usage.