HDFS_06_HDFS服务器节点的分类
持续更新 大数据 文章…
1. HDFS服务器节点的分类 ⭐️
经过前面的铺垫，现在是正式进入了 HDFS。
分布式文件系统（DFS）是一个统称，HDFS 是指 Hadoop 的分布式文件系统，HDFS 原理和 DFS 类似。所以你会发现，HDFS 和前面学的 DFS 很类似。
HDFS 节点分为三类： NameNode、DataNode、SecondaryNameNode
; 1.1 为何要对HDFS服务器节点进行分类?
我们先看看上面的图，客户端的文件被拆分成了数据块，每个数据块有三个副本，众多的数据块几乎毫无规律的存放各个 DataNode 上。现在用户想要从 HDFS 上拉取数据，对于 HDFS ，客户想要拉取数据就要自己去各个 DataNode 上面去找对应的数据块然后再组合成原文件。实际开发当中 DataNode 的数量很多，如果每次用户都要去遍历全部的 DataNode 才能找到数据块的话，这个效率是相当低的！所以，为了提高效率，我们把 HDFS 服务器节点分为三类。
1.2 NameNode（NN）
NameNode，一般简称为 NN， 在HDFS当中扮演了十分重要的角色，所以一定要保证 NN 的安全性！
1.2.1 NameNode 是干什么的？
NameNode 只要是用来：
- 接收客户端的请求：用户存数据、取数据请求都要经过 NN
- 存储 用户上传的文件的元数据 （会把该信息实例化到本地硬盘）
- 存储 文件与数据块的映射关系 （会把该信息实例化到本地硬盘）
- 存储 数据块与DataNode的映射关系 *（会把该信息实例化到本地硬盘）
这样做了之后，客户端发送拉取文件的请求到 NameNode ，NameNode 就可以告诉客户端该文件对应的是哪些数据块，这些数据块都存放在哪些 DataNode 上，然后客户端就可以有目的性地去 DataNode 上拉取数据块最后组合成原文件，所以有了 NN 的存在，极大提高了效率！
1.2.2 NN 存在的问题
1、问题1
大家思考一个问题，假设现在刚刚启动集群，有几个 DataNode 没有成功启动，然后这个时候客户端要拉取数据了，客户仍然按照 NN 记录的数据块与 DataNode 映射关系去对应的 DataNode 拿数据，恰好就有 DataNode 没有启动，那么用户该如何拿数据呢？
如上图：存储关键数据块的 DataNode 都关机了，这个时候客户端仍然按照 NN 的描述去 DataNode 拿数据，肯定是拿不到的，那么如何解决这个问题呢？
; 解决方法：
- 不能把 NN 存储的数据块与DataNode的映射关系放在本地磁盘上：如果恰好有存储关键数据块的 DataNode 关机了，用户就永远无法拿到对应数据块组成原文件了。
- DataNode 定时给 NN 上报自己有哪些数据块：这样就可以每次都保证用户可以准确无误的找到对应的数据块了！NN 也可以知道哪些 DataNode 停止工作，那么 NN 就会把关机的 DataNode 上的缺失的数据块补充到其他正常的 DataNode 上，从而保证每个数据块达到最小副本数。
1.2.3 心跳机制
所谓心跳机制就是，NN 会与 DataNode 进行通讯，就像心跳一样。这样 NN 就可以知道哪些 DataNode 在正常工作，哪些关机了。 然后 NN 就会把关机的 DataNode 上的缺失的数据块补充到其他正常的 DataNode 上，从而保证每个数据块达到最小副本数。
如果 DataNode 超过 3秒没有和 NN 进行心跳通讯，NN 就会暂时把该 DN 标记为不可用
如果 DataNode 超过一定时间（默认是10分30秒）没有和 NN 进行心跳通讯，NN 就会认为把该 DN 停止工作，会把关机的 DataNode 上的缺失的数据块补充到其他正常的 DataNode 上，从而保证每个数据块达到最小副本数。
超时时长的计算公式为： timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。 而默认heartbeat.recheck.interval 大小为5分钟，dfs.heartbeat.interval默认为3秒，所以默认是 10分30秒。
; 1.3 DataNode（DN）
1.3.1 DN 是干什么的？
- 存储数据块：每个 DN 都会存储数据块，而且每个数据块都会有唯一的名字。DN 不擅长存储小文件。
- 与 NN 保持心跳
- 开机会向 NN 会报自己有哪些数据块：为 NN 补充数据块与 DN 的映射关系信息，如果数据块少了，NN 就会补充数据块以保证每个数据块达到最小副本数
1.4 SecondaryNameNode（SNN）
1.4.1 SNN 存在的意义
通过日志和快照解决 NameNode 单点故障问题
1.4.1 如何解决 NN 单点故障？
1、传统解决方案
- 日志机制
- 做任何操作之前先记录日志
- 当 NN 下次启动的时候，只需要重新按照以前的日志 “重做” 一遍即可
- 缺点
- edits 文件大小不可控，随着时间的发展，集群启动的时间会越来越长
- 有可能日志中存在大量的无效日志
- 优点
- 绝对不会丢失数据
- 拍摄快照
- 我们可以将内存中的数据写出到硬盘上
- 序列化
- 启动时还可以将硬盘上的数据写回到内存中
- 反序列化
- 缺点
- 关机时间过长
- 如果是异常关机，数据还在内存中，没法写入到硬盘
- 如果写出频率过高，导致内存使用效率低（stop the world） JVM
- 优点
- 启动时间较短
2、SNN 解决方案
- 解决思路（日志edits+快照fsimage）
- 让日志大小可控
- 定时快照保存
- NameNode 文件目录
- 查看目录
/var/huoborn/hadoop/full/dfs/name/current- edits_0000000000000000001-0000000000000000019
- edits_inprogress_0000000000000000020
- 当前已经正在执行的操作的日志信息
- 这些日志信息还没有被合并到镜像中
- fsimage_0000000000000000000
- fsimage_0000000000000000000.md5
- fsimage_0000000000000000019
- fsimage_0000000000000000019.md5
- 完整性校验规则
- seen_txid –>19
- VERSION
- 解决方案
- 当我们启动一个集群的时候，会产生四个文件
- edits_0000000000000000001
- fsimage_00000000000000000
- seen_txid
- VERSION
- 我们每次操作都会记录日志 –>edits_inprogress-000000001
- 随和时间的推移，日志文件会越来越大，当达到阈值的时候（64M 或 3600秒）
dfs.namenode.checkpoint.period 每隔多久做一次checkpoint ，默认3600s
dfs.namenode.checkpoint.txns 每隔多少操作次数做一次checkpoint，默认1000000次
dfs.namenode.checkpoint.check.period 每个多久检查一次操作次数，默认60s
- 会生成新的日志文件
- edits_inprogress-000000001 –>edits_0000001
- edits_inprogress-000000001 –>edits_0000001
1.4.2 SNN 数据恢复步骤
- 强行杀死 NameNode 节点
- 清空 namenode 下 name 中的 fsimage 和 edtis 文件
[root@node01 ~]
- secondary namenode下的name中的fsimage和edits复制到namenode对应文件夹中
[root@node01 ~]
- 启动namenode
- hadoop-daemon.sh start namenode
- 访问namenode节点页面，成功
下期讲解 HDFS_07_安全模式.....
Original: https://blog.csdn.net/qq_48262902/article/details/121552076
Author: 火晟君
Title: HDFS_06_HDFS服务器节点的分类
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/664916/
转载文章受原作者版权保护。转载请注明原作者出处！