hadoop-NameNode、DataNode相关理论知识

最新推荐文章于 2024-04-26 18:38:10 发布

jsx____

最新推荐文章于 2024-04-26 18:38:10 发布

阅读量439

点赞数

分类专栏： hadoop 大数据文章标签： hadoop 大数据 hdfs

本文链接：https://blog.csdn.net/jsx____/article/details/108455083

版权

hadoop 同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

大数据

11 篇文章 0 订阅

订阅专栏

参考：hadoop权威指南 章节：3.2.2 11.1.1

2020_7_15

心跳机制DN-NN：

上传datanode链接状态为3s一次，若10分钟未响应，namenode则判断该datanode为不可用

上传block块状态信息为60分钟一次

块数据信息非实时上传，是在写入时由客户端上传，若其中一个datanode宕机，也会在一小时的周期后才会通知到namenode，但是如果这时执行下载，若namenode分配的block存储节点不通，会反馈会namenode ，进行重新分配

若一台datanode节点宕机期间，执行删除，会只删除元数据和正常的datanode中存储的数据，元数据也随之删除，这时即使宕机的datanode恢复正常，宕机期间执行删除的数据还会在里面，但是变成了垃圾数据（没有元数据，无法定位）。

多目录存储datanode数据

分开存储的意义在于，假如有磁盘损坏，

一个datanode不会完全损坏

NameNode（nn）

参考：hadoop权威指南11.1.1

VERSION（版本）了解即可

参数：

layout version
是一个负整数参数，他描述持久性数据结构的版本，与hadoop发布包版本号无关（此参数没什么卵用），namenode改变了一点就会递减

namespaceID
文件系统命名空间的唯一标识符，是namenode初始化时创建的。

clusterID
是集群id，多集群需要这个参数

cTime
标记了namenode 存储空间的创建时间，默认0

storageType
说明该目录的文件属于namenode

blockpool
块池id

fsimage

元数据镜像文件

存储hdfs的永久检查点文件，目录信息文件信息，检查点只在特殊条件下更新检查点。namenode可以根据检查点和日志文件，组合成元数据，元数据放在内存上。

edits

操作日志文件

日志,带有_inprogress标识的代表这时当前版本的日志，持续追加，在特定时刻才会创建新的替换旧的，旧的会被更名，继续存储在该目录下

senn_txid

文件：最后一个edits文件的版本号

in_use.lokc

current目录的上一级目录有一个in_use.lock文件，那是一个锁文件，防止多namenode互相操作元数据

元数据

namenode根据fsimage最新版本和edits最新版本整合出来的，与客户的进行交互的数据

里面存了数据的块信息路径信息等

fsimage和edits 存储在磁盘上，而元数据存储在内存中

fsimage元数据镜像文件-重点理解他是元数据的镜像文件，虽然内容在时间上不同，但是他是稍微落后于内存中的元数据且存在本地磁盘上的“元数据”

SecondaryNameNode(2nn)执行的检查点操作

secondarynamenode：以下可能会被简称2nn，namenode简称nn

2nn不能起到namenode节点的作用（不是热备份），他的意义在于辅助namenode 更新检查点

namenode：

1启动时namenode将fsimage最新版和edits_inprogress文件从磁盘加载到内存，组成元数据。因为不满足条件的情况下，2nn是不会合并元数据镜像文件的，所以本地磁盘的fsimage的内容落后于操作日志。所以开启namenode会将其整合成元数据。

2客户端进行操作时，namenode上的元数据的更新是实时的

3 操作namenode会更新元数据，namenode更新元数据同时，会向磁盘的edits_inprogress文件追加操作日志。在存在2NN的情况下namenode不参与更改fsimage。

secondarynode：

更新检查点，将日志edits操作的内容更新至fsimage，通过http拉取数据

1 SecondaryNamenode请求namenode 是否进行检查点操作（checkpoint）

2 NameNode响应请求

3 secondarynamenode将edits_inprogress更名为edits+旧版本号，同时创建一个新的edits_inprogress文件，nn进行写入日志只会向edits_inprogress内写

4将更名后的上一个版本的edits文件和最新版的fsimage文件远程拷贝至secondarynamenode所在的节点里。通过HTTP 拉取。

5在secondarynamenode中进行合并，合并产生新的fsimage（元数据镜像文件）

6将合并的元数据镜像导入namenode，将导入的fsimage文件更名为最新版本，开机时namenode会自动拿最新的版本的镜像文件合并元数据

客户端操作时，元数据和日志（edits）为实时更新。磁盘上存储的元数据镜像文件（fsimage）不会实时更新，他会以检查点的形式更新，存储最新版本和上一个版本的镜像文件（存两个），在每次开启hadoop运行构建元文件时，namenode会先将最新的日志（edits_inprogress）和镜像文件(fsimage最新版本)进行整合，产生最新版本的元数据，放在内存上以供调用和操作。

元数据存在于内存上，系统关闭元数据就会被销毁，日志（edits）和目录文件信息（fsimage）存放在本地

检查点更新条件

检查点更新当然不是一直更新，那样很浪费资源。但也不可能太久不更新，这样NN在启动时合并元数据将浪费大量的时间。所以2NN有一系列检擦机制，在合理的时间与数据量上获取平衡。

1．每隔一小时更新一次检查点

2．一分鐘檢查一次事务，事务达到100w条，即使没有达到一个小时也会更新检查点

当达到检查点更新条件时， secondarynamenode，他会拿namenode中的最新版本的镜像文件（fsimage）和当前使用的日志（新建edits_inprogress，将原日志文件更名为历史版本，历史版本命名规则为：<edits_该日志开始使用的版本号-该日志结束的版本号>，并去除inprogress标识），整合成最新的元数据镜像文件（不更名原fsimage，直接创建一个版本号为更高的fsimage（版本号+1），namenode调用时会自动拿版本号最高的fsimage），并发回namenode。且nn只会存储版本最新和较新的两个元数据镜像文件。