首页 > 编程语言 >HDFS NameNode元数据管理

HDFS NameNode元数据管理

时间:2024-09-25 18:55:14浏览次数:10  
标签:HDFS 文件 fsimage edits 数据管理 内存 NameNode 数据

一、什么是元数据

在HDFS中,元数据主要指的是文件相关的元数据,由NameNode管理维护。从广义的角度来说,因为NameNode还需要管理众多DataNode节点,因此DataNode的位置和健康状态信息也属于元数据。

二、元数据管理概述

1.文件相关元数据类型

在HDFS中,文件相关元数据具有两种类型:

文件自身属性信息:文件名称、权限,修改时间,文件大小,复制因子,数据块大小。

HDFS NameNode元数据管理_HDFS

文件块位置映射信息:记录文件块和DataNode之间的映射信息,即哪个块位于哪个节点上。

HDFS NameNode元数据管理_文件系统_02

2.存储相关元数据类型

按存储形式分为内存元数据和元数据文件两种,分别存在内存和磁盘上。

内存元数据

为了保证用户操作元数据交互高效,延迟低,NameNode把所有的元数据都存储在内存中,我们叫做内存元数据。内存中的元数据是最完整的,包括文件自身属性信息、文件块位置映射信息。 
但是内存的致命问题是,断点数据丢失,数据不会持久化。因此NameNode又辅佐了元数据文件来保证元数据的安全完整。

元数据文件有两种:fsimage内存镜像文件、Edits log编辑日志

fsimage 内存镜像文件

是内存元数据的一个持久化的检查点。但是fsimage中仅包含Hadoop文件系统中文件自身属性相关的元数据信息,但不包含文件块位置的信息。文件块位置信息只存储在内存中,是由datanode启动加入集群的时候,向namenode进行数据块的汇报得到的,并且后续间断指定时间进行数据块报告。
持久化的动作是数据从内存到磁盘的IO过程。会对namenode正常服务造成一定的影响,不能频繁的进行持久化。

Edits log编辑日志

为了避免两次持久化之间数据丢失的问题,又设计了Edits log编辑日志文件。文件中记录的是HDFS所有更改操作(文件创建,删除或修改)的日志,文件系统客户端执行的更改操作首先会被记录到edits文件中。

3.NameNode加载元数据文件顺序

1.fsimage和edits文件都是经过序列化的,在NameNode启动的时候,它会先将fsimage文件中的内容加载到内存中,之后再执行edits文件中的各项操作,使得内存中的元数据和实际的同步,存在内存中的元数据支持客户端的读操作,也是最完整的元数据。
2.当客户端对HDFS中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据会更新到内存元数据中。因为fsimage文件一般都很大(GB级别的很常见),如果所有的更新操作都往fsimage文件中添加,这样会导致系统运行的十分缓慢。
3.HDFS这种设计实现着手于:一是内存中数据更新、查询快,极大缩短了操作响应时间;二是内存中元数据丢失风险颇高(断电等),因此辅佐元数据镜像文件(fsimage)+编辑日志文件(edits)的备份机制进行确保元数据的安全。
4.NameNode维护整个文件系统元数据。因此,元数据的准确管理,影响着HDFS提供文件存储服务的能力。

三、元数据管理相关目录文件

1.元数据本地存储目录

namenode元数据存储目录由参数:dfs.namenode.name.dir指定;
格式化完成之后,将会在$dfs.namenode.name.dir/current目录下创建如下的文件:

HDFS NameNode元数据管理_元数据_03

dfs.namenode.name.dir是在hdfs-site.xml文件中配置的,默认值如下:

HDFS NameNode元数据管理_文件系统_04

2.元数据相关文件--VERSION

namespaceID/clusterID/blockpoolID 
这些都是HDFS集群的唯一标识符。标识符被用来防止DataNodes意外注册到另一个集群中的namenode上。这些标识在联邦(federation)部署中特别重要。联邦模式下,会有多个NameNode独立工作。每个的NameNode提供唯一的命名空间(namespaceID),并管理一组唯一的文件块池(blockpoolID)。clusterID将整个集群结合在一起作为单个逻辑单元,在集群中的所有节点上都是一样的。

HDFS NameNode元数据管理_文件系统_05

storageType
  说明这个文件存储的是什么进程的数据结构信息。如果是DataNode节点,storageType=DATA_NODE。
cTime
  NameNode存储系统创建时间,首次格式化文件系统这个属性是0,当文件系统升级之后,该值会更新到升级之后的时间戳;
layoutVersion
  HDFS元数据格式的版本。HDFS升级时会进行更新。

3.元数据相关文件--seen_txid

包含上一次checkpoint时的最后一个事务ID,这不是NameNode接受的最后一个事务ID。
seen_txid内容不会在每个事务性操作上都更新,只会在checkpoint时更新。
NameNode启动时会检查seen_txid文件,以验证它至少可以加载该数目的事务。如果无法验证加载事务,NameNode将中止启动。

