HDFS重要概念

Posted 2022-05-18 小企鹅推雪球!

文章目录

• • 摘要
  • HDFS的数据流单位
  • HDFS读数据流程
  • HDFS写数据流程
  • HDFS元数据管理机制
  • Fsimage与Edits文件解析
  • • Fsimage中为什么没有记录块所对应DataNode？
    • Edits文件解析
  • checkpoint周期
  • NameNode故障处理
  • Hadoop的限额与归档以及集群安全模式
  • HDFS的安全模式
  • Hadoop归档技术

摘要

1. 总结一些HDFS重要的概念

HDFS的数据流单位

1. 在DFSClient写HDFS的过程中，有三个需要搞清楚的单位：block、packet与chunk；
2. block是最大的一个单位，它是最终存储于DataNode上的数据粒度，由dfs.block.size参数决定，默认是64M；（这个参数由客户端配置决定；）
3. packet是中等的一个单位，它是数据由DFSClient流向DataNode的粒度，以dfs.write.packet.size参数为参考值，默认是64K；注：这个参数为参考值，是指真正在进行数据传输时，会以它为基准进行调整，调整的原因是一个packet有特定的结构，调整的目标是这个packet的大小刚好包含结构中的所有成员，同时也保证写到DataNode后当前block的大小不超过设定值；
4. chunk是最小的一个单位，它是DFSClient到DataNode数据传输中进行数据校验的粒度，由io.bytes.per.checksum参数决定，默认是512B
5. ps:事实上一个chunk还包含4B的校验值，因而chunk写入packet时是516B；数据与检验值的比值为128:1，所以对于一个128M的block会有一个1M的校验文件与之对应；

HDFS读数据流程

1. 客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。
2. 挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
3. DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。
4. 客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

PS:写过程中的三层buffer(了解)

1. 写过程中会以chunk、packet及packet queue三个粒度做三层缓存；当数据流入DFSOutputStream时，DFSOutputStream内会有一个chunk大小的buf，当数据写满这个buf（或遇到强制flush），会计算checksum值，然后填塞进packet
2. 当一个chunk填塞进入packet后，仍然不会立即发送，而是累积到一个packet填满后，将这个packet放入dataqueue队列
3. 进入dataqueue队列的packet会被另一线程按序取出发送到datanode
4. 注：生产者消费者模型，阻塞生产者的条件是dataqueue与ackqueue之和超过一个block的packet上限
   

HDFS写数据流程

1. 客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已经存在，父目录是否存在
2. NameNode返回是否可以上传。
3. 客户端请求第一个 Block上传到哪几个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如何管理和存储元数据？

1. 计算机中存储数据两种：内存或者是磁盘。
2. 元数据存储磁盘：存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应，但是安全性高
3. 元数据存储内存：元数据存放内存，可以高效的查询以及快速响应客户端的查询请求，数据保存在内存，如果断点，内存中的数据全部丢失。
4. 解决方案：内存+磁盘；NameNode内存+FsImage的文件（磁盘）

磁盘和内存中元数据如何划分？两个数据一模一样，还是两个数据合并到一起才是一份完整的数据呢？

1. 一模一样时：client如果对元数据进行增删改操作，需要保证两个数据的一致性。FsImage文件操作起来效率也不高。
2. 两个合并=完整数据：NameNode引入了一个edits文件（日志文件：只能追加写入）edits文件记录的是client的增删改操作，不再选择让NameNode把数据dump出来形成FsImage文件（这种操作是比较消耗资源）

1. 第一阶段：NameNode启动
   1.1 第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
   1.2 客户端对元数据进行增删改的请求。
   1.3 NameNode记录操作日志，更新滚动日志。
   1.4 NameNode在内存中对数据进行增删改。
2. 第二阶段：Secondary NameNode工作
   2.1 Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否执行检查点操作结果
   2.2 Secondary NameNode请求执行CheckPoint。
   2.3 NameNode滚动正在写的Edits日志。将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
   2.4 Secondary NameNode加载编辑日志和镜像文件到内存，并合并生成新的镜像文件fsimage.chkpoint。
   2.5 拷贝fsimage.chkpoint到NameNode。
   2.6 NameNode将fsimage.chkpoint重新命名成fsimage。

Fsimage与Edits文件解析

1. NameNode在执行格式化之后，会在/data/tmp/dfs/name/current目录下产生如下文件
2. Fsimage文件：是namenode中关于元数据的镜像，一般称为检查点，这里包含了HDFS文件系统所有目录以及文件相关信息（Block数量，副本数量，权限等信息）
3. Edits文件 ：存储了客户端对HDFS文件系统所有的更新操作记录，Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中（不包括查询操作）
4. seen_txid：该文件是保存了一个数字，数字对应着最后一个Edits文件名的数字
5. VERSION：该文件记录namenode的一些版本号信息，比如：CusterId,namespaceID等

