HDFS 初识

当一个数据集在一个物理机上增长得容不下的时候，就需要把它分区存放到多个独立的机器上，这就要通过网络来管理分布在这些机器上的数据，像这样通过网络来管理数据的文件系统称之为分布式文件系统（distributed filesystems）。

Hadoop中的分布式文件系统为HDFS，其设计用来存储较大的文件、通过流的方式访问数据，在普通的商业硬件集群上运行。

存储文件较大：通常上百GB，或者上百TB，甚至是PB。

流访问：即数据批量读取而非随机读写，适用于“一次写，多次读”的数据，且读取的数据量比较大。Hadoop擅长数据分析而不是事务处理。

普通的商业硬件：说的是HDFS不需要用一些比较昂贵的、可靠性高的硬件来做集群，普通的PC就可以。

HDFS的结构图：

HDFS的相关概念：

Blocks（块）

我们知道，磁盘有块的概念，一个磁盘的块指的是可以读取或写入的最小的量，而单个磁盘上的文件系统正是在块的基础上来处理数据的，通常，文件系统中块的大小是磁盘中块大小的整数倍。文件系统的块大小通常有几KB，而磁盘的块大小为512B。

HDFS也有块的概念，但是块的大小比较大，默认为128MB。像磁盘的文件系统一样，HDFS中的文件被分为块大小的块，都是以独立的单元存储，和磁盘的文件系统不同的是，如果存入文件的大小低于块的大小，不会占用一个整块，例如，有一个1MB大小的文件，块大小为128MB，那么这个文件仅占用1MB大小的块空间，而不是128MB。

那么，在HDFS中，为什么要把块（block）设置的如此大？

这主要是为了最小化磁盘的寻道开销。如果块足够大，那么从磁盘传输数据的时间会明显长于寻找块开始位置的时间，这样，传输由多个块组成的大文件的时间就要看磁盘的传输速率了。反过来，如果块设置的比较小，那么就需要产生较多的数据块，这在传输由多个块组成的大文件是，无疑增加了寻址的开销，就不再单一的取决于传输速率了，还要取决于磁盘的寻址速度。

另一个原因是为了降低内存消耗，如果块设置的比较小，就需要记录更多块的元数据信息，占用更多内存。

如果块设置的较大，也不太好，通常，MapReduce中的任务一次只处理一个快中数据，如果块较大，则会导致任务数较少，可能会造成作业分配不均匀，影响作业的运行速度。

那么块的大小设置为多少才合适呢？通常要根据数据量、节点数等因素综合考虑了。

分布式文件系统中使用块的抽象概念，带来了几点好处，首先，最明显的好处是一个文件可以大于网络中的任何一个磁盘。对文件分块，不需要把一个文件中的所有块都存储在一个磁盘，它可以存储在集群中的任何磁盘上。其次，使用块作为存储单元，简化了存储子系统（存储子系统包括：磁盘、磁盘控制器、存储网络、磁盘阵列、卷管理层、目录虚拟层）。存储子系统处理块，简化了存储的管理（对于一个磁盘来说，因为块的大小是固定，可以很容易的计算出它能存储多少）和消除元数据的问题（因为存储的是数据的块，文件元数据如权限等信息不需要存储，而是由其它系统来单独处理元数据信息）。

此外，块适合用于提供容错性和可用性的复制。为应对损坏的块、磁盘和机器故障的情况，每一个块会被复制到少数独立的物理机上（通常是3台机器）。如果一个块变得不可用了，可以读取其在其它机器上的副本，使用这种方式对客户端来说是透明的。

Namenodes 和 Datanodes

一个HDFS集群以Master - Worker的模式运行，主要有两种类型的节点：一个namenode节点和若干的datanode节点。namenode节点负责管理文件系统的命名空间，维护文件系统树和树中所有文件和目录的元数据信息，这些元数据信息被持久化存储在本地磁盘上，主要有两个文件：命名空间镜像和编辑日志（the namespace image and the edit log）。namenode也知道对于给定的文件，其所有块在哪些datanode节点中的位置信息。然而，namenode并不持久存储块的位置信息，因为在系统启动时，这些信息是从datanode节点中重建的。

datanode是文件系统的工作节点，他们根据客户端或namenode的请求来存储或检索数据块，并且他们还会定期向namenode节点发送他们存储数据块的清单。

namenode的容错机制

namenode节点是非常重要的，如果namenode节点发生故障，那么，文件系统中的所有文件都将丢失，因为无法从datanode节点的数据块中构建文件。为此，使namenode适应这种失败是很重要的，Hadoop提供两种机制来应对：

第一种是将持久化存储的文件系统元数据的文件备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统。

第二种方式是运行一个辅助的Namenode(Secondary Namenode)。 事实上Secondary Namenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。通常，Secondary Namenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。

namenode的结构图：

Block Caching

通常一个datanode从磁盘上读取块，但是对于频繁访问的文件，其数据块可能会被缓存在datanode节点的内存中，一个离堆块缓存（off-heap block cache）。默认，一个块只能缓存在一个datanode节点的内存中，尽管可以配置每个文件的缓存数量。Job调度器（如MapReduce、Spark或者其他框架）可以充分利用缓存块来提高读取的性能。

关于hdfs的缓存，想进一步了解，可以参看这篇文章：http://blog.csdn.net/qiruiduni/article/details/48030101

HDFS Federation

namenode节点在内存中保存着文件系统中每个文件和数据块的引用，这意味着，一个含有很多文件的集群，内存成为其扩展的限制因素。HDFS federation（HDFS联盟），在2.x版本中被引入，它允许通过增加namenode节点来扩展集群，每一个namenode仅管理文件系统命名空间的一部分。例如，一个namenode管理根节点下/user目录中的所有文件，另一个namenode仅管理/share目录下的所有文件。

