Hadoop权威指南-3.2 HDFS的概念 - 高飞网

3.2 HDFS的概念

2016-10-21 10:09:41.0

3.2.1 数据块

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

    HDFS同样也有块(block)的概念,但是大得多,默认为64MB。与单一磁盘上的文件系统相似,HDFS上的文件也被划分为块大小的多个分块(chunk),作为独立的存储单元,但其与基文件系统不同的是,HDFS中小于一个块大小的文件不会占据整个块的空间,如果没有特殊指出,本书中提到的“块”特指HDFS中的块。

为何HDFS中的块如此实

HDFS的块比硬盘的块大,其上目的是为了最小化寻址开销。如果块设置得足够大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间,因而,传输一个由多个块组成的文件的时间取决于硬盘传输速率。(即降低磁盘寻址时间开销)

    对于分布式系统中的块进行抽象会带来很多好处。第一个最明显的好处是,一个文件的大小可以大于网络中任意一个磁盘的容量。文件的所有块并不需要存储在同一个磁盘上,因此它们可以利用集群上的任意一个磁盘进行存储。事实上,尽管常见,但对于整个HDFS而言,也可以仅存储一个文件,该文件的块占满集群中的所有磁盘。

    第二个好处是,使用抽象块而非整个文件作为存储单元,大大简化了存储子系统的设计。

    不仅如此,块还非常适合用于数据备份进而提供数据容错能力和提高可用性。将每个块复制到少数几个独立的机器上(默认为3个),可以保存在块、磁盘或机器发生故障后,数据不会丢失。如果发现一个块不可用,系统会从其他地方读取另一个复本,而这个过程对用户是透明的。一个因损坏或机器故障而丢失的块可以从其他修行地占复制到另一台可以正常运行的机器上,以保证复本的数量回到正常水平。

    与磁盘文件系统相似,HDFS中fsck指令可以显示块信息。

% hadoop fsck / -files -blocks

3.2.2 namenode和datanode

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

    客户端代表用户通过与namenode和datanode交互来访问整个文件系统。客户端提供一个类似于POSIX的文件系统接口,因此用户在编程时无需知道namenode和datanode也可实现其功能。

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

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

    另一种可行的方法是运行一个辅助namenode,但它不能被用作namenode。。。

3.2.3 联邦HDFS

    namenode在内存中保存文件系统中每个文件和每个数据块的引用关系,这意味着对于一个拥有大量文件的超大集群来说,内存将成为限制系统横向扩展的瓶颈。在2.x发行版本系统中引入的联邦HDFS允许系统通过添加namenode实现扩展,其中每个namenode管理系统命名空间中的一部分。例如,一个namenode可能管理/user目录下的所有文件,而另一个namenode可能管理/share目录下的所有文件。

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

    要想访问联邦HDFS集群,客户端需要使用客户端挂载数据表将文件路径映射到anmenode。

3.2.4 HDFS的高可用性

    通过联合使用在多个文件系统中备份namenode的元数据和通过备用namenode创建监测点能防止数据丢失,但是依旧无法实现文件系统的高可用性。namenode依旧存在单点(SPOF)的问题。如果namenode失效了,那么所有的客户端,包括MapReduce作业,均无法读、写或列(list)文件,因为namenode是唯一存储元数据到数据块映射的地方。在这一情况下,Hadoop系统无法提供服务直到新的namenode上线。

    这样的情况下,要想从一个失效的namenode恢复,系统管理员得启动一个拥有文件系统元数据副本的新的namenode,并配置datanode和客户端以便使用这个新的namenode。新的namenode直到满足以下情形才能响应服务:1)将命名空间的映像导入内存;2)重做编辑日志;3)接收到足够多的来自datanode的数据块报告并退出安全模式。对于一个大型并拥有大师和数据块的集群,namenode的冷启动需要30分钟甚至更长时间。

    Hadoop的2.x发行版本系统针对上述问题在HDFS中增加了对高可用性(HA)的支持。在这一实现中,配置了一对活动-备用(active-standby)namenode。当活动namenode失效,备用namenode会接管它的任务并开始服务于来自客户端的请求,不会有任何明显中断。实现这一目标需要在架构上做如下修改:

    · namenode之间需要通过高可用的共享存储实现编辑日志的共享(如zookeeper)。当备用namenode接管工作之后,它将通读共享编辑日志直到末尾,以实现与活动namenode的状态同步,并继续读取取活动namenode写入的新条目。

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

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

    在活动namenode失效之后,备用namenode能够快速(几十秒的时间)实现任务接管,因为最新的状态存储在内存中:包括最新的编辑日志条目和最新的数据块映射信息。    

    在活动namenode和备用namenode都失效情况下,管理员依旧可以申明一个备用namenode实现冷启动。

故障切换与规避

    一个称为故障转移控制器(failover_controller)的系统中有一个新的实体管理着将活动namenode转移为备用namenode的转换过程。故障转移控制器是可插拔的,但其最被的实现是基于ZooKeeper的并由此确保有且仅有一个活动namenode。

    但在非平稳故障转移的情况下,无法确切知道失效namenode是否已经停止运行。如在网络非常慢或者网络被分割的情况下同样会激发故障转移,但先前的活动namenode依然运行着并且依旧是活动namenode。高可用实现做了更进一步的优化,以确保先前活动的namenode不会执行危害系统并导致系统崩溃的操作——该方法称为“规避(fencing)”。如杀死namenode进程,收回访问共享存储目录的权限,通过远程管理命名以屏蔽相应网络端口。