hadoop基础----hadoop理论(三)-----hadoop分布式文件系统HDFS详解

我们在前面已经为学习hadoop做了一些准备和初步了解:

虚拟机

java基础和实战

linux基础和shell编程

hadoop基础----hadoop理论(一)----Hadoop简介

hadoop基础----hadoop理论(二)-----hadoop学习路线(持续更新)

我们已经知道Hadoop=HDFS（文件系统，数据存储技术相关）+ Mapreduce（数据处理）

本章就先来了解一下HDFS。

什么是HDFS

当数据集的大小超过一台独立物理计算机的存储能力时，就有必要对它进行分区(partition)并存储到若干台单独的计算机上。

管理网络中跨多台计算机存储的文件系统称为分布式文件系统(distributed filesystem)。该系统架构于网络之上，势必会引入网络编程的复杂性，因此分布式文件系统比普通磁盘文件系统更为复杂。例如，使文件系统能够容忍节点故障且不丢失任何数据，就是一个极大的挑战。

Hadoop就有一个称为HDFS的分布式文件系统，全称为Hadoop Distributed File System。

HDFS是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。

它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。

Hadoop整合了众多文件系统，在其中有一个综合性的文件系统抽象，它提供了文件系统实现的各类接口，HDFS只是这个抽象文件系统的一个实例。hadoop提供了一个高层的文件系统抽象类org.apache.hadoop.fs.FileSystem，这个抽象类展示了一个分布式文件系统，并有几个具体实现，如下表所示。

文件系统	URI方案	Java实现 （org.apache.hadoop）	定义
Local	file	fs.LocalFileSystem	支持有客户端校验和本地文件系统。带有校验和的本地系统文件在fs.RawLocalFileSystem中实现。
HDFS	hdfs	hdfs.DistributionFileSystem	Hadoop的分布式文件系统。
HFTP	hftp	hdfs.HftpFileSystem	支持通过HTTP方式以只读的方式访问HDFS，distcp经常用在不同的HDFS集群间复制数据。
HSFTP	hsftp	hdfs.HsftpFileSystem	支持通过HTTPS方式以只读的方式访问HDFS。
HAR	har	fs.HarFileSystem	构建在Hadoop文件系统之上，对文件进行归档。Hadoop归档文件主要用来减少NameNode的内存使用。
KFS	kfs	fs.kfs.KosmosFileSystem	Cloudstore（其前身是Kosmos文件系统）文件系统是类似于HDFS和Google的GFS文件系统，使用C++编写。
FTP	ftp	fs.ftp.FtpFileSystem	由FTP服务器支持的文件系统。
S3（本地）	s3n	fs.s3native.NativeS3FileSystem	基于Amazon S3的文件系统。
S3（基于块）	s3	fs.s3.NativeS3FileSystem	基于Amazon S3的文件系统，以块格式存储解决了S3的5GB文件大小的限制。

Hadoop提供了许多文件系统的接口，用户可以使用URI方案选取合适的文件系统来实现交互。

我们可以看到HDFS只是其中的一个实例，但是HDFS是核心。

HDFS的设计目标和特点

假设节点失效是常态(因为大部分用的是廉价机)
--目标任何一个节点失效都不影响HDFS的使用
--HDFS可以自动完成副本的复制

简单一致性模型，假设一次写入多次读取模块(也就是数据源几乎不修改)

流式数据访问

不支持文件并发写入

不支持文件修改

轻便的访问异构的软硬件平台(也就是有很多接口可以实现与其它数据库软件框架之间的相互访问)

HDFS不适合存储小文件

HDFS不适合大量随机读

HDFS不适合需要经常对文件修改的应用场景

HDFS的优缺点

HDFS和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。

优点

处理超大文件

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

流式的访问数据

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

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

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

缺点

不适合低延迟数据访问

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

改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择。

通过上层数据管理项目来尽可能地弥补这个不足。在性能上有了很大的提升，它的口号就是goes real time(实时)。

使用缓存或多master设计可以降低client的数据请求压力，以减延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了。

无法高效存储大量小文件

因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。

一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。

当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。

还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。

举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。

改进策略：要想让HDFS能处理好小文件，有不少方法。
利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。

对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。

横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。

多Master设计，有一些Master的Block大小改为1M，调优处理小文件。

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

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

HDFS的组成

数据块(block)

block是HDFS最基本的存储单位。大文件会被分割成多个block进行存储，block大小默认为64MB。

每一个block会在多个datanode上存储多份副本，默认是3份。

元数据节点(namenode)

namenode存储元数据,元数据保存在内存中与磁盘上,元数据包括命名空间镜像(fsimage)及修改日志(edit log)。