HDFS NameNode元数据管理_文件系统_06

4.元数据相关文件--fsimage

元数据镜像文件。每个fsimage文件还有一个对应的.md5文件,其中包含MD5校验和,HDFS使用该文件来防止磁盘损坏文件异常。

HDFS NameNode元数据管理_元数据_07

fsimage数据查看

fsimage文件是Hadoop文件系统元数据的一个永久性的检查点,包含Hadoop文件系统中的所有目录和文件idnode的序列化信息;对于文件来说,包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等;而对于目录来说,包含的信息主要有修改时间、访问控制权限等信息。

oiv是offline image viewer的缩写,可将hdfs fsimage文件的内容转储为人类可读的格式。
常用命令:hdfs oiv -i fsimage_0000000000000000050 -p XML -o fsimage.xml

HDFS NameNode元数据管理_HDFS_08

5.元数据相关文件--edits log

已完成且不可修改的编辑日志。这些文件中的每个文件都包含文件名定义的范围内的所有编辑日志事务。在HA高可用性部署中,主备namenode之间可以通过edits log进行数据同步。

HDFS NameNode元数据管理_元数据_09

edits log文件内容查看

edits log文件存放的是Hadoop文件系统的所有更新操作记录日志。
文件系统客户端执行的所有写操作首先会被记录到edits文件中。

oev是offline edits viewer(离线edits查看器)的缩写,该工具不需要hadoop集群处于运行状态。
命令:hdfs oev -i edits_0000000000000000011-0000000000000000025 -o edits.xml
在输出文件中,每个RECORD记录了一次操作,示例如下:

HDFS NameNode元数据管理_HDFS_10

四、SecondaryNameNode

背景

当HDFS集群运行一段事件后,就会出现下面一些问题:
1.edits logs因操作记录多会变的很大,
2.fsimage因间隔时间长将会变得很旧;
3.namenode重启会花费很长时间,因为有很多改动要从edits log合并到fsimage文件上;
4.如果频繁进行fsimage持久化,又会影响NN正常服务,毕竟IO操作是一种内存到磁盘的耗精力操作.

1.SNN职责概述

因此为了克服上述问题,需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件,这样也会减小在NameNode上的压力。
SecondaryNameNode就是来帮助解决上述问题的,它的职责是合并NameNode的edit logs到fsimage文件中。
因此常把secondarynamenode称之为主角色的辅助角色,辅助NameNode做一些事。

 

HDFS NameNode元数据管理_文件系统_11

2.SNN Checkpoint--概述

Checkpoint核心是把fsimage与edits log合并以生成新的fsimage的过程。
结果:fsimage版本不断更新不会太旧、edits log文件不会太大。

3.SNN Checkpoint--流程

1、当触发checkpoint操作条件时,SNN发送请求给NN滚动edits log。然后NN会生成一个新的编辑日志文件:edits new,便于记录后续操作记录。
2、SNN会将旧的edits log文件和上次fsimage复制到自己本地(使用HTTP GET方式)。
3、SNN首先将fsimage载入到内存,然后一条一条地执行edits文件中的操作,使得内存中的fsimage不断更新,这个过程就是edits和fsimage文件合并。合并结束,SNN将内存中的数据dump生成一个新的fsimage文件。
4、SNN将新生成的Fsimage new文件复制到NN节点。至此刚好是一个轮回,等待下一次checkpoint触发SecondaryNameNode进行工作,一直这样循环操作。

HDFS NameNode元数据管理_元数据_12

4.SNN Checkpoint--触发机制

# core-site.xml
dfs.namenode.checkpoint.period=3600  //两次连续的checkpoint之间的时间间隔。默认1小时
dfs.namenode.checkpoint.txns=1000000 //最大没有执行checkpoint事务的数量,满足将强制执行紧急checkpoint,即使尚未达到检查点周期。默认100万事务数量。

五、NameNode元数据恢复

1.NameNode存储多目录

namenode元数据存储目录由参数:dfs.namenode.name.dir指定。
dfs.namenode.name.dir属性可以配置多个目录,各个目录存储的文件结构和内容都完全一样,相当于备份,这样做的好处是当其中一个目录损坏了,也不会影响到hadoop的元数据,特别是当其中一个目录是NFS(网络文件系统Network File System,NFS)之上,即使你这台机器损坏了,元数据也得到保存。

2.从SecondaryNameNode恢复

SecondaryNameNode在checkpoint的时候会将fsimage和edits log下载到自己的本机上本地存储目录下。并且在checkpoint之后也不会进行删除。
如果NameNode中的fsimage真的出问题了,还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage,虽然已经不是最新的fsimage,但是我们可以将损失减小到最少!

HDFS NameNode元数据管理_文件系统_13

 

 

 

 

 

