04-Hadoop之HDFS分布式文件系统详解

HDFS详解

一、 HDFS 概述

1.1 HDFS定义

​ HDFS( Hadoop Distribution File System), 它是一个文件系统,用于存储文件,通过目录树来定位文件;其次,它是分布式的,由很多服务器联合起来实现其功能,集群中的服务器有各自的角色。

​ HDFS的使用场景:适合一次写入,多次读出的场景,且不支持文件的修改。适合用来做数据分析,并不适合用来做网盘应用。

1.2 HDFS优缺点

(1)优点

a. 高容错性
  • 数据自动保存多个副本。它通过增加副本的形式,提高容错性
  • 某一个副本丢失以后,它可以自动恢复
b. 适合处理大数据
  • 数据规模: HDFS 是 Hadoop 项目的一个子项目。是 Hadoop 的核心组件之一, Hadoop 非常适 于存储大型数据 (比如 TB 和 PB)(需要多台节点),
  • 文件规模: HDFS 使用多台计算机存储文件,能够处理百万规模以上的文件数量。
c. 可构建在廉价机器上,通过多副本机制,提高可靠性

(2) 缺点

a. 不适合低延时数据访问

对于毫秒级的存储数据,是做不到的

b. 无法高效的对大量小文件进行存储
  • 存储大量小文件的话,它会占用NameNode大量的内存来存储文件目录和块信息。
  • 小文件存储的寻址时间会超过读取时间,它违反了HDFS的设计目标
c. 不支持并发写入、文件随机修改
  • 一个文件只能有一个写,不允许多个线程同时写
  • 仅支持数据append (追加), 不支持文件的随机修改

1.3 HDFS架构 (理解清楚)

思考:HDFS系统中的文件或者数据存储在哪里?
NameNode:用于管理元数据(对真实数据的描述信息)
	--存储在Linux系统/opt/module/hadoop-3.1.3/name下								格式化之后,才会产生name目录
作用:	
	用于管理HDFS名称空间
	用于配置副本策略
	用于处理客户端读写请求
	管理数据(Block)块映射信息
	下达指令给DN
	
DataNode:用于存储真实块数据信息	
	--存储在Linux系统/opt/module/hadoop-3.1.3/data下
	格式化之后,才会产生data目录
执行数据块的读写操作

SecondaryNameNode : 为NameNode分担压力, 关键时刻,辅助恢复NameNode

1.4 HDFS文件块大小(面试重点)

HDFS中文件的存储在物理上是分块存储(块为单位),块的大小可以通过dfs.blocksize设置,默认在hadoop3.x版本中是128M,hadoop2.x也是128M,hadoop1.x是64M.本地(windows系统)模式下默认的块大小是32M
	注意:128M只是衡量一个文件是否要进行切块的标准,实际文件是多大,存储到Hdfs上就是多大。
	例如: 块大小为128M
       上传一个100M的文件, 最后在HDFS会生成一个块。实际占用空间还是100M
       上传一个200M的文件, 最后在HDFS会生成两个块, 第一个块占用空间128M, 第二个块占用空间72M
       
块大小设置路径:在hdfs-default.xml中	

  dfs.blocksize
  134217728
  
      The default block size for new files, in bytes.
      You can use the following suffix (case insensitive):
      k(kilo), m(mega), g(giga), t(tera), p(peta), e(exa) to specify the size (such as 128k, 512m, 1g, etc.),
      Or provide complete size in bytes (such as 134217728 for 128 MB).
  

(1) 将文件切分为block块的好处

  • 一个文件的大小可能大于集群中任意一个磁盘
    • 块可以将大文件切分多个块进行存储
  • 使用块进行存储可以简化存储系统
  • 块非常适用于数据备份进而提供数据容错能力和可用性

(2) 块缓存

