Hadoop教程 第二章：Hadoop分布式文件系统[1]

MEI

第二章：Hadoop分布式文件系统< xmlnamespace prefix ="o" ns ="urn:schemas-microsoft-comfficeffice" />

介绍

HDFS，Hadoop Distributed File System，是一个设计用来保存大数据量的数据的分布式文件系统(TB级甚至是PB级)，并提供快速访问这些数据的能力，数据通过冗余的方式保存在多台机器上，以来保存对失败的容错性和并行应用的高度可用性，本章介绍分布式文件系统的设计以及如何使用它。

本章目标

1. 理解HDFS的基本设计，以及它与基本的分布式系统概念的关系。

2. 学习如何通过命令行建立和使用HDFS。

3. 学习在你的应用上使用HDFS。

大纲

1.         介绍

2.         本章目标

3.         大纲

4.         分布式文件系统基础

5.         配置HDFS

6.         与HDFS交互

1.         常用操作示例

2.         HDFS命令行参考

3.         HFSAdmin命令行参考

7.         在MapReduce中使用HDFS

8.         编程中使用HDFS

9.         HDFS权限和安全性

10.     其它HDFS任务

1.         块的重新负载

2.         拷贝大的文件集合

3.         停止结点运行

4.         检验文件系统正常度

5.         对主机架的考虑

11.     HDFS Web接口

12.     参考

分布式文件系统基础

分布式文件系统是设计来保存大数据量的数据，并提供客户端可访问分布在网络上数据的方法。有许多分布式系统以不同的方法来解决这个问题。

NFS，Network File System，是最常见的分布式文件系统，它也是仍然在使用的最古老的分布式文件系统，它的设计非常直观，便有很大的局限性，NFS提供远程访问单台机器的单个逻辑卷的能力，一个NFS服务器将它本地的对外部客户端可见，客户端可以将这个远程的文件系统直接挂载到它们自己的Linux文件系统上，再以对本地磁盘相同的方式访问它。

这种模型一个最大的优点是它的透明性，客户端并不需要特别关注它们是在操作远程的数据文件，标准的库函数如open，close，fread等等，都可通过NFS使用。

但作为一个分布式文件系统，它的能力很有限，一个NFS的文件都要存在一台机器上，这意味着它只能保存一台机器所能保存的数据量，并且不提供这台机器崩溃的可靠性保证（比如通过复制文件到其它服务器上），如果大量客户端要操作数据，会使服务器压力很重，并且客户端必需总是将数据读到它们本地机器上才能操作。

HDFS的设计相对其它分布式文系统，比如NFS，对几个问题是健壮的，特别是：

1.         HDFS设计用来保持非常大数据量的信息，这需要将数据分布到大量的机器上，它支持比NFS大得多的文件大小。

2.         HDFS的数据保存是可靠的，如果集群中的机器工作不正常，数据仍然是可用的。

3.         HDFS提供快速，可扩展的数据访问能力。

4.         通过简单地添加一些机器，就可以使集群能服务于更多的客户端是可能的。

5.         HDFS与Hadoop MapReduce能很好地集成，它在可能的情况下，能使数据读取，计算本地化。

尽管HDFS有很强的可扩展性，但由于它高性能的设计也使它局限于某些应用范围，它并不是如NFS通用，下面是HDFS做出的一些权衡：

1.         应用程序使用HDFS要使用流的方式读取文件，HDFS对流式读取文件进地了优化，但这时seek到文件的任一位置这种操作代价就高了。

2.         数据是一次写入，多次读取；Hadoop不支持写操作关闭文件后，再更新文件（Hadoop 0.19支持追加文件）。

3.         由于文件很大，并且是流式读取，所以系统并不提供本地缓存机制，如果要取读过的数据，只能再从HDFS文件中再次读取。

4.         Hadoop假设每个机器都极可能失败，或永远或暂时，集群必须能应付多台机器同时失败的情况（比如，主机架倒了），这时集群性能下降应与损失的机器成比例，系统作为一个整体不应变得很慢，也不应该有数据丢失，Hadoop用复制数据的策略来克服这一困难。