通过元数据负责管理文件目录(HDFS的命名空间)、文件和block的对应关系以及block和datanode的对应关系。

namenode的目录结构:



VERSION文件是java properties文件，保存了HDFS的版本号。

layoutVersion是一个负整数，保存了HDFS的持续化在硬盘上的数据结构的格式版本号。
namespaceID是文件系统的唯一标识符，是在文件系统初次格式化时生成的。
cTime此处为0
storageType表示此文件夹中保存的是元数据节点的数据结构。

例如:
namespaceID=1232737062
cTime=0
storageType=NAME_NODE
layoutVersion=-18

数据节点(datanode)

datanode负责存储，数据节点是文件系统中真正存储数据的地方。存储文件内容，文件内容保存在磁盘。

它的作用是维护block id 到datanode本地文件的映射关系。

当然大部分容错机制都是在datanode上实现的。

datanode的目录结构:



数据节点的VERSION文件格式如下：
namespaceID=1232737062
storageID=DS-1640411682-127.0.1.1-50010-1254997319480
cTime=0
storageType=DATA_NODE
layoutVersion=-18

blk_<id>保存的是HDFS的数据块，其中保存了具体的二进制数据。
blk_<id>.meta保存的是数据块的属性信息：版本信息，类型信息，和checksum
当一个目录中的数据块到达一定数量的时候，则创建子文件夹来保存数据块及数据块属性信息。

从元数据节点（secondary namenode）

从元数据节点并不是元数据节点出现问题时候的备用节点，它和元数据节点负责不同的事情。
其主要功能就是周期性将元数据节点的命名空间镜像文件和修改日志合并，以防日志文件过大。
合并过后的命名空间镜像文件也在从元数据节点保存了一份，以防元数据节点失败的时候，可以恢复。

也就是将NameNode的fsimage与edit log从NameNode复制到临时目录，将fsimage同edit log合并 并产生新的fsimage，将产生的新的fsimage上传给NameNode， 清除NameNode中的edit log

HDFS的架构

如图所示，HDFS采用master/slave(主从)架构对文件系统进行管理。

一个HDFS集群是由一个NameNode和一定数目的DataNodes组成的。

NameNode是一个中心服务器，负责管理文件系统的名字空间(Namespace )及客户端对文件的访问。

集群中的DataNode一般是一个节点运行一个DataNode进程，负责管理它所在节点上的存储。

HDFS展示了文件系统的名字空间，用户能够以文件的形式在上面存储数据。

从内部看，一个文件其实被分成了一个或多个数据块，这些块存储在一组DataNode上。

NameNode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录，它也负责确定数据块到具体DataNode节点的映射。
DataNode负责处理文件系统客户端的读/写请求。在NameNvde的统一调度下进行数据块的创建、删除和复制。

通俗的理解:

NameNode：是Master节点，是大领导。管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；
SecondaryNameNode：是一个小弟，分担大哥namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
DataNode：Slave节点，奴隶，干活的。负责存储client发来的数据块block；执行数据块的读写操作。
热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。
冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。
fsimage:元数据镜像文件（文件系统的目录树。）
edits：元数据的操作日志（针对文件系统做的修改操作记录）
namenode内存中存储的是=fsimage+edits。
SecondaryNameNode负责定时默认1小时，从namenode上，获取fsimage和edits来进行合并，然后再发送给namenode。减少namenode的工作量。

HDFS读写数据流的工作原理

HDFS文件的读取剖析

