什么是HDFS

HDFS是（Hadoop Distributed File System）的缩写，也即Hadoop分布式文件系统。它通过目录树定位在分布式场景下在不同服务器主机上的文件。它适用于一次写入，多次读出的场景。

HDFS的优缺点

优点

1，高容错性，一份文件在多台服务器上都有备份，不存在因为一台服务器宕机而造成文件丢失的情况。
2，存储量大，数据规模：接近TB。数量规模：接近百万。
3，可搭建在廉价的电脑上，不需要专门的服务器。

缺点

1，读取速度慢。
2，无法高效的存储大量的细小文件，大量的小文件，HDFS的查找时间远大于读取时间，违反了HDFS的设计初衷。
3，不支持并发写入，不支持随机修改了。要修改的数据只能追加在文件的末尾。

HDFS的组成

NameNode

HDFS的老大，只操作小弟，不操作具体的数据。

DataNode

HDFS的小弟，负责操作具体的数据。
在这里插入图片描述

Client

客户端，直接打开的hadoop页面是客户端，写的HDFS命令是客户端，后端写的代码也是客户端。

SecondaryNameNode

大哥的秘书，分担老大的工作，比如定时备份数据：操作Fsimage和Edits
在这里插入图片描述

HDFS中的块大小

HDFS文件在物理上采用分块存储，在Hadoop1.x版本中是64M，在Hadoop2.x和3.x版本中采用128M。
其大小可以修改配置 dfs.blocksize来决定。
为什么要采用128M作为大小？
寻址时间为0.01s，按照HDFS的设计思路，数据在传输的时间应为寻址时间的0.01，那么传输时间就为1s，机械硬盘的读写速度为100M/s。所以一个块选择其大小为128M。
总结：块大小取决于服务器硬盘的传输效率。

HDFS的Shell操作

这些百度就有
尚硅谷Hadoop3.x官方文档大全免费下载。
https://pan.baidu.com/share/init?surl=P5JAtWlGDKMAPWmHAAcbyA 提取码：5h60

HDFS的JavaApi操作

源码在GitHub

HDFS的读写流程

HDFS的写数据流程

文件写入流程

在这里插入图片描述
（1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
（2）NameNode返回是否可以上传。
（3）客户端请求第一个 Block（128M）上传到哪几个DataNode服务器上。
（4）NameNode返回3个DataNode节点，分别为dn1、dn2、dn3。
（5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
（6）dn1、dn2、dn3逐级应答客户端。
（7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。是第一个应答后传给第二个，再传给第三个
（8）当一个Block传输完成之后，客户端再次请求NameNode上传第二个Block的服务器。（重复执行3-7步）。

节点距离计算

HDFS在写入数据时，NameNode会选择距离最近的DataNode，写入数据，那么他是如何计算距离的呢？
在这里插入图片描述

机架感知（副本存储节点选择）

在“文件写入流程”中d1是数据存储的位置，d2，d3都是d1文件副本（冗余）存储的DataNode。那么HDFS他是如何选择冗余副本应该放在哪的呢？
（1）官方说明

http://hadoop.apache.org/docs/r3.1.3/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#Data_Replication For the common case, when the replication factor is three, HDFS’splacement policy is to put one replica on the local machine if the writer is on a datanode, otherwise on a random datanode, another replica on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; thi policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.

（2）Hadoop3.1.3副本节点选择
在这里插入图片描述

HDFS的读数据流程

在这里插入图片描述
（1）Client通过对象：分布式文件系统向NameNode请求下载文件，NameNode进行权限和文件校验。并返回具体的DataNode地址。
（2）挑选一台DataNode（就近原则+负载原则）穿行读数据。！非并行！
（3）DataNode开始传输数据给客户端（以Packet为单位来做校验）。Packet = 64K
（4）客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

NameNode和2NameNode

NN和2NN工作机制

DataNode中数据又备份，那NameNode中的数据没有备份吗？
当然有，NameNode数据备份类似Redis的AOF和RDB技术，采用FsImage和Edits的合并，合成元数据。并把这个备份程序，交由2NN进行运行。
在这里插入图片描述
1）第一阶段：NameNode启动
（1）第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。
（3）NameNode记录操作日志，更新滚动日志。
（4）NameNode在内存中对元数据进行增删改。
2）第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
（2）Secondary NameNode请求执行CheckPoint。
（3）NameNode滚动正在写的Edits日志。
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint。
（7）拷贝fsimage.chkpoint到NameNode。
（8）NameNode将fsimage.chkpoint重新命名成fsimage。
要备份数据，就将fsimage和最新的edits_inprogress进行合并。
每次NameNode启动的时候都会将Fsimage文件读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并。

DataNode

DataNode的工作机制

1，DataNode检查是否在正常，
1>DataNode每3秒向NameNode发送心跳，如果在10分钟+20秒NameNode还是没有接收到DataNode的心跳就默认为DataNode挂掉了。
2>一个DataNode中有很多块，NameNode周期性校验节点块的时间为6H，周期性向NameNode汇报节点情况的时间也为6H。
2，数据具体在DataNode中的块中有。数据+数据长度+校验和+时间戳
在这里插入图片描述