HDFS的设计是基于GFS，Google File System的设计，它的设计在论文Google File System中有描述。

HDFS是块结构的文件系统，单个文件被分成相同大小的块，这些块被分布到集群中的多台机器上，集群中的单个机器被称为数据结点(DataNode)，一个文件可由多个块组成，它们并不需要放到同一台机器上，保存每个块的机器是被随机选择的，所以访问一个文件需要多台机器协作，但它所支持的文件大小会比单台机器的DFS大的多，并保持一个台机器存不下的文件。

如果使用多台机器保存一个文件，那么这些机器中任一一台崩溃都会导致文件不可访问，HDFS通过将每块复制到多台机器（默认3台）的方式来解决这个问题。

< xmlnamespace prefix ="v" ns ="urn:schemas-microsoft-com:vml" />

图2.1 数据结点保存着多个文件的块，复制数为2，名字结点中保存着文件名与块id的关系

大多数基于块的文件系统的块大小为4KB或8KB，与之相比，HDFS中默认使用块大小为64MB，比前者大出几个数量级。这使得HDFS减少了对每个文件元数据的存储量，不只如些，通过很大量数据连续化存放在磁盘上，就可以快速地流式读取数据，这种设计的结果是HDFS倾向于处理大文件，并顺序地读取不同于诸如NTFS或EXT。这些要处理许多小文件的文件系统。HDFS倾向于保存大量超大文件，每个几百M或几G，因为100MB的文件才不过能分成2个块，在你计算机上的文件也许经常被随机访问，即应用程序从一个文件中不同位置读取少量信息，而不是顺序访问，相反，HDFS希望程序从开始顺序读到结尾的方式读，这使它在第四章所介绍的MapReduce形式的编程中特别有用。

HDFS是在一些机器中以块的形式保存文件，但这些文件并不是普通文件系统的一部分，在运行Hadoop服务的数据结点上输入ls命令，可以显示普通文件系统的内容，但它不能显示HDFS中的文件，这是因为HDFS在一个不同的命名空间中运行，它与本地文件内容是隔离的，HDFS中的文件（更准确性，组成这些文件的块）是保存在数据结点服务管理的一个特定目录下，这些文件没有名字，只有块id，你无法通过Linux文件命令与HDFS中的文件交互。

但HDFS有它自己的文件管理命令，并且还与你熟悉的Linux文件命令很相似，本章将在后面部分向你介绍这些命令。

文件系统可靠保存它的元数据是很重要的，更准确地说，因为文件数据是以一次写入，多次读取的方式访问的，元数据结构（比如：文件名，目录名）会被大量客户端同时修改，元数据结构信息户不使去同步是很重要的，所以这些只由一台机器来处理，它被称为名字结点（NameNode），保存着文件系统中所有元数据。因为每个文件都有较少的元数据（它只保存文件名，权限，和文件每块的位置），所有的元数据都保存在NameNode的内存中，可以进行快速访问元数据。

要打开一个文件，客户端可从NodeNode取得该文件每个块的位置，即是哪些结点保存着这个文件的块，客户端再直接从DataNode中读取每个块，这个过程可以并行读取，NameNode并不直接参与块数据传输，这可使它的压力减至最小。

当然，即使名字结点失败名字结点的信息也必须保存，所以有多个冗余系统可以使名字结构完全崩溃时，也可以保存元数据信息。名字结点崩溃比如数据结点崩溃更严重，当单个数据结点崩溃，整个集群也会正常运行，但名字结点崩溃后，集群将不可访问，除非名字结点手工恢复，幸运的是名字结点参与相比是非常少的，所以它崩溃的可能也远低于任一数据结点。

配置HDFS

在集群上配置HDFS只需要很短的时间，首先我们来看Hadoop配置有关的部分，再看名字结点的格式。

集群配置

首先要把Hadoop下载并解压，第五章会介绍Hadoop如何运行，第七章介绍如何建立一个大的集群，并为Hadoop做一些预设置，包括下载依赖的软件。