Fsimage中为什么没有记录块所对应DataNode？

1. 在内存元数据中是有记录块所对应的dn信息，但是fsimage中就剔除了这个信息；
2. HDFS集群在启动的时候会加载image以及edits文件，block对应的dn信息都没有记录，集群启动时会有一个安全模式（safemode）,安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。
3. 后续每隔一段时间dn都要汇报自己持有的block信息。

Edits文件解析

1. Edits中只记录了更新相关的操作，查询或者下载文件并不会记录在内
2. nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件
3. 通过fsimage文件自身的编号来确定哪些edits已经被合并
   

checkpoint周期

<!-- 定时一小时 -->
<property>
	<name>dfs.namenode.checkpoint.period</name>
	<value>3600</value>
</property>
<!-- 一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次 -->
<property>
	<name>dfs.namenode.checkpoint.txns</name>
	<value>1000000</value>
<description>操作动作次数</description>
</property>
<property>
	<name>dfs.namenode.checkpoint.check.period</name>
	<value>60</value>
<description> 1分钟检查一次操作次数</description>
</property >

NameNode故障处理

1. NameNode故障后，HDFS集群就无法正常工作，因为HDFS文件系统的元数据需要由NameNode来管理维护并与Client交互，如果元数据出现损坏和丢失同样会导致NameNode无法正常工作进而HDFS文件系统无法正常对外提供服务
2. 元数据出现丢失损坏如何恢复?
   2.1 将2NN的元数据拷贝到NN的节点下此种方式会存在元数据的丢失。
   2.2 搭建HDFS的HA（高可用）集群，解决NN的单点故障问题！！（借助Zookeeper实现HA，一个Active的NameNode,一个是Standby的NameNode）

Hadoop的限额与归档以及集群安全模式

1. HDFS文件的限额配置允许我们以文件大小或者文件个数来限制我们在某个目录下上传的文件数量或者文件内容总量，以便达到我们类似百度网盘网盘等限制每个用户允许上传的最大的文件的量

2. 数量限额

   hdfs dfs -mkdir -p /user/root/lagou #创建hdfs文件夹
   hdfs dfsadmin -setQuota 2 /user/root/lagou # 给该文件夹下面设置最多上传两个文件，上传文件，发现只能上传一个文件
   hdfs dfsadmin -clrQuota /user/root/lagou # 清除文件数量限制
   

3. 空间大小限额

hdfs dfsadmin -setSpaceQuota 4k /user/root/lagou # 限制空间大小4KB
#上传超过4Kb的文件大小上去提示文件超过限额
hdfs dfs -put /export/softwares/xxx.tar.gz /user/root/lagou
hdfs dfsadmin -clrSpaceQuota /user/root/lagou #清除空间限额
#查看hdfs文件限额数量
hdfs dfs -count -q -h /user/root/lagou

HDFS的安全模式

1. 安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求。
2. 在NameNode主节点启动时，HDFS首先进入安全模式，DataNode在启动的时候会向NameNode汇报可用的block等状态，当整个系统达到安全标准时，HDFS自动离开安全模式
3. 如果HDFS出于安全模式下，则文件block不能进行任何的副本复制操作，因此达到最小的副本数量要求是基于DataNode启动时的状态来判定的，启动时不会再做任何复制（从而达到最小副本数量要求）
4. HDFS集群刚启动的时候，默认30S钟的时间是出于安全期的，只有过了30S之后，集群脱离了安全期，然后才可以对集群进行操作。

Hadoop归档技术

1. Hadoop归档技术主要解决HDFS集群存在大量小文件的问题。由于大量小文件会占用NameNode的内存，因此对于HDFS来说存储大量小文件造成NameNode内存资源的浪费！
2. Hadoop存档文件HAR文件，是一个更高效的文件存档工具，HAR文件是由一组文件通过archive工具创建而来，在减少了NameNode的内存使用的同时，可以对文件进行透明的访问。
3. 通俗来说就是HAR文件对NameNode来说是一个文件减少了内存的浪费，对于实际操作处理文件依然是一个一个独立的文件。
   3.1. 启动YARN集群

   [root@linux121 hadoop-2.9.2]$ start-yarn.sh  #启动YARN集群
   

   3.2 归档文件把/user/lagou/input目录里面的所有文件归档成一个叫input.har的归档文件，并把归档后文件存储到/user/lagou/output路径下。

   [root@linux121 hadoop-2.9.2]$ bin/hadoop archive -archiveName input.har –p
   /user/root/input /user/root/output
   

   3.3 查看归档

   [root@linux121 hadoop-2.9.2]$ hadoop fs -lsr /user/root/output/input.har
   [root@linux121 hadoop-2.9.2]$ hadoop fs -lsr har:///user/root/output/input.har
   

   3.4 解归档文件

   [root@linux121 hadoop-2.9.2]$ hadoop fs -cp har:/// user/root/output/input.har/* /user/root