Hadoop分布式文件系统（1）

本文参考《Hadoop权威指南》，希望能为大家学习hadoop提供一点帮助

Hadoop分布式文件系统

当数据集的大小超过一台独立的物理计算机的存储能力时，就有必要对它进行分区（partition）并存储到
若干单独的计算机上。管理网络中跨多台计算机存储的文件系统被称为分布式文件系统（distributed
filesystem ）。该系统架构于网络之上，同时拥有网络编程的复杂性，因此分布式文件系统比普通的磁盘
文件管理系统更为复杂。比如，分布式文件管理系统需要保证节点故障的情况下不丢失任何数据。

Hadoop有一个称为HDFS的分布式系统，即Hadoop Distributed Filesystem。在以前版本的hadoop中
也被称为DFS，它们是同一种事物。Hadoop是一个综合性的文件系统抽象，而HDFS是Hadoop的旗舰机文件系统。

HDFS的设计

HDFS以流式数据访问模式来存储超大文件，运行于商业硬件集群上。

我们可以这么理解上面的话：

• 超大文件 :
  “超大文件”在这里指具有几百MB/几百GB设置几百TB大小的文件。目前已经有PB级数据的Hadoop集群了。

• 流式数据访问
  HDFS的构建思路是这样的：一次写入，多次读取是最高效的访问模式。数据集通常由数据源复制而来，接着
  长时间在此数据集上进行各种分析。每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个数据
  集的时间延迟比读取第一条记录的时间延迟更重要

• 商用硬件
  Hadoop并不需要运行在昂贵且高可靠的硬件上，它是设计运行在商业硬件（在各种零售店都能买到的普通
  硬件）的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，
  被设计成能够继续工作下去且不让用户察觉到明显的中断。
  同样，那些不适合在HDFS上运行的应用也值得研究。目前某些领域并不适合在HDFS上运行，不过以后可能会
  有所改进。

• 低时间延迟的数据访问
  要求低时间延迟访问的应用，例如几十毫秒范围，不适合在HDFS上运行。记住HDFS是为高数据吞吐量应用
  优化的，这可能会以提高时间延迟为代价。目前对于低延迟访问的需求，HBase是更好的选择。

• 大量的小文件
  由于 namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode
  的内存容量。根据经验，每个文件/目录和数据块的存储信息大约占150字节。举个例子，如果有一百万个文件，
  且每个文件占一个数据块，那至少需要300mb的内存。尽管存储上百万个文件是可行的，但是存储数十亿文件就
  超出了当前的硬件能力。

• 多用户写入，任意修改文件
  HDFS中的文件可能只能有一个writer，而且操作总是将数据添加在文件末尾。它不支持具有多个写入者的
  操作，也不支持在文件的任意位置进行修改。

HDFS的概念

##### 1. 数据块
每个磁盘都有默认的数据块大小，这是磁盘进行数据读写的最小单位。构建于单个磁盘之上的文件管理系统通过
磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统块一般为几千字节，
而磁盘块一般为512字节。这些信息—文件系统块的大小—对于需要读/写文件的文件系统用户来说是透明的。
尽管如此，系统仍然提供了一些工具（如ds和fsck）来维护文件系统，由它们对文件系统中的块进行操作。

HDFS同样也有块（block）的概念，但是大得多，默认为64MB。与单一磁盘上的文件系统相似，HDFS上的
文件也被划分为块大小的多个分块（chunk），作为独立的存储单元。但与其它文件系统不同的是，HDFS中
小于一个块大小的文件不会占据整个块的空间。

##### 2. namenode和datanode
HDFS集群有两类节点以管理者-工作者模式运行，即一个namenode（管理者）和多个datanode（工作者）
namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件
的形式永久存在本地的磁盘上：命名空间文件和编辑日志文件。namenode也记录着每个文件中各个块所在的
数据节点的信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时由数据节点重建

客户端（client）代表用户通过与namenode和datanode交互来访问整个文件系统。客户端提供一个类似POSIX（
可移植操作系统界面）的文件系统接口，因此用户在编程时无需知道namenode和datanode也可以实现其功能。

datanode是文件系统的工作节点。它们根据需要存储并检索数据块（受客户端或namenode的调度），并且
定期向namenode发送它们所存储的块的列表。

没有namenode，文件系统将无法使用。事实上，如果运行namenode服务的机器损坏，文件系统上的所有文件
将会丢失，因为我们不知道如何根据datanode块重建文件。因此，对namenode实现容错非常重要，Hadoop
为此提供两种机制

