HDFS详解

1.       HDFS详解

1.1.  分布式文件系统与HDFS

1.1.1. 产生背景

数据量越来越多，在一个操作系统管辖的范围存不下了，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，因此迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统，这样分布式文件系统就应运而生。

1.1.2. 定义

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。

通俗点讲，就是一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。

1.1.3. 特点

Ø  通透性：

让实际上是通过网络来访问文件的动作，由程序与用户看来，就像是访问本地的磁盘一般。

Ø  容错：

即使系统中有某些节点脱机，整体来说系统仍然可以持续运作而不会有数据损失。

分布式文件管理系统很多，hdfs只是其中一种。适用于一次写入多次查询的情况，不支持并发写情况，小文件不合适。

当前比较流行的分布式文件系统包括：Lustre、Hadoop、MogileFS、FreeNAS、FastDFS、NFS、OpenAFS、MooseFS、pNFS、以及GoogleFS。

1.1.4. HDFS简介

HDFS是基于流数据模式访问和处理超大文件的需求而开发的，他可以运行在廉价的商用服务器上。总的来说，HDFS具有以下几个特点：

1.1.4.1.     HDFS的优点

　　1）处理超大文件

　　这里的超大文件通常是指百MB、设置数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

　　2）流式的访问数据

　　HDFS的设计建立在更多地响应"一次写入、多次读写"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

　　3）运行于廉价的商用机器集群上

　　Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。

1.1.4.2.      HDFS的缺点

　　1）不适合低延迟数据访问

　　如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。

　　改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。

　　2）无法高效存储大量小文件

　　因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。

　　改进策略：要想让HDFS能处理好小文件，有不少方法。

　　3）不支持多用户写入及任意修改文件

　　在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

1.2.  HDFS体系结构与基本概念

我们要向了解HDFS的体系结构，首先从概念入手，下面我们就介绍一下HDFS中的几个重要概念。

1.2.1. 基本概念

1.2.1.1.     块（Block）

    一个磁盘有它的块大小，代表着它能够读写的最小数据量。文件系统通过处理大小为一个磁盘块大小的整数倍数的数据块来运作这个磁盘。文件系统块一般为几千字节，而磁盘块一般为512个字节。这些信息，对于仅仅在一个文件上读或写任意长度的文件系统用户来说是透明的。但是，有些工具会维护文件系统，如df 和 fsck， 它们都在系统块级上操作。

HDFS也有块的概念，不过是更大的单元，默认为64 MB。与单一磁盘上的文件系统相似，HDFS上的文件也被分为以块为大小的分块，作为单独的单元存储。但与其不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间。如果没有特殊指出，"块"在本书中就指代HDFS中的块。

在分布式文件系统中使用抽象块会带来很多好处。

Ø  第一个最明显的好处是，一个文件可以大于网络中任意一个磁盘的容量。文件的分块(block，后文有些地方也简称为"块")不需要存储在同一个磁盘上，因此它们可以利用集群上的任意一个磁盘。其实，虽然不常见，但对于HDFS集群而言，也可以存储一个其分块占满集群中所有磁盘的文件。

Ø  第二个好处是，使用块抽象单元而不是文件会简化存储子系统。简单化是所有系统的追求，但对于故障种类繁多的分布式系统来说尤为重要的。存储子系统控制的是块，简化了存储管理。(因为块的大小固定，计算一个磁盘能存多少块就相对容易)，也消除了对元数据的顾虑(块只是一部分存储的数据-而文件的元数据，如许可信息，不需要与块一同存储，这样一来，其他系统就可以正交地管理元数据。)

Ø  不仅如此，块很适合于为提供容错和实用性而做的复制操作。为了应对损坏的块以及磁盘或机器的故障，每个块都在少数其他分散的机器(一般为3个)进行复制。如果一个块损坏了，系统会在其他地方读取另一个副本，而这个过程是对用户透明的。一个因损坏或机器故障而丢失的块会从其他候选地点复制到正常运行的机器上，以保证副本的数量回到正常水平。

 同样，有些应用程序可能选择为热门的文件块设置更高的副本数量以提高集群的读取负载量。

