HadoopHDFS框架技术

Hadoop  主要由HDFS和MapReduce  两个核心部分组成。其中最底部就是HDFS，

它被用来存储Hadoop  集群中所有存储节点上的文件。通过Java API可以对所有的HDFS文件进行操作，

必须通过抽象类FileSystem来操作，FileSystem继承org.apache.hadoop.conf.Configuration，适用file:// 、 ftp、hdfs

多种文件系统。

一个只有500G的单节点无法一次性读取连续的PB级的数据，为了解决这个问题，可以把大规模数据集分别存储在多个不同的节点系统中，即实现跨网络的多个节点资源的文件系统：分布式文件系统

HDFS架构图：

 

HDFS的设计目标：    

1、硬件故障是常态，而不是异常，运行在普通廉价的机器上

2、适合流式数据访问

3、适合大规模数据集，非常巨大的分布式文件系统

5、移动计算比移动数据更划算

6.易扩展，为用户提供性能不错的文件存储服务

NameNode是所有HDFS元数据的管理者，用户数据永远不会存储到NameNode上

A typical deployment has a dedicated machine that runs only the NameNode software.

Each of the other machines in the cluster runs one instance of the DataNode software.

The architecture does not preclude running multiple DataNodes on the same machine but in a

real deployment that is rarely the case.

部署架构建议：NameNode+N个DataNode

                         NN和DN部署在不同的节点

选择 HDFS 存储数据，是因为 HDFS 具有以下优点：

(1) 高容错性

1) 数据自动保存多个副本。它通过增加副本的形式，提高容错性。

2) 某一个副本丢失以后，它可以自动恢复，这是由 HDFS 内部机制实现的，我们不必关心。

(2) 适合批处理

1) 它是通过移动计算而不是移动数据。

2) 它会把数据位置暴露给计算框架。

(3) 适合大数据处理

1) 数据规模：能够处理数据规模达到 GB、TB、甚至PB级别的数据。

2) 文件规模：能够处理百万规模以上的文件数量，数量相当之大。

3) 节点规模：能够处理10K节点的规模。

(4) 流式数据访问

1) 一次写入，多次读取，不能修改，只能追加。

2) 它能保证数据的一致性。

(5) 可构建在廉价机器上

1) 它通过多副本机制，提高可靠性。

2) 它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。

2、当然 HDFS 也有它的劣势，并不适合所有的场合：

(1) 不适合低延时数据访问

1) 比如毫秒级的来存储数据，这是不行的，它做不到。

2) 它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况  下是不行的，

     比如毫秒级以内读取数据，这样它是很难做到的。

(2) 无法高效的对大量小文件进行存储

1) 存储大量小文件的话，它会占用  NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，

   因为NameNode的内存总是有限的。

2) 小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。 改进策略

(3) 并发写入、文件随机修改

1) 一个文件只能有一个写，不允许多个线程同时写。

2) 仅支持数据 append（追加），不支持文件的随机修改。

常用的架构部署图：

NameNode管理文件系统的元数据，DataNode存储实际的数据。客户端通过同

NameNode和DataNodes的交互访问文件系统。客户端联系NameNode以获取文件的元数据，

而真正的文件I/O操作是直接和DataNode进行交互的。

这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。

下面我们分别介绍这四个组成部分。

Client：就是客户端。

1、文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。

2、与 NameNode 交互，获取文件的位置信息。

3、与 DataNode 交互，读取或者写入数据。

4、Client 提供一些命令来管理 HDFS，比如启动或者关闭HDFS。

5、Client 可以通过一些命令来访问 HDFS。

NameNode：就是 master，它是一个主管、管理者。用户的实际数据不经过namenode

1、管理 HDFS 的名称空间(各种操作，维护文件系统树和其中的所有文件和目录)：这些信息保存在命名空间镜像文件

     和编辑日志文件。

2、管理数据块（Block）映射信息：记录每个文件中各个数据块在节点上的信息，

      但不永久保存块的位置信息，这些信息会在系统启动时由数据节点重建。

3、分配副本的存放节点 ,配置副本策略

4、处理客户端读写请求。

DataNode：就是Slave。NameNode 下达命令，DataNode 执行实际的操作。

1、存储实际的数据块，负责来自文件系统客户的读写请求。

2、执行数据块的创建，读/写操作，删除和来自namenode节点的块复制命令。

Secondary NameNode：并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。

1、辅助 NameNode，分担其工作量。

2、定期合并 fsimage和fsedits，并推送给NameNode。

3、在紧急情况下，可辅助恢复 NameNode。

HDFS副本机制：

副本因子、副本系数：

An application can specify the number of replicas of a file that should be maintained by HDFS. The number of copies of a file is called the replication factor of that file.

All blocks in a file except the last block are the same size

读写：

Files in HDFS are write-once and have strictly one writer at any time.