"一劳永逸" 的话,有是有的,而 "一劳永逸" 的事却极少



标签:HDFS,文件,fsimage,edits,数据管理,内存,NameNode,数据
From: https://blog.51cto.com/u_8901540/12111441

相关文章

  • Cloudera安装攻略:让你的数据管理更高效!
    引言:之前文章《深度挖掘|Cloudera安装不再难!基础环境搭建全解析》中,我们深入探讨了如何在企业环境中精心准备系统环境,为大数据平台Cloudera 搭建奠定坚实基础。今天,我们将正式进行ClouderaManager的下载安装与部署。ClouderaManager下载步骤一:环境检查与准备确保系统环境已......
  • 大数据-140 - ClickHouse 集群 表引擎详解5 - MergeTree CollapsingMergeTree 与其他
    点一下关注吧!!!非常感谢!!持续更新!!!目前已经更新到了:Hadoop(已更完)HDFS(已更完)MapReduce(已更完)Hive(已更完)Flume(已更完)Sqoop(已更完)Zookeeper(已更完)HBase(已更完)Redis(已更完)Kafka(已更完)Spark(已更完)Flink(已更完)ClickHouse(正在更新···)章节内容上节我们完成了如下的内容:MergeTree实测案例Re......
  • React 入门第九天:与后端API的集成与数据管理
    在React学习的第九天,我集中学习了如何与后端API进行集成。这一步是将静态的React应用转变为动态、可交互的关键。通过与后端通信,我们可以从服务器获取数据、发送用户输入以及处理复杂的业务逻辑。1.使用fetch进行数据请求React没有内置的HTTP库,因此我们通常使用浏览器提供的fetch......
  • Hadoop三大组件之HDFS(一)
    1.HDFS的架构HDFS(HadoopDistributedFileSystem)采用主从架构,由一个NameNode(主节点)和多个DataNode(从节点)组成。NameNode负责管理数据块映射信息(如文件名、文件目录、权限、块位置等)并配置副本策略,而DataNode负责存储实际的数据块。SecondaryNameNode辅助NameNode进行元......
  • HBase与HDFS&Hive
    在大数据领域中,HBase和HDFS是两种常用的存储系统。它们各自有其独特的特性和优势,但也有一些关键的差异。理解这些差异可以帮助我们更好地选择适合我们需求的存储解决方案。HBase:HBase是一个分布式列存储数据库,它是ApacheHadoop生态系统的一部分。它以行键为索引,支持高性能的随机......
  • 数据中台的退潮与数据飞轮的崛起:未来企业数据管理的新趋势?
    在过去的几年中,数据中台一度被认为是企业打造核心数据能力建设的灵丹妙药。然而,随着时间的推移,这一模式渐显疲态,一些企业甚至开始质疑,数据中台真的是一个万能的解答吗?近期,“数据飞轮”概念的兴起似乎指引了一个新方向,但我们需要清楚地理解这其中的转变到底意味着什么。首先,数据中......
  • java+vue计算机毕设大学生体测数据管理系统【源码+开题+论文+程序】
    本系统(程序+源码)带文档lw万字以上文末可获取一份本项目的java源码和数据库参考。系统程序文件列表开题报告内容研究背景随着高等教育的普及与体育健康意识的提升,大学生体质健康测试(简称“体测”)已成为衡量学生综合素质不可或缺的一环。然而,传统的手工记录与管理体测数据......
  • 大数据-140 - ClickHouse 集群 表引擎详解5 - MergeTree CollapsingMergeTree 与其他
    点一下关注吧!!!非常感谢!!持续更新!!!目前已经更新到了:Hadoop(已更完)HDFS(已更完)MapReduce(已更完)Hive(已更完)Flume(已更完)Sqoop(已更完)Zookeeper(已更完)HBase(已更完)Redis(已更完)Kafka(已更完)Spark(已更完)Flink(已更完)ClickHouse(正在更新···)章节内容上节我们完成了如下的内容:MergeTre......
  • Hadoop(十二)NameNode 和 SecondaryNameNode
    一、NN和2NN工作机制1、NameNode中的元数据存储在哪里?存储在NameNode节点的磁盘中会导致效率过低,因为经常需要进行随机访问和响应客户请求;存储在内存中,一旦元数据丢失,整个集群就无法工作,也不合适。因此产生了在磁盘中备份元数据的FsImage。引入Edits文件(只进行追加操作,效率很......
  • 六种主流ETL工具的比较与Kettle的实践练习指南--MySQL、hive、hdfs等之间的数据迁移
            在数据集成和数据仓库建设中,ETL(Extract,Transform,Load)工具扮演着至关重要的角色。本文将对六种主流ETL工具进行比较,并深入探讨Kettle的实践应用。一、六种主流ETL工具比较1.DataPipeline设计及架构:专为超大数据量、高度复杂的数据链路设计的灵活、可扩......