与磁盘文件系统相似，HDFS中 fsck 指令会显示块的信息。例如，执行以下命令将列出文件系统中组成各个文件的块：

% hadoop fsck / -files -blocks

 

总而言之，存储在HDFS上的大文件会被分割成多个block进行存储，block大小默认为64MB。每一个block会在多个datanode上存储多份副本，默认是3份。

注意：hdfs在对数据存储进行block划分时，如果文件大小超过block，那么按照block大小进行划分；不如block size的，划分为一个块，是实际数据大小。

1.2.1.2.     NameNode

Namenode 管理者文件系统的Namespace。它维护着文件系统树(filesystem tree)以及文件树中所有的文件和文件夹的元数据(metadata)。

管理这些信息的文件有两个，分别是Namespace 镜像文件(Namespace image)和操作日志文件(edit log)，这些信息被一般是在内存中的，当然，这两个文件也会被持久化存储在本地硬盘。

Namenode记录着每个文件中各个块所在的数据节点的位置信息，但是他并不持久化存储这些信息，因为这些信息会在系统启动时从数据节点重建。

Namenode结构图可抽象为如图：

客户端(client)代表用户与namenode和datanode交互来访问整个文件系统。客户端提供了一些列的文件系统接口，因此我们在编程时，几乎无须知道datanode和namenode，即可完成我们所需要的功能。

Namenode中最重要的两个文件时Fsimage文件和Edits文件，

Fsimage是元数据镜像文件。存储某一时段NameNode内存元数据信息。此文件一般需要多目录存储，进行备份，以保证元数据的安全性。

下面是fsimage的存储路径配置文件及方法：

 

安装hadoop是一般是在配置文件core-site.xml中进行配置，

Core-site.sh文件是覆盖了hdfs-default.sh文件，其配置的参数值传递给了hdfs-default.sh。在此文件中可以配置多个目录实现fsimage文件的备份，例如：${hadoop.tmp.dir}/dfs/name,/name2,/name3

edits:操作日志文件，是负责记录用户操作信息的文件。它是以事物的方式进行数据的存储的，也就是它只存储完整的操作的信息，如果某个操作中途断了该操作的信息不会被存储。

Edits文件中的数据要定时被合并到fsimage文件中，此操作有secenderynamenode节点完成。从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，同时重置NameNode的edits。

一般情况下Secenderynamenode是默认安装在namenode所在机器上的（不是太安全）。

Edits的信息定时被合并到fsimage文件时由checkpoint实现的，并将最后一次checkpoint的时间保存到fsimage文件中：

fstime:保存最近一次checkpoint的时间

1.2.1.3.     DataNode

Datanode是文件系统的工作节点，他们根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送他们所存储的块(block)的列表。

Datanode上的数据一般会有两个备份，一份在同一个机架的不同的datanode上，另一个在不同机架的datanode上。

Datanode中存储文件时会生成两份文件，一份为所上传的文件，另一份为校验文件（一般为MD5文件），用来检验数据是否完整。

Datanode中存放的文件必须是通过HDFS命令上传的，否则HDFS就不会识别该文件，并且上传之后的文件已经被HDFS处理，不会找到原文件。

1.2.1.4.     Secenderynamenode

secondary namenode就是用来帮助namenode将内存中的元数据信息checkpoint到硬盘上的。

checkpoint的过程如下：

Ø  secondary namenode通知namenode生成新的日志文件edits.new，以后的日志都写到新的日志文件中。

Ø  secondary namenode用http get从元数据节点获得fsimage文件及旧的日志文件。

Ø  secondary namenode将fsimage文件加载到内存中，并执行日志文件中的操作，然后生成新的fsimage文件。

Ø  secondary namenode将新的fsimage文件用http post传回namenode

Ø  namenode可以将旧的fsimage文件及旧的日志文件，换为新的fsimage文件和新的日志文件(第一步生成的)，然后更新fstime文件，写入此次checkpoint的时间。

这样namenode中的fsimage文件保存了最新的checkpoint的元数据信息，日志文件也重新开始，不会变的很大了。

合并原理图：