首先，客户端通过调用FileSystem。对象中的open(）函数来读取它需要的数据。

F1ieSystem是HDFS中DistributedFileSystem的一个实例(参见图第①步)。

DistributedFileSystem会通过RPC协议调用NameNode来确定请求文件块所在的位置。

这里需要注意的是，NameNode只会返回所调用文件中开始的几个块而不是全部返回(参见图第②步)。

对于每个返回的块，都包含块所在的DataNode地址。

随后，这些返回的DataNode会按照Hadoop定义的集群拓扑结构得出客户端的距离，然后再进行排序(有关拓扑结构的后面会讲解)。

如果客户端本身就是一个DataNode，那么它将从本地读取文件。

其次，DistributedFileSystem会向客户端返回一个支持文件定位的输入流对象FSDataInputStream，用于给客户端读取数据。

FSDataInputStream包含一个DFSInputStream对象，这个对象用来管理DataNode和NameNode之间的I/O。

当以上步骤完成时，客户端便会在这个输入流之上调用read()函数〔参见图第③步〕。

DFSInputStream对象中包含文件开始部分的数据块所在的DataNode地址。首先它会连接包含文件第一个块最近的DataNode。
随后，在数据流中重复调用read()函数，直到这个块全部读完为止(参见图第④步)。
当最后一个块读取完毕时，DFSInputStream会关闭连接，并查找存储下一个数据块距离客户端最近的DataNode(参见图第⑤步)。

以上这些步骤对客户端来说都是透明的。

客户端按照DFSInputStream打开和DataNode连接返回的数据流的顺序读取该块，它也会调用NameNode来检索下一组块所在的DataNode的位置信息。

当客户端完成所有文件的读取时，则会在FSDataInputStream中调用close()函数(参见图9第⑥步)。
当然，HDFS会考虑读取中节点出现故障的情况。

目前HDFS是这样处理的，如果客户端和所连接的DataNode在读取时出现故障，那么它就会去尝试连接存储这个块的下一个最近的DataNode，同时它会记录这个节点的故障，这样它就不会再去尝试连接和读取块。

客户端还会验证从DataNode传送过来的数据校验和。如果发现一个损坏的块.那么客户端将会再尝试从别的DataNode读取数据块，向NameNode报告这个信息，NameNade也会更新保存的文件信息。

这里要关注的一个设计要点是，客户端通过NameNode引导获取最合适的DataNode地址，然后直接连接DataNode读取数据。

这种设计的好处是，可以使HDFS扩展到更大规模的客户端并行处理，这是因为数据的流动是在所有DataNode之间分散进行的。

同时NameNode的压力也变小了，使得NameNode只用提供请求块所在的位置信息就可以了，而不用通过它提供数据，这样就避免了NameNode随着客户端数量的增长而成为系统瓶颈。

HDFS文件的写入剖析

第一，客户端通过调用DistributedFileSystem对象中的creat()函数创建一个文件(参见图)。

DistributedFileSystem通过RPC调用在NameNode的文件系统命名空间中创建一个新文件，此时还没有相关的DataNode与之关联。

第二，NameNade会通过多种验证保证新的文件不存在于文件系统中，并且确保请求客户端拥有创建文件的权限。

当所有验证通过时，NameNade会创建一个新文件的记录，如果创建失败，则抛出一个IOException异常。

如果创建成功，则DistributedFileSystem返回一个FSDataOutputStream给客户端用来写入数据。

这里FSDataOutputStream和读取数据时的FSDataInputStream一祥都包含一个数据流对象DFSOutputStream，客户端将使用它来处理与DataNode和NameNode之间的通信。

第三，当客户端写入数据时，DFSOutputStream会将文件分割成包，然后放入一个内部队列，我们称为“数据队列”。

DataStreamer会将这些小的文件包放入数据流中，DataStreamer的作用是请求NameNode为新的文件包分配合适的DataNade存放副本。

返回的DataNode列表形成一个“管道”，假设这里的副本数是3，那么这个管道中就会有3个DataNode。 DataStreamer将文件包以流的方式传送给队列中的第一个DataNode,第一个DataNode会存储这个包，然后将它推送到第二个DataNode中，随后照这样进行，直到管道中的最后一个DataNode。

第四，DFSOutputStream同时也会保存一个包的内部队列，用来等待管道中的DataNode返回确认信息，这个队列被称为确认队列（ack queue)。

只有当所有管道中的DataNode都返回了写入成功的返回信息文件包，才会从确认队列中删除。

当然，HDFS会考虑写入失败的情况，当数据写入节点失败时，HDFS会做出以下反应。

首先管道会被关闭，任何在确认通知队列中的文件包都会被添加到数据队列的前端，这样管道中失败的DataNode都不会丢失数据。

当前存放在正常工作的DataNode之上的文件块会被赋予一个新的身份，井且和NameNode进行关联，这样，如果失败的DataNode过段时间后会从故障中恢复出来。

其中的部分数据块就会被删除。然后，管道会把失败的DataNode删除，文件会继续被写到管道中的另外两个DataNode中。

最后，NameNode会注意到现在的文件块副本数没有达到配置属性要求，会在另外的DataNode上重新安排创建一个副本，随后的文件会正常执行写入操作。

当然，在文件块写入期间，多个DataNode同时出现故障的可能性存在，但是很小。只要dfs.replicatinn.min的属性值(默认为1)成功写入，这个文件块就会被异步复制到集群的其他DataNode中，直到满足dfs. replication. min的属性值(默认为3)。

客户端成功完成数据写入的操作后，就会调用6种close()函数关闭数据流(参见图第⑥步)。

这步操作会在连接NameNode确认文件写入完全之前将所有剩下的文件包放人DataNode管道.等待通知确认信息。

NameNade会知道哪些块组成一个文件(通过DataStreamer获得块位置信息)，这样NameNode只要在返回成功标志前等待块被复制（要求复制数量不小于最小量dfs.replicativn.min )即可。

HDFS的API详解和HDFS常用操作

该部分内容将在实战部分讲述。