@changedi
2017-02-04T20:46:52.000000Z
字数 7237
阅读 6153
大数据
HDFS
原文:http://hadoop.apache.org/docs/r2.6.4/hadoop-project-dist/hadoop-hdfs/HdfsUserGuide.html
HDFS是个分布式文件系统,包含几个特点(区别于普通分布式文件系统):高容错
、高吞吐
。高容错可以使得系统部署在廉价硬件上,而高吞吐则非常适合做大规模数据集的应用。
HDFS是Hadoop应用程序运行的主要分布式存储。一个HDFS集群包含一个NameNode来管理集群文件系统的元数据metadata,包含很多DataNode来实际存储数据data。
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启动的时机由两个配置参数决定。
Secondary NameNode把最新的checkpoint存入一个字典,这和Primary的处理方式是一样的。这样就保证了在Primary需要时可以随时读取被checkpoint的image。
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启动进程是由下面两个参数来配置并控制的。
Checkpoint Node把最新的checkpoint存入一个字典,这和NameNode的处理方式是一样的。这样就保证了在NameNode需要时可以随时读取被checkpoint的image。(看到这里,Checkpoint和Secondary不是长得一样吗)
可以在集群配置文件里配置多个Checkpoint 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中声明不需要持久存储。
当所有的image和edits的拷贝全部丢失时,最新的checkpoint会被import到NameNode。为了确保这种行为,需要:
NameNode会从dfs.namenode.checkpoint.dir上传checkpoint,然后把checkpoint保存到dfs.namenode.name.dir。当一个合法的image存在dfs.namenode.name.dir时,NameNode会fail。NameNode会校验dfs.namenode.checkpoint.dir里的镜像是否是一致的,但是不会修改它。
HDFS上的数据一般不会均匀的分布在各个DataNode上。通常这是因为为已知集群添加新的DataNode导致的。当分配block的时候(数据存到文件是以一系列的block形式存在的),NameNode在确定哪个DataNode来接受数据时需要考虑很多参数。比如:
基于多种考虑,数据也许不会被均匀分布。HDFS提供给管理员一个工具来分析block的分布情况并且可以重新分配DataNode的data来保证balance。具体详见HADOOP-1652。
典型的大型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。
在启动过程中,NameNode会从fsimage和edits日志文件里加载文件系统状态。然后NameNode会等待各个DataNode来汇报它们的block,所以它不会提前启动复制这些block,尽管集群已经存在足够的副本数。在这段时间,NameNode进入安全模式。NameNode的安全模式本质上是一个HDFS集群的只读模式,它不会允许对文件系统或者block进行任何修改。正常状况下,NameNode会在大多数DataNode汇报完其文件系统的block状态可用后脱离保护模式。如果有必要,HDFS可以通过bin/hdfs dfsadmin -safemode命令显式地进入保护模式。 NameNode的首页会显示保护模式的开关状态。
HDFS支持fsck命令来检查不一致状态。它被设计用来利用不同的文件汇报问题,比如在文件或者未备份block下丢失block。不像传统文件系统本地的fsck应用,HDFS的fsck不会修复检测到的错误。通常NameNode会自动修复大多数可恢复的错误。默认情况fsck会忽略open files,但也提供一个选项可以在汇报时支持选择所有文件。fsck命令不是一个Hadoop shell命令。它可以通过bin/hdfs fsck来运行。fsck可以运行在整个文件系统下,也可以是一个文件的子集。
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命令。
典型的场景下,你需要配置多个元数据存储。那么,如果其中一个崩溃了,你就可以通过读取另一个元数据存储来保证正常服务。
然而如果只配置了一个元数据存储,这时崩溃会怎么办呢?在这种情况下,一种特殊的NameNode启动模式——Recovery模式可以允许你恢复你的大多数数据。
你可以用这样的命令来启动recovery模式:namenode -recover
当处于恢复模式时,NameNode会在命令行提示你选择可能的操作来恢复你的数据。
如果不想被通知,可以指定-force选项。这个选项会强制恢复模式选择第一个操作选项。正常情况下,这会是最合理的一个选择。
因为恢复模式会导致你丢失数据,所以在启用时请备份你的edit log和fsimage。
当Hadoop在已知集群中升级后,可能会导致带来新的bug或者不兼容的变更影响已有的应用。在任意的非试用的HDFS安装下,丢失数据都是不可用的,更别说是从一个软件重启HDFS。HDFS允许管理员回滚Hadoop到集群之前的版本。HDFS升级在Hadoop Upgrade Wiki页面有详细的描述。HDFS一次可以有一个备份。在升级前,管理员需要用bin/hadoop dfsadmin -finalizeUpgrade命令来移除已经存在的备份。具体的升级步骤简略描述如下:
当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操作会引发数据不一致性。
HDFS的文件权限与其他类似Linux的平台的文件权限设计方式类似。当前的安全设计局限于简单的文件权限。负责启动NameNode的用户被认为是HDFS的超级用户。未来新版本的HDFS会支持类似Kerberos的网络鉴权协议用来做用户鉴权和数据加密传输。
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.