通常 DataNode 从磁盘中读取块,但对于访问频繁的文件,其对应的块可能被显示的缓存在 DataNode 的内存中,以堆外块缓存的形式存在。默认情况下,一个块仅缓存在一个DataNode的内存中,当然可以针对每个文件配置DataNode的数量。作业调度器通过在缓存块的DataNode上运行任务,可以利用块缓存的优势提高读操作的性能

上述总结:DataNode从磁盘中读取块内容是从内存读取再写到磁盘的。(只需要清楚)

例如:
连接(join)操作中使用的一个小的查询表就是块缓存的一个很好的候选。用户或应用通过在缓存池中增加一个cache directive来告诉namenode需要缓存哪些文件及存多久。缓存池(cache pool)是一个拥有管理缓存权限和资源使用的管理性分组。

例如:

一个文件 130M,会被切分成2个block块,保存在两个block块里面,实际占用磁盘130M空间,而不是占用256M的磁盘空间

思考: 为什么块的大小不能设置太小, 也不能设置太大?`

  • HDFS的块设置太小会增加寻址时间,程序一直在找块的开始位置;

  • 如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时,会非常慢

总结: HDFS 块的大小设置主要取决于磁盘传输速率。

1.5 HDFS的特性总结

  • 1. master/slave 架构(主从架构)

HDFS 采用 master/slave 架构。一般一个 HDFS 集群是有一个 Namenode 和一定数目的 Datanode 组成。Namenode 是 HDFS 集群主节点,Datanode 是 HDFS 集群从节点,两种角色各司其职,共同协调完成分布式的文件存储服务。

  • 2. 分块存储

HDFS 中的文件在物理上是分块存储(block)的,块的大小可以通过配置参数来规定,默认大小在 hadoop2.x 版本中是 128M。

  • 3. 名字空间(NameSpace)

HDFS 支持传统的层次型文件组织结构。用户或者应用程序可以创建目录,然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动或重命名文件。
Namenode 负责维护文件系统的名字空间,任何对文件系统名字空间或属性的修改都将被 Namenode 记录下来。
HDFS 会给客户端提供一个统一的抽象目录树,客户端通过路径来访问文件,形如:hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。

  • 4. NameNode 元数据管理

我们把目录结构及文件分块位置信息叫做元数据。NameNode 负责维护整个 HDFS 文件系统的目录树结构,以及每一个文件所对应的 block 块信息(block 的 id,及所在的 DataNode 服务器)。

  • 5. DataNode 数据存储

文件的各个 block 的具体存储管理由 DataNode 节点承担。每一个 block 都可以在多个 DataNode 上。DataNode 需要定时向 NameNode 汇报自己持有的 block 信息。存储多个副本(副本数量也可以通过参数设置 dfs.replication,默认是 3)

  • 6. 副本机制

为了容错,文件的所有 block 都会有副本。每个文件的 block 大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后改变。

  • 7. 一次写入,多次读出

HDFS 是设计成适应一次写入,多次读出的场景,且不支持文件的修改。
正因为如此,HDFS 适合用来做大数据分析的底层存储服务,并不适合用来做网盘等应用,因为修改不方便,延迟大,网络开销大,成本太高。

二、 HDFS 的shell命令

2.1 基本语法

bin/hadoop fs 具体命令 OR bin/hdfs dfs 具体命令

注意:两个(hadoop、dfs)在操作dfs上的操作是完全相同的。

2.2 命令大全

-启动Hadoop集群
	start-dfs.sh    start-yarn.sh
-help:输出这个命令参数
	hdfs dfs -help rm
-ls: 显示目录信息
	hadoop fs -ls /
-mkdir:在HDFS上创建目录
	hadoop fs -mkdir -p /user/atguigu
-moveFromLocal:从本地剪切粘贴到HDFS
	hdfs dfs -moveFromLocal ./input/test.txt /user/atguigu/input
-appendToFile:追加一个文件到已经存在的文件末尾
	hdfs dfs -appendToFile ./input/test.txt /user/atguigu/input/wc.input.txt
-cat:显示文件内容
	hadoop fs -cat /user/atguigu/input/wc.input
-chgrp 、-chmod、-chown:Linux文件系统中的用法一样,修改文件所属权限
	hdfs dfs -chmod 777 /user/atguigu/input/input/wc.input
	hadoop fs -chown atguigu:atguigu /user/atguigu/input/input/wc.input
-copyFromLocal:从本地文件系统中拷贝文件到HDFS
	hadoop fs -copyFromLocal README.txt /
-copyToLocal:从HDFS拷贝到本地
	hdfs dfs -copyToLocal /user/atguigu/input/wc.input ./
-cp :从HDFS的一个路径拷贝到HDFS的另一个路径
	hdfs dfs -cp /user/atguigu/input/wc.input /user/atguigu/
-mv:在HDFS目录中移动文件
	hadoop fs -mv /user/atguigu/input  /user/
-get:等同于copyToLocal,就是从HDFS下载文件到本地
	hadoop fs -get /user/atguigu/input/wc.input ./
-getmerge:合并下载多个文件
	hdfs dfs -getmerge /user/atguigu/input/* ./input.txt
-put:等同于copyFromLocal
	hadoop fs -put ./input/text.txt /user/atguigu/input/
-tail:显示一个文件的末尾
	hadoop fs -tail /user/atguigu/input/wc.input
-rm:删除文件或文件夹
	hadoop fs -rm -r /user/atguigu/input/wc.input
-rmdir:删除空目录
	hdfs dfs -rmdir /user/atguigu/wcinput
-du统计文件夹的大小信息
	hdfs dfs -du -s -h /user/atguigu/test
-setrep:设置HDFS中文件的副本数量
	hdfs dfs -sdetrep 5 /README.txt 
	
注意:这里设置的副本数只是记录在NameNode的元数据中,是否真的会有这么多副本,还得看DataNode的数量。因为目前只有3台设备,最多也就3个副本,只有节点数的增加到至少5台时,副本数才能达到5

三、 HDFS的读写数据流程(开发重点)

3.1 HDFS 写数据流程

示例:上传一个200M的文件到HDFS分布式系统
HDFS写的流程步骤如下:
1、客户端client向NameNode发送上传文件的请求,NameNode会做校验(是否具备权限,上传路径是否存在,文件是否存在,是否执行覆盖操作等)

2、NameNode返回是否可以上传

3、客户端按照集群中块大小的设置对200M的数据进行切块,即切分为128M和72M两个block块,并请求第一个block上传到哪几个DataNode服务器上(DataNode节点信息)					     --切块源码查看:FileInputFormat~getSplits()方法
	补充:
	3.1 执行上传时,是一块一块进行上传,则先请求上传0~128M的块信息(第一个block块),因为数据真实存在DataNode节点上,所以NameNode会返回dn1\dn2\dn3三个服务器节点存储数据   
	--思考:副本选择机制,如何选择节点并返回?

4、客户端得到dn的信息后,会和dn服务器节点建立链接,客户端发送请求建立block传输通道,执行写数据操作 
	补充:
	4.1 客户端在和dn(DataNode)建立连接时,也会有选择,选择距离客户端最近的节点请求建立链接通道(假设dn1最近)
	4.2 客户端和dn1建立链接通道之后,dn1内部发请求到dn2,请求建立通道,dn2发请求到dn3,请求建立通道,dn3响应dn2,dn2响应dn1,dn1响应客户端 ,均没有问题,通道建立成功

5、数据传输时,不是说将128M的文件直接进行传输,而是客户端向dn1以Packet(数据包)为单位进行数据传输,(packet大小:64KB),每次传输64KB,最后一次传输数据大小可能不够64KB
	补充:
	5.1 客户端向dn1传输64KB的数据到内存,dn1落盘(在当前节点服务器上将数据由内存写到本地),并分发给dn2(内存),dn2落盘,在发给dn3(内存),dn3落盘     	--逻辑上的说法
	5.2 trunk数据传输过程中的最小单位(512字节),每次从0~128M中读数据,先读取512字节放入trunk中,当trunk满载时,对trunk内的数据进行校验,生成校验值(占4个字节),即共将516个字节放入Packet内,一个Packet存在N多个trunk	--真实说法
	5.3 各节点内部Packet是如何进行传输的?
	在hdfs内部有一个队列,叫做dataQuene,每传输一个Packet,就将当前Packet放入到DQ队列中,当dn1接收到DQ中的Packet时,会将Packet从DQ队列中拉取出来,存入另一队列ackquene中(应答队列),当dn1,dn2,dn3等节点均将ackq中的数据写成功之后,ackquene中的packet移除,表示packet传输完成

6、当dn1、dn2、dn3建立通道时,或者在数据传输过程中,如果某个节点出现问题,比如dn2宕机了,那么客户端会重新发请求建立传输通道,这时,宕机的节点dn2不在请求应答,dn1 和 dn3直接建立通道,dn2不在使用,缺少副本数据,内部机器会重新配置一台来顶替dn2,保证真实节点数据和副本机制设置的保持一致

7、数据传输完成之后,流关闭,执行第二个块的数据写操作,步骤同上

3.2 副本选择机制

(1) 节点距离计算

在HDFS写数据的过程中,NameNode会选择距离待上传数据最近距离的DataNode接收数据。

思考:这个最近距离怎么计算呢?

节点距离:两个节点到达最近的共同祖先的距离总和。

04-Hadoop之HDFS分布式文件系统详解_第1张图片

可以通过上图总结出,可用带宽效率(依次递减):

  1. 同一节点上的进程
  2. 同一机架上的不同节点
  3. 同一数据中心中不同机架上的节点
  4. 不同数据中的节点

(2) 机架感知(副本储存节点选择)

机架感知说明

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’s placement 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.

(3) 副本的存放策略

目的
  1. 数据的安全(优先)
  2. 数据块的负载均衡
解决方案(节点选择):
  • 第一个副本在Client 所处的节点上。如果客户端在集群外,随机挑选一个。
  • 第二个副本在另外一个机架的随机一个节点。
    • 注意:第二个副本的所在机架不能和第一个副本所在机架相同
  • 第三个副本在第二个副本所在的机架的随机一个节点上。(不同于第二个副本节点)

设计思想:如果第一个副本和第二个副本都放在了第一个机架上,那么写入的效率会提高,但是数据的安全性就会降低(机架损坏导致两个副本都不能使用),所以将第一个副本和第二个副本存放在不同的机架上;第三个副本存放的节点在第二个副本所在的机架上的其它节点,此时可以保证数据写入效率更高。

3.3 HDFS 读数据流程

示例: 从HDFS上下载一个200M的文件到客户端
1、 客户端通过Distributed FileSystem向NameNode请求下载文件,NameNode通过查询元数据,返回该文件的块所在的DataNode地址。
2、 客户端根据元数据返回的DataNode地址挑选一台DataNode(就近原则,然后随机)服务器,请求读取数据。
3、 DataNode开始传输数据给客户端(从磁盘里面读取数据输入流,以Packet为单位来做校验)。
4、 客户端以Packet为单位接收,先在本地缓存,然后写入目标文件。

四、 HDFS中NameNode和SecondaryNameNode(面试重点)

4.1 NN 和 2NN 工作机制

4.1.1 概述

思考:NameNode中的元数据是存储在哪里的?

① 假设存储在NameNode所在节点的磁盘上,因为元数据需要进行随机访问,还有响应客户请求,这样做效率必然过低,所以不可行。

② 假设存储在内存中,一旦断电,元数据就会丢失,整个集群就无法工作了,所以这也不可行。

③ 因此元数据在磁盘和内存上都会使用。

具体使用:Fsimage文件存放在磁盘中;Edits文件存放在内存中,当edits文件存储一定数量后利用滚动日志将edits保存到磁盘,并生成一个新的 edits_inprogress_xxx文件。

04-Hadoop之HDFS分布式文件系统详解_第2张图片

4.1.2 NN工作机制

(1)第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
	即在NN启动时,需要先将磁盘的fsimage_current 和 edits_inprogress_001 文件加载到进行一次合并. 在内存中构建好元数据信息。	其中 seen_txid:记录正在使用的编辑日志文件
(2)客户端对元数据进行增删改的请求。

(3)NameNode记录操作日志,更新滚动日志。
	NN会将edits_progress进行所谓的滚动,说白了就是该文件不能再进行写入操作,会生成另外一个编辑日志文件用于记录后续的写操作.
	  	滚动正在使用的编辑日志: edits_inprogress_001 --> edits_001
	  	新的编辑日志: edits_inprogress_002 

(4)NameNode在内存中对元数据进行增删改。


总结: NN内存中的数据 = 磁盘上正在使用的fsimage + 正在使用的edits文件.

4.1.3 2NN工作机制

(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。

4.2 Fsimage 和 Edits 解析

4.2.1 概念

  1. Fsimage文件(镜像文件):存放的是元数据。详情:HDFS 文件系统元数据的一个永久性的检查点, 其中包含HDFS文件系统的所有目录和文件inode的序列化信息。
  2. Edits文件(日志文件):存放的是操作命令。详情:存放HDFS文件系统的所有更新操作的路径,文件系统客户端执行的所有写操作首先会被记录到Edits文件中
  3. seen_txid文件报尺寸的是一个数字,就是最后一个edits_的数字
  4. 每次NameNode启动的时候都就会将 Fsimage 文件读入内存,加载 Edits 里面的更新操作,保证内存中的语言数据信息是最新的、同步的,可以看成NameNode启动的时候就将Fsimage 和 Edits 文件进行了合并。

4.2.2 oiv查看Fsimage文件

语法:	hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径
案例
hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-3.1.3/fsimage.xml

将镜像文件转成xml文件后可以将其传到Windows桌面上进行打开
在  中可以看见文件或者目录的信息

思考:Fsimage中没有记录块所对应DataNode,为什么?

在fsimage中,并没有记录每一个block对应到哪几个datanodes的对应表信息,而只是存储了所有的关于namespace的相关信息。而真正每个block对应到datanodes列表的信息在hadoop中并没有进行持久化存储,而是在所有datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenode,namenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。(HDFS就是通过这种块信息汇报的方式来完成 block -> datanodes list的对应表构建。Datanode向namenode汇报块信息的过程叫做blockReport,而namenode将block -> datanodes list的对应表信息保存在一个叫BlocksMap的数据结构中。)
参考:https://blog.csdn.net/weixin_43988989/article/details/104590230

​ 总结:在集群启动后,要求DataNode上报数据块信息,并间隔一段时间后再次上报。

4.2.3 oev查看Edits文件

语法:	hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
案例
hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-3.1.3/edits.xml

将日志文件转成xml文件后可以将其传到Windows桌面上进行打开

思考:NameNode如何确定下次开机启动的时候合并哪些Edits?

NameNode启动时会合并最新的 Edits文件(edits_inprogress_xxx 文件)和 磁盘中最新生成的fsimage文件

​ 总结:都是合并最新的。

4.3 CheckPoint时间设置

1)通常情况下,SecondaryNameNode每隔一小时执行一次。

配置文件 hdfs-default.xml

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>  //修改这个值就是修改检查点时间
</property>

2)一分钟检查一次操作次数,当操作次数达到1百万时,SecondaryNameNode执行一次。

配置文件 hdfs-default.xml


  dfs.namenode.checkpoint.txns
  1000000
操作动作次数



  dfs.namenode.checkpoint.check.period
  60
 1分钟检查一次操作次数

4.4 NameNode故障处理

NameNode故障后,可以采用如下两种方法恢复数据。

方式一

/*
	将secondaryNameNode中的数据cp到NameNode存储数据的目录
	--NN存储的目录(/opt/module/hadoop-3.1.3/data/name/current)
*/
具体操作演示:
	1、杀掉NameNode进程
		jps 查看NN运行的进程号
		kill -9 NN进程号
	2、删除name下所有内容
		rm -rf /opt/module/hadoop-3.1.3/data/name/ *
	3、拷贝2NN服务器节点name下的所有内容到NN中的name目录下
		scp -r atguigu@atguigu5:/opt/module/hadoop-3.1.3/data/namesecondary/* ./name/


方式二

使用-importCheckpoint选项启动NameNode守护进程,从而将SecondaryNameNode中数据拷贝到NameNode目录中.
具体操作演示:
	1、修改hdfs-site.xml
		
          dfs.namenode.checkpoint.period
          120
        
        
          dfs.namenode.name.dir
          /opt/module/hadoop-3.1.3/data/name
        
	2、kill -9 NameNode进程
	3、删除NameNode存储的数据(/opt/module/hadoop-3.1.3/data/name)
	4、如果2NN不和NN在一个主机节点上,需要将2NN存储数据的目录拷贝到NN存储数据的平级目录,并删除in_use.lock文件
		scp -r atguigu@atguigu5:/opt/module/hadoop-3.1.3/data/namesecondary ./
		rm -rf in_use.lock
		pwd   --->   /opt/module/hadoop-3.1.3/data
	5、导入检查点数据(等待一会ctrl+c结束掉)
		bin/hdfs namenode -importCheckpoint
	6、启动NameNode
		hdfs --daemon start namenode

4.5 集群安全模式

4.5.1 安全模式概述

1、 NameNode 启动

NameNode启动时,首先将镜像文件(Fsimage)载入内存,并执行编辑日志(Edits)中的各项操作。一旦在内存中成功建立文件系统元数据的映像,则创建一个新的Fsimage文件和空的编辑日志(实际上没有创建新的文件,这里指的是将checkpoint的数据放入进行同步导致文件变化)。此时,NameNode开始监听DataNode请求。这个过程期间,NameNode一直运行在安全模式,即NameNode的文件系统对客户端来说只是只读的

2、 DataNode启动

系统中的数据块的位置并不是由NameNode维护的,而是以块列表的形式存储在DataNode中。在系统的正常操作期间,NameNode会在内存中保留所有块位置的映射信息。在安全模式下,各个DataNode会向NameNode发送最新的块列表信息,NameNode了解到足够多的块位置信息之后,即可高效运行文件系统。

3、 安全模式退出判断

如果满足 “最小副本条件” ,NameNode会在30秒钟之后就会退出安全模式。所谓的最小副本条件指的是在整个文件系统中 99.9%的块满足最小副本级别(默认值 : dfs.replication.min = 1 最小副本数为1)。在启动一个刚刚格式化的 HDFS 集群时,因为系统中还没有任何块,所以 NameNode 不会进入安全模式

最小副本条件解释:如果有1000个块,只需要知道1000个块中的999块其中的一个块的副本,即可退出安全模式。

4.5.2 安全模式生命周期

1、init
	当NN刚启动~加载fsimage+edites日志文件~内存中元数据构建成功~NN开始监听DN请求,此过程中,NN处于安全模式下,NN的文件系统对于client是只读的
2、run
	当DN启动~DN向NN发起内部通信,告知NN自己节点上DN真实块数据列表信息(安全模式下),NN收到各DN的块位置信息之后,开始运行文件系统
	--NN中的真实数据存放位置不是由NN维护的,而是以块的形式存储在各DN节点上
3、safe quit:(HDFS集群系统启动完成后,自动退出安全模式)
	满足‘最小副本条件’ 安全模式退出	

4.5.3 安全模式操作语法

(1) bin/hdfs dfsadmin -safemode get		(功能描述:查看安全模式状态)
(2) bin/hdfs dfsadmin -safemode enter  	(功能描述:进入安全模式状态)
(3) bin/hdfs dfsadmin -safemode leave	(功能描述:离开安全模式状态)
(4) bin/hdfs dfsadmin -safemode wait	(功能描述:等待安全模式状态)

4.5.4 案例

案例演示:
1、在/opt/module/hadoop-3.1.3/ 路径下创建脚本safemode.sh
	touch safemode.sh
2、编辑safemode.sh
 a. 打开脚本
	sudo vim safemode.sh    
 b. 编写内容是:当处于安全模式会进入等待状态(不然会直接不执行命令导致上传失败),并上传一个文件到HDFS系统
    #!/bin/bash
    hdfs dfsadmin -safemode wait
    hdfs dfs -put /opt/module/hadoop-3.1.3/README.txt /
3、给与safemode.sh执行权限
	chmod 777 safemode.sh
4、运行safemode.sh脚本
	./safemode.sh
5、重新打开一个xshell控制台,执行离开等待状态
	bin/hdfs dfsadmin -safemode leave
6、观察原窗口,查看原窗口hdfs的安全模式状态
	bin/hdfs dfsadmin -safemode get
	Safe mode is OFF
	safemode.sh中的上传代码执行,hdfs集群已有上传的数据

五、 DN工作机制(面试开发重点)

5.1 DataNode工作机制

04-Hadoop之HDFS分布式文件系统详解_第3张图片

DataNode的工作机制:
(1)一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
(2)DataNode启动后向NameNode注册,通过后,周期性(1小时)的向NameNode上报所有的块信息。
(3)心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。
(4)集群运行中可以安全加入和退出一些机器。
DataNode的作用:以块的形式,来存储真实数据,128M为切块单位
	切块之后的数据分为2部分:
		-- 数据本身(即文件中真实的数据)
		-- 元数据(对数据块的长度、校验和、时间戳等描述信息)
		
DataNode的存储位置: /opt/module/hadoop-3.1.3/data/data/current/BP-1901013597-192.168.202.103-1600767106029/current/finalized/subdir0/subdir0
	查看后可以发现:
		每个块分成两个前面同名但后缀名不同的文件
		不带后缀名的文件 就是 真实存储的数据
		带 .meta 后缀名的文件 就是 存储元数据的文件

5.2 数据完整性

思考:如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号(1)和绿灯信号(0),但是存储该数据的磁盘坏了,一直显示是绿灯,是否很危险?同理DataNode节点上的数据损坏了,却没有发现,是否也很危险,那么如何解决呢?

如下是DataNode节点保证数据完整性的方法。
(1)当DataNode读取Block的时候,它会计算CheckSum。
(2)如果计算后的CheckSum,与Block创建时值不一样,说明Block已经损坏。
(3)Client读取其他DataNode上的Block。
(4)DataNode在其文件创建后周期验证CheckSum。

校验码算法: crc (32位)、md5(128位) 、SHA1(160)、SHA256

5.3 掉线时限参数设置

心跳:DataNode会每隔3秒向NameNode响应一下,向NameNode证明还存活着。

如果DataNode发生故障造成DataNode无法与NameNode通信,此时,NameNode不会立刻把该节点判定为死亡,超过 “ 超市时长” (默认是10分钟 + 30秒)时,才会判定该节点已死亡。

超时时长的计算公式为:

超时时长 = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval

配置文件: hdfs-site.xml
添加内容如下  第一个是毫秒单,值为5分钟,第二个单位是秒,值为3秒
    
        dfs.namenode.heartbeat.recheck-interval
        300000
    
    
        dfs.heartbeat.interval
        3
    

5.4 服役新数据节点

注意:启动新节点,不需要去停止集群,也不要配置workers文件,当需要将新增节点也可群起群停时,要去将新增节点添加到workers文件中,并分发

添加新节点

1、在hadoop104主机上再克隆一台hadoop105主机
2、修改IP地址和主机名称
	vim /etc/sysconfig/network-scripts/ifcfg-ens33
		将 IPADDR=192.168.1.104 改成 192.168.1.105
	vim /etc/hostname
		将 hadoop104 改成 hadoop105
   补充:如果 /etc/hosts 文件下没有添加有192.168.1.105则还需要添加进去
3、删除hadoop105服务节点下hadoop的data和logs,并且删除/tmp的所有临时文件
	rm -rf /opt/module/hadoop-3.1.3/data  /opt/module/hadoop-3.1.3/logs
	sudo rm -rf /tmp/*
4、source配置文件
	source /etc/profile
5、在hadoop105上启动DataNode节点,直接关联到集群
	hdfs --daemon start datanode    --web端可以看到新增节点直接加入集群
6、	yarn --daemon start nodemanager
7、如果数据不均衡,可以用命令实现集群的再平衡
	sbin/start-balancer.sh

workers的作用:在启动整个模块时会根据workers中的地址去各节点的服务。

注意:workers不是决定谁是集群中的节点。

只要配置了免密登录,并且在配置文件里配置了NameNode地址,即可加入。

5.5 退役旧数据节点

5.5.1 添加白名单

白名单:在白名单的主机节点才能被允许访问NameNode。

配置白名单步骤:

a. 在NameNode(hadoop102)的/opt/module/hadoop-3.1.3/etc/hadoop目录下创建whitelist文件

vim /opt/module/hadoop-3.1.3/etc/hadoop/whitelist
添加以下内容(不添加hadoop105) -- 注意:不能有空格和空行
    hadoop102
    hadoop103
    hadoop104

b. 在NameNode的hdfs-site.xml配置文件中增加dfs.hosts属性(并重启NameNode)

    
        dfs.hosts
        /opt/module/hadoop-3.1.3/etc/hadoop/whitelist
    

c. 配置文件分发 — 有需求可分发

xsync hdfs-site.xml

注意:虽然修改集群上某一个节点的配置后其他节点也需要同步,但是白名单只要在NameNode所在的节点上即可生效,可以不用分发

d. 刷新 NameNode

hdfs dfsadmin -refreshNodes

e. 在 web 浏览器上查看

在hadoop102:9870上的DataNode上可以查看

5.5.2 黑名单退役

黑名单作用: 在黑名单上的主机都会被强制退出

配置黑名单步骤:

a. 在NameNode(hadoop102)的/opt/module/hadoop-3.1.3/etc/hadoop目录下创建blacklist文件

vim /opt/module/hadoop-3.1.3/etc/hadoop/blacklist
添加以下内容(不添加hadoop105) -- 注意:不能有空格和空行
    hadoop102
    hadoop103
    hadoop104

b. 在NameNode的hdfs-site.xml配置文件中增加dfs.hosts.exclude属性(并重启NameNode)

    
        dfs.hosts.exclude
        /opt/module/hadoop-3.1.3/etc/hadoop/blacklist
    

c. 配置文件分发 — 有需求可分发

xsync hdfs-site.xml

d. 刷新 NameNode

hdfs dfsadmin -refreshNodes

e. 在 web 浏览器上查看

在hadoop102:9870上的DataNode上可以查看

5.6 Datanode多目录配置 — 可略

1)DataNode也可以配置成多个目录,每个目录存储的数据不一样。即:数据不是副本

2)具体配置如下

​ 打开配置文件 hdfs-site.xml

​ 配置内容如下


        dfs.datanode.data.dir
		file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2

你可能感兴趣的:(Hadoop,hadoop,big,data)