HDFS配置文件是一组XML文件，它们位于Hadoop的配置目录conf下，conf目录在Hadoop的安装目录下(即解压Hadoop后产生的目录)。conf/hadoop-defaults.xml文件中包含了Hadoop中的所有参数默认值，这个文件一般视为是只读的，你可以在conf/hadoop-site.xml中设置新的值，以覆盖默认值，这个文件会被复制集群中的所有机器上。

配置设置是以一组键-值对的格式：

<property>

    <name>property-name</name>

    <value>property-value</value>

</property>

在配置中加入<final>true</final>可防止属性被别的应用覆盖。这在大多系统范围配置选项中是有用的。

下列的设置在HDFS配置中是必需的：

key	value	example
fs.default.name	protocol://servername:port	hdfs://alpha.milkman.org:9000
dfs.data.dir	pathname	/home/username/hdfs/data
dfs.name.dir	pathname	/home/username/hdfs/name

这些设置的描述如下：

fs.default.name，这是集群名字结点的URI（协议，主机名，端口）。Hadoop系统中的结点都需要知道名字结点的地址才能进行操作，数据结点要与这个名字结点一起注册，才吏它们的数据通过名字结点变为可用的，客户端要通过个地址取得文件块的真正存放地址再去取数据。

dfs.data.dir，这是数据结点保存数据的本地文件系统的路径，因为它们将运行在不同的机器上，并不需要所有的数据结点都将数据保存到相同前缀的本地路径，集群中的机器是不同的，也是可行的。但如果这个目录在整个系统都是统一的，那么配置也就简单些，Hadoop默认将dfs.data.dir设为/tmp。这在测试时是没关系的，但在生产环境中，这样做很容易丢失数据，所以必需覆盖。

dfs.name.dir，这是名字结点保存元数据的本地路径，它仅用于名字结点找到它自己的信息，它在数据结点上不存在，它的默认值也是/tmp，所以它也必须覆盖。

另一个上面没有提及的参数dfs.replication，它是文件系统中每个块的默认复制数，在生产环境集群中，一般就用它的默认值3，你可以随意增加复制数，但它会无谓地用去很多空间，如果把它设小，会影响数据的可用性和可靠性。

在单结点上的配置中，可以直接把下面的配置复制到hadoop-site.xml中（译者注：这是0.18版的做法，在0.20下不会成功，日后我会更新到0.20的方法的）。

<configuration>

  <property>

    <name>fs.default.name</name>

    <value>hdfs://your.server.name.com:9000</value>

  </property>

  <property>

    <name>dfs.data.dir</name>

    <value>/home/username/hdfs/data</value>

  </property>

  <property>

    <name>dfs.name.dir</name>

    <value>/home/username/hdfs/name</value>

  </property>

</configuration>

当然，your.server.name.com和username是需要修改的，而使用端口9000是任意选择的。

将以上配置拷入con/hadoop-site.xml文件后，将con/目录拷到集群中所有机器上。主结点需要知道所有数据结点机器的地址，因为启动脚本依赖它，同样在con/目录中，编辑文件子结点，使它包含子结点的完整主机名列表，每行一个主机名，主结点（比如localhost）通常不在这个文件中出现。

然后创建下面的目录

user@EachMachine$ mkdir -p $HOME/hdfs/data

user@namenode$ mkdir -p $HOME/hdfs/name

拥有Hadoop实例的用户需要可以读写上面的两个目录，并不是所有的用户都需要访问这两个目录，用chmod来设置权限是比较合理的。在大规模环境中，建议使用者在每个结点上创建一个名为hadoop的用户，以来拥有和运行hadoop任务，对于单个机器使用你自己的用户名，运行Hadoop是完全没有问题的，但不建议用root运行Hadoop。

启动HDFS

现在我们需要格式化我们设置的文件系统：

user@namenode:hadoop$ bin/hadoop namenode -format

上述操作只应进行一次，当它完成时，我们可以启动分布式文件系统了。

user@namenode:hadoop$ bin/start-dfs.sh

这个命令会启动主结点的名字结点（也就是start.dfs.sh被调用的地方），它同样也启动每个子结点(slave machine)上的数据结点实例，在单机“集群”中，数据结点与名字结点在同一台机器上，在两台或多台机器的真实集群上，这个脚本会ssh到每个子结点，启动数据结点实例。