1. 第一种机制是备份那些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使namenode在多个
   文件系统上保存元数据的持久状态。这些写操作是实时同步的，是原子操作。一般的配置是，将持久状态写入
   本地磁盘的同时，写入一个远程挂载的网络文件系统（NFS）

2. 另一种可行的方法是运行一个辅助的namenode，但它不能被用作namenode。这个辅助namenode的重要作
   用是定期通过编辑日志合并命名空间镜像，以防止编辑日志过大。这个辅助namenode一般在另一台单独的计算
   机运行，因为它需要占用大量的cpu时间与namenode相同容量的内存来执行合并操作。它会保存合并后命名空间
   镜像的副本，并在namenode发生故障时启用。但是，辅助namenode保存的状态总是滞后于主节点，所以在主节点
   全部失效时，难免会发生部分数据丢失。在这种情况下，一般把存储在NFS上的namenode元数据复制到辅助namenode
   并作为新的主namenode运行。

   3. 联邦HDFS

   在Hadoop 2.x的版本系列中引入的联邦HDFS允许系统通过添加namenode实现扩展，其中每个namenode
   管理文件系统命名空间的一部分。

   在联邦环境下，每个namenode维护一个命名空间卷（namespace volume），包括命名空间的源数据和在该命名
   空间下的文件的所有数据块和数据块池。命名空间卷之间是相互独立的，两两之间并不相互通信，甚至其中一个
   namenode失效也不会影响由其它namenode维护的命名空间的可用性。数据块池不再进行切分，因此集群中的
   datanode需要注册到每个namenode。

   要想访问联邦HDFS集群，客户端需要通过使用客户端挂载数据表将文件路径映射到namenode。该功能通过
   ViewFIleSystem和viewfs:URI进行配置和管理。

   4. HDFS的高可用性

   Hadoop 2.x系列版本中在HDFS中增加了对高可用性（HA）的支持。

   Hadoop通过活动-备用（active-stanby）namenode，来实现HA。当活动namenode失效，备用namenode
   就会接管它的任务并开始服务于来自客户端的请求，不会有任何明显的中断。实现这一目标，需要在架构上做
   以下修改：

   • namenode之间需要通过高可用的共享存储实现编辑日志的共享。（在早期版本中，需要一个NFS过滤器
     来辅助实现，但是在后期版本中将提供更多的选择，比如构建于ZooKeeper之上的BookKeeper这样的系统）
     当备用那么弄得接管工作以后，它将通过共享编辑日志至末尾，以实现与活动namenode的状态同步，并
     继续读取由活动namenode写入的新条目。

   • datanode需要同时向两个namenode发送数据块处理报告，因为数据块的映射信息存储在namenode的内存中，
     而非磁盘。

   • 客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的。

   在活动namenode失效之后，备用namenode能谱快速（几十秒的时间）实现任务接管。

命令行接口

我们可以使用HDFS执行所有常用的文件系统操作，例如读取文件，新建目录，移动文件，删除数据，列出目录。
可以输入 hadoop fs -help命令获取每个命令的详细帮助文件。

首先从本地文件系统将一个文件复制到HDFS：

    root[@master](https://my.oschina.net/u/48054):/media/workspace/IntelliJIDEA/WHadoop# hadoop fs -copyFromLocal input/docs/quangle.txt /usr/weiwei/quangle.txt

再将文件复制回本地文件系统

    root[@master](https://my.oschina.net/u/48054):/media/workspace/IntelliJIDEA/WHadoop# hadoop fs -copyToLocal /usr/weiwei/quangle.txt input/docs/quangle.copy.txt

接着我们查看一下hadoop的文件目录是怎么显示的

    hadoop fs -ls /usr/weiwei

结果如下

    Found 1 items    -rw-r--r--   2 root supergroup        119 2017-02-05 12:06 /usr/weiwei/quangle.txt

返回的结果细腻与 UNIX 命令ls -l的输出结果非常相似，仅有细微的差别。第一列显示的是文件模式。
第二列显示的是这个文件的备份数（这在传统的UNIX文件系统中是没有的）。第3列和第4列显示的是文件
所属的用户和组别。第5列显示的是文件的大小，以字节为单位，如果是目录则大小为0。第6,7列显示的
是文件最后修改日期与时间。最后，第8列显示的是文件或目录的绝对路径。