【Hadoop生态】HDFS的元数据管理机制二

简介: 【Hadoop生态】HDFS的元数据管理机制二

# 1. 元数据目录相关文件

在Hadoop的HDFS首次部署好配置文件之后,并不能马上启动使用,而是先要对文件系统进行格式化。需要在NameNode(NN)节点上进行如下的操作:

```bash

$HADOOP_HOME/bin/hdfs namenode –format

```

在这里要注意两个概念,一个是文件系统,此时的文件系统在物理上还不存在;二就是此处的格式化并不是指传统意义上的本地磁盘格式化,而是一些==清除与准备工作==。

格式化完成之后,将会在$dfs.namenode.name.dir/current目录下创建如下的文件结构,这个目录也正是namenode元数据相关的文件目录:

![在这里插入图片描述](https://ucc.alicdn.com/images/user-upload-01/7ab7ca0689c845aabe0f0cef790afc7f.jpeg#pic_center)


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

![在这里插入图片描述](https://ucc.alicdn.com/images/user-upload-01/6a4ad06a555e4585937132f55bda433f.jpeg#pic_center)


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

下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。



<font color=red size=5>VERSION</font>

>namespaceID=934548976

clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196

cTime=0

storageType=NAME_NODE

blockpoolID=BP-893790215-192.168.24.72-1383809616115

layoutVersion=-47


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

storageType说明这个文件存储的是什么进程的数据结构信息(如果是DataNode,storageType=DATA_NODE);

cTime NameNode存储系统创建时间,首次格式化文件系统这个属性是0,当文件系统升级之后,该值会更新到升级之后的时间戳;

layoutVersion表示HDFS永久性数据结构的版本信息,是一个负整数。

补充说明:

格式化集群的时候,可以指定集群的cluster_id,但是不能与环境中其他集群有冲突。如果没有提供cluster_id,则会自动生成一个唯一的ClusterID。

```bash

$HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>

```

<font color=red size=5>seen_txid</font>

>$dfs.namenode.name.dir/current/seen_txid非常重要,是存放transactionId的文件,format之后是0,它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候,会按照seen_txid的数字,循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候,一定要比对seen_txid内的数字是不是你edits最后的尾数。

Fsimage & edits

$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件,及其对应的md5校验文件。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
目录
相关文章
|
XML 存储 分布式计算
【赵渝强老师】史上最详细:Hadoop HDFS的体系架构
HDFS(Hadoop分布式文件系统)由三个核心组件构成:NameNode、DataNode和SecondaryNameNode。NameNode负责管理文件系统的命名空间和客户端请求,维护元数据文件fsimage和edits;DataNode存储实际的数据块,默认大小为128MB;SecondaryNameNode定期合并edits日志到fsimage中,但不作为NameNode的热备份。通过这些组件的协同工作,HDFS实现了高效、可靠的大规模数据存储与管理。
1718 70
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
1124 6
|
SQL 分布式计算 关系型数据库
Hadoop-24 Sqoop迁移 MySQL到Hive 与 Hive到MySQL SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
Hadoop-24 Sqoop迁移 MySQL到Hive 与 Hive到MySQL SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
466 0
|
SQL 分布式计算 关系型数据库
Hadoop-23 Sqoop 数据MySQL到HDFS(部分) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
Hadoop-23 Sqoop 数据MySQL到HDFS(部分) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
287 0
|
SQL 分布式计算 关系型数据库
Hadoop-22 Sqoop 数据MySQL到HDFS(全量) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
Hadoop-22 Sqoop 数据MySQL到HDFS(全量) SQL生成数据 HDFS集群 Sqoop import jdbc ETL MapReduce
380 0
|
9月前
|
数据采集 存储 安全
数据治理≠数据管理!90%的企业都搞错了重点!
在数字化转型中,数据不一致、质量差、安全隐患等问题困扰企业。许多组织跳过基础的数据管理,直接进行数据治理,导致方案难以落地。数据管理涵盖数据生命周期中的采集、存储、处理等关键环节,决定了数据是否可用、可靠。本文详解数据管理的四大核心模块——数据质量、元数据、主数据与数据安全,并提供构建数据管理体系的四个阶段:评估现状、确定优先级、建立基础能力与持续改进,助力企业夯实数据基础,推动治理落地。
|
存储 数据管理 数据格式
数据治理 vs. 数据管理:别再傻傻分不清!
数据治理 vs. 数据管理:别再傻傻分不清!
634 10
|
9月前
|
数据采集 存储 SQL
数据管理四部曲:元数据管理、数据整合、数据治理、数据质量管控
老张带你搞定企业数据管理难题!数据找不到、看不懂、用不好?关键在于打好元数据管理、数据整合、数据治理和数据质量管控四大基础。四部曲环环相扣,助你打通数据孤岛,提升数据价值,实现精准决策与业务增长。
数据管理四部曲:元数据管理、数据整合、数据治理、数据质量管控
|
人工智能 关系型数据库 分布式数据库
拥抱Data+AI|“全球第一”雅迪如何实现智能营销?DMS+PolarDB注入数据新活力
针对雅迪“云销通App”的需求与痛点,本文将介绍阿里云瑶池数据库DMS+PolarDB for AI提供的一站式Data+AI解决方案,助力销售人员高效用数,全面提升销售管理效率。

相关实验场景

更多