HDFS概要

--HDFS--

Hadoop Distributed File System

HDFS一个分布式，高容错，可线性扩展的文件系统

简介：

Hadoop分布式文件系统（HDFS）是一种分布式文件系统，设计用于在商用硬件上运行。它与现有的分布式文件系统有许多相似之处。但是，与其他分布式文件系统的差异很大。HDFS具有高度容错能力，旨在部署在低成本硬件上。HDFS提供对应用程序数据的高吞吐量访问，适用于具有大型数据集的应用程序。HDFS放宽了一些POSIX要求，以实现对文件系统数据的流式访问。HDFS最初是作为Apache Nutch网络搜索引擎项目的基础设施而构建的。HDFS是Apache Hadoop Core项目的一部分。

HDFS架构

HDFS具有主/从架构。HDFS集群由单个NameNode，管理文件系统命名空间的主服务器和管理客户端对文件的访问组成。此外，还有许多DataNode，通常是群集中每个节点一个，用于管理连接到它们运行的​​节点的存储。HDFS公开文件系统命名空间，并允许用户数据存储在文件中。在内部，文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间操作，如打开，关闭和重命名文件和目录。它还确定了块到DataNode的映射。DataNode负责提供来自文件系统客户端的读写请求。DataNodes还执行块创建，删除。

HDFS架构包含三个部分：NameNode，DataNode，Client。
Replication：复制    Metadata ops 
:元数据操作  Rack:机架

NameNode(命名节点)：存储、生成文件系统的元数据。运行一个命名节点。

DataNode(数据节点)：存储实际的数据，将自己管理的数据块信息上报给NameNode ，运行多个数据节点。

Client(客户端)：支持业务访问HDFS，从NameNode
,DataNode获取数据返回给业务。可以多个客户端，和业务一起运行。

HDFS的读写流程

文件写流程：

1.业务应用调用HDFS Client提供的API，请求写入文件。

2.HDFS Client联系NameNode，NameNode在元数据中创建文件节点。

3.业务应用调用write API写入文件。

4.HDFS Client收到业务数据后，从NameNode获取到数据块编号、位置信息后，联系DataNode，并将需要写入数据的DataNode建立起流水线。完成后，客户端再通过自有协议写入数据到DataNode1，再由DataNode1复制到DataNode2, DataNode3。

5.写完的数据，将返回确认信息给HDFS Client。

6.所有数据确认完成后，业务调用HDFS Client关闭文件。

7.业务调用close, flush后HDFS Client联系NameNode，确认数据写完成，NameNode持久化元数据。

文件读流程：

1.业务应用调用HDFS Client提供的API打开文件。

2.HDFS Client联系NameNode，获取到文件信息（数据块、DataNode位置信息）。

业务应用调用read API读取文件。

3.HDFS Client根据从NameNode获取到的信息，联系DataNode，获取相应的数据块。(Client采用就近原则读取数据)。

4.5.HDFS Client会与多个DataNode通讯获取数据块。

6.数据读取完成后，业务调用close关闭连接。

DistributedFileSystem对象（java）：HDFS客户端通过调用DistributedFileSystem对象的open()方法打开需要读取的文件。

FSDataInputStream对象：DistributedFileSystem通过对NameNode发出RPC请求，确定要读取文件的block的位置。DistributedFileSystem返回一个FSDataInputStream(输入流，读操作)给HDFS客户端，让它从FSDataInputStream中读取数据。FSDataInputStream接着包装一个DFSInputStream(输入流)，用来与DataNode及NameNode的I/O 通信。

HDFS的关键特性

HDFS的高可靠性是如何实现的？

．HA高可靠机制：

HDFS的高可靠性（HA）主要体现在利用zookeeper实现主备NameNode，以解决单点NameNode故障问题。

ZooKeeper主要用来存储HA下的状态文件，主备信息。ZK个数建议3个及以上且为奇数个。

NameNode主备模式，主提供服务，备同步主元数据并作为主的热备。

ZKFC(ZooKeeper
Failover Controller)用于监控NameNode节点的主备状态。

JN(JournalNode)用于存储Active NameNode生成的Editlog。Standby NameNode加载JN上Editlog，同步元数据。

ZKFC控制NameNode主备仲裁

ZKFC作为一个精简的仲裁代理，其利用zookeeper的分布式锁功能，实现主备仲裁，再通过命令通道，控制NameNode的主备状态。ZKFC与NN部署在一起，两者个数相同。

元数据同步

主NameNode对外提供服务。生成的Editlog同时写入本地和JN，同时更新主NameNode内存中的元数据。

备NameNode监控到JN上Editlog变化时，加载Editlog进内存，生成新的与主NameNode一样的元数据。元数据同步完成。

主备的FSImage仍保存在各自的磁盘中，不发生交互。FSImage是内存中元数据定时写到本地磁盘的副本，也叫元数据镜像。

1. ZKFC控制NameNode主备仲裁

ZKFC作为一个精简的仲裁代理，其利用zookeeper的分布式锁功能，实现主备仲裁，再通过命令通道，控制NameNode的主备状态。ZKFC与NN部署在一起，两者个数相同。

2. 采用共享存储同步日志

主用NameNode对外提供服务，同时对元数据的修改采用写日志的方式写入共享存储，同时修改内存中的元数据。

备用NameNode周期读取共享存储中的日志，并生成新的元数据文件，持久化到硬盘，同时回传给主NameNode。

.元数据持久化机制：

EditLog:记录用户的操作日志，用以在FSImage的基础上生成新的文件系统镜像。

FSImage:用以阶段性保存文件镜像。

FSImage.ckpt:在内存中对fsimage文件和EditLog文件合并（merge）后产生新的fsimage，写到磁盘上，这个过程叫checkpoint.。备用NameNode加载完fsimage和EditLog文件后，会将merge（合并）后的结果同时写到本地磁盘和NFS（网络文件系统）。此时磁盘上有一份原始的fsimage文件和一份新生成的checkpoint文件：fsimage.ckpt.  而后将fsimage.ckpt改名为fsimage（覆盖原有的fsimage）。

EditLog.new:
NameNode每隔1小时或Editlog满64MB就触发合并,合并时,将数据传到Standby
NameNode时,因数据读写不能同步进行,此时NameNode产生一个新的日志文件Editlog.new用来存放这段时间的操作日志。Standby NameNode合并成fsimage后回传给主NameNode替换掉原有fsimage,并将Editlog.new 命名为Editlog。

Datanode会周期性地向主备namenode上报数据块和datanode的对应信息

.三副本机制：

为确保文件的容错性，同时提供更快的数据读取，默认每个数据块有3个副本，且分布在不同的存储节点DN上。

第一个副本在本节点。(本地节点)

第二个副本在远端机架的节点。（同机架不同节点）

第三个副本看之前的两个副本是否在同一机架，如果是则选择其他机架（其他机架），否则选择和第一个副本相同机架的不同节点，第四个及以上，随机选择副本存放位置。