心跳机制：

The NameNode makes all decisions regarding replication of blocks. It periodically receives a Heartbeat and a Blockreport from each of the DataNodes in the cluster. Receipt of a Heartbeat implies that the DataNode is functioning properly. A Blockreport contains a list of all blocks on a DataNode

HDFS 副本存放策略：

第一个副本：存储在同 Client 相同节点上。第二个副本：存储在不同机架的节点上。

第三个副本：存储在第二个副本机架中的另外一个节点上。其它副本：选择随机存储

===================================================================================

HDFS文件读写流程：

漫画讲解：https://blog.csdn.net/scdxmoe/article/details/50904881

                  https://www.jianshu.com/p/a0f170436cbe

• HDFS写流程：

客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后，客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本。

详细步骤：

1、客户端向namenode发送文件上传的请求 ，namenode检查目标文件是否已存在，父目录是否存在
2、namenode返回是否可以上传.

3、client发送文件上传的真正请求，包含文件名，文件大小等
3、client会先对文件进行切分，比如一个blok块128m，文件有300m就会被切分成3个块，一个128M、一个128M、一个44M

     (进行文件的逻辑切块（不真正切块，只划分出切块的范围，是预切分))

     请求第一个 block该传输到哪些datanode服务器上
4、namenode根据3中的计算返回datanode的服务器，确定哪些数据节点可以上传。
5、client请求一台datanode上传数据（本质上是一个RPC调用，建立pipeline（构建第一个块的pipline（从client-》

     datanode01-》datanode02.。。。）在此期间，客户端会构建一个守护进程，等待pipline构建成功的响应）），第一个

     datanode收到请求会继续调用第二个datanode，然后第二个调用第三个datanode，将整个pipeline建立完成，逐级返回客户端

6、client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（一个packet为64kb），当然

      在写入的时候datanode会进行数据校验，它并不是通过一个packet进行一次校验而是以chunk为单位进行校验（512byte），

      第一台datanode收到一个packet就会传给第二台，第二台传给第三台；第一台每传一个packet会放入一个应答队列等待应答

7、当一个block传输完成之后，client再次请求namenode上传第二个block的服务器。

注意：

1.namenode实际客户端只上传一个datanode,其余两个是namenode完成的。让datenote自己复制的。然后复制完成以后逐级返回结果给namenode.如果2,3datanode复制失败，再有namenode分配新的datanode地址。对于客户端来说默认上传一个datanode就可以了，其余的由datanode自己复制。

2.datanode切片是由客户端完成的。datanode第二三个副本的上传和第一个上传是异步的。

3.构建pipline的时候，如果有节点通信不成功，会重试，没有反应会剔除，然后重建pipline

4.文件上传过程中，只要有一个副本上传成功，就默认这个数据块上传成功，剩下的副本会在集群空闲的时候进行异步复制

5.优先返回客户端所在节点，如果客户端不在集群中，就近返回同机架的节点，再返回不同机架的，就近返回原则

• HDFS读流程:

客户端将要读取的文件路径发送给namenode，namenode获取文件的元信息（主要是block的存放位置信息）返回给客户端，客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件。

读详细步骤：

1、跟namenode通信查询元数据（block所在的datanode节点），找到文件块所在的datanode服务器
2、挑选一台datanode（就近原则，然后随机）服务器，请求建立socket流
3、datanode开始发送数据（从磁盘里面读取数据放入流，以packet为单位来做校验(CRC校验)，若成功就进行第二块的下载）
4、客户端以packet为单位接收，先在本地缓存，然后写入目标文件，后面的block块就相当于是append到前面的block块最后合成最终需要的文件。

 

元数据包含

1.抽象目录树

2.数据和块的映射

3.块的存储位置

元数据文件分成4类

1.edits 历史日志文件/正在编辑的日志文件，记录元数据的操作日志

2.fsimage 镜像文件，存储真实的元数据信息序列化之后的文件

3.seen_txid 合并点，记录下次需要合并的edits文件的编号

4.合并工作由secondarynamenod来做 ，fsimage最终就是由fsimage和edits合并得来的

触发条件：可配置 1.一个小时 2.元数据条数达100万

checkpoint过程

若接收到修改元数据的请求比如hadoop fs -mkdir

过程如下：

1.先修改edits文件

2.修改内存中的元数据

3.snd会定时向nd发送请求，查看是否需要合并

4.nd反馈需要进行元数据合并

5.snd向nd发送元数据合并的请求

6.nd将正在编辑的edits文件进行回滚，写入历史数据，同时生成新的edits_inprogress文件，接受新的元数据请求

7.snd会将回滚完成的文件和fsimage文件拉取到snd本地

8.snd对文件放在内存中进行合并，完成后fsimage.checkpoint文件

9.将新的fsimage文件发送给nd，并进行重命名为fsimage文件，将原来的文件覆盖