HDFS Federation 的架构如下图：

在Federation（联盟）情况下，每个namenode管理一个命名空间卷（namespace volume），它由当前namenode的命名空间的元数据信息和在其命名空间中所有文件块的block pool组成。 每个命名空间卷之间相互独立，这意味着每个namenode节点之间不相互通信，此外，发生故障的namenode节点不会影响其它可用的namenode节点。所有的datanode节点都需要向集群中的所有namenode节点注册，并定期的向所有的namenode节点发送其存储块的报告，并执行来自所有namenode节点的命令。

一个block pool由属于同一个namespace的数据块组成。

Federation的优点：

1、扩展性和隔离性

支持多个namenode水平扩展整个文件系统的namespace，可按照应用程序的用户和种类分离namespace volume，进而增强了数据的隔离性。

2、通用存储服务
Block Pool抽象层为HDFS的架构开启了创新之门。分离block storage layer使得：
a、 新的文件系统（non-HDFS）可以在block storage上构建
b、 新的应用程序（如HBase）可以直接使用block storage层
c、 分离的block storage层为将来完全分布式namespace打下基础

缺点：

实际上，HDFS Federation并没有完全解决单点故障的问题，虽然namenode存在多个，但从单个namenode节点看，仍存在单点故障的问题，如果某个namenode节点挂掉了，则其管理的文件便不可以访问。

关于HDFS Federation的更详细介绍，请查阅这篇文章：http://blog.csdn.net/qiruiduni/article/details/48046455

HDFS High Availability

如上述，在多个文件系统中备份namenode节点的元数据和使用secondary namenode节点以检查点的方式来防止数据丢失，但是这并没有提供高可用的文件系统，namenode节点仍存在单点故障的问题（single point of failure），如果namenode节点挂掉，所有的客户端（包括MapReduce任务）将不能读写文件，因为namenode节点是唯一存储文件元数据和文件到块映射的仓库。在这种情况下，Hadoop将暂停服务直到有新的namenode节点可用。

从出现故障的节点中恢复，管理员需要使用一个文件系统元数据的副本和datanode节点的配置信息来启动一个新的namenode，并让客户端使用这个新的namenode。新的namenode节点并不能及时提供服务，直到（i）其命名空间的镜像文件加载到内存（ii）重做编辑日志（iii）获得来自datanode节点的块报告，才能脱离安全模式，提供服务。在一个含有大量文件和块的大集群中，启动一个新的namenode节点，至少要30分钟，甚至更多。

为解决这种问题，从Hadoop 2.0版本开始，提供了HDFS  高可用（high availability）的实现，该实现提供一对namenode节点，其中一个作为活动（active）节点，另一个作为备用节点，一旦活动节点出现故障，备用节点可以很快的接管，继续为客户端提供服务，这期间没有明显的中断现象。

High Avaliability 具体实现方式为：

• namenode节点之间必须共享存储、共享编辑日志。当一个备用的namenode节点启动完毕，它会读取编辑日志文件，保持与active namenode节点状态的同步，然后继续读取由active namenode节点写入编辑日志文件中的新的状态。
• datanode节点必须向两个namenode节点发送块报告，因为块的映射存储在datanode节点的内存中，而不是磁盘上。
• 客户端必须配置处理namenode节点故障切换的机制，这对用户来说是透明的。
• secondary namenode的扮演备用节点的角色，它需要设置检查点，定期检查active namenode节点的命名空间。

对于高可用的共享存储，有两个选择：一个是使用NFS文件服务器，另一个是仲裁日志管理器（QJM：quorum journal manager）。而HDFS的实现使用的是QJM，主要是为了提供高可用的编辑日志，并且使用QJM也是大多数HDFS推荐的。QJM运行一组日志节点（journal nodes），每一个编辑操作都会被记录到多个日志节点中，通常是3个日志节点，所以系统可以容忍部分日志的丢失。

如果namenode节点关掉，备用的namenode节点可以很快的接管（几十秒），因为在备用namenode节点的内存存储着最新的状态：最新的编辑日志和最新的块映射信息。但是，在实际的观察中，namenode节点之间的切换时间会较长些（在一分钟左右），因为系统需要确认namenode节点是否已经失效。

不太可能的情况是，在active namenode节点挂掉时候，备用的namenode节点也挂掉了，对于这种情况，管理员仍然可以重新启动备用的namenode节点，这要比没有高可用的环境好些。

Failover and fencing（故障切换和栅栏）

namenode节点之间的故障切换，是由一个failover controller（故障切换控制器）控制的，它有多种控制器，默认实现为使用的Zookeeper来保证仅有一个活动的namenode节点。每个namenode节点都有一个轻量级的故障切换控制器进程，来监控其所在namenode节点的故障（使用简单的心跳机制），并触发故障切换操作。

在日常的维护中，管理员可以有序的手动启动故障切换，这被称作优雅的故障切换（graceful failover），当然也有不雅的故障切换（ungraceful failover），例如，由于网络慢或网络故障引发的故障切换，即使之前的active namenode节点仍正在运行。为应对这种情况，HA提供了一种“栅栏”（fencing）的实现方式，来尽力阻止之前活动的namenode节点做任何破坏的操作。

在同一时间，QJM只允许一个namenode节点操作编辑日志，然而，也存在一种可能，就是之前的active nomenode节点还在处理来自客户端的读取请求。所以，创建一个栅栏（fence）命令可以中断namenode节点的进程，废除对共享存储目录的访问，此外，它还可以通过远程管理命令来关闭它的网络端口，关闭节点、甚至强行断电。

如果使用NFS文件服务器来共享编辑日志，那就必须要要使用栅栏，因为NFS文件服务器不能做到在同一时间只允许一个namenode节点来操作编辑日志文件。