元数据管理
1.元数据管理概述
> HDFS分类-类型分包括以下几部分
文件、目录自身的属性信息,例如文件名,目录名,修改信息等
文件记录的信息的存储相关的信息,例如存储块信息,分块情况,副本个数等
记录 HDFS 的 Datanode 的信息,用于 DataNode 的管理。
> 按形式分
内存元数据 内存
元数据文件两种 磁盘
> HDFS 磁盘上元数据文件分为两类,用于持久化存储:
fsimage 镜像文件:是元数据的一个持久化的检查点,包含 Hadoop 文件系统中的所有目录和文件元数据信息,但不包含文件块位置的信息。
Edits 编辑日志:存放的是 Hadoop 文件系统的所有更改操作(文件创建,删除或修改)的日志,文件系统客户端执行的更改操作首先会被记录到 edits 文件中。
> ps:所谓的持久化,就是将数据保存到硬盘中,使得在应用程序或机器重启后可以继续访问之前保存的数据
当客户端对 HDFS 中的文件进行新增或者修改操作,操作记录首先被记入 edits 日志文件中,
当客户端操作成功后,相应的元数据会更新到内存元数据中。因为 fsimage 文件一般都很大
(GB 级别的很常见),如果所有的更新操作都往 fsimage文件中添加,这样会导致系统运行的
十分缓慢。
HDFS 这种设计实现着手于:一是内存中数据更新、查询快,极大缩短了操作响应时间;
二是内存中元数据丢失风险颇高(断电等),因此辅佐元数据镜像文件(fsimage)+编辑日
志文件(edits)的备份机制进行确保元数据的安全。
2.元数据目录
在 Hadoop 的 HDFS 首次部署好配置文件之后,并不能马上启动使用,而是先要对文件系
统进行格式化。需要在 NameNode(NN)节点上进行如下的操作:
$HADOOP_HOME/bin/hdfs namenode –format
文件系统:此时的文件系统在物理上还不存在
格式化:格式化并不是指传统意义上的本地磁盘格式化,而是一些清除与准备工作。
> HDFS中文件块目录结构具体格式如下:
${dfs.datanode.data.dir}/
├── current
│ ├── BP-526805057-127.0.0.1-1411980876842
│ │ └── current
│ │ ├── VERSION
│ │ ├── finalized
│ │ │ ├── blk_1073741825
│ │ │ ├── blk_1073741825_1001.meta
│ │ │ ├── blk_1073741826
│ │ │ └── blk_1073741826_1002.meta
│ │ └── rbw
│ └── VERSION
└── in_use.lock
目录在哪是在 hdfs-site.xml的dfs.namenode.name.dir指定 可以是多个
> seen_txid:
$dfs.namenode.name.dir/current/seen_txid 非常重要,是存放 transactionId 的文
件,format 之后是 0,它代表的是 namenode 里面的 edits_*文件的尾数,namenode 重启的
时候,会按照 seen_txid的数字,循序从头跑 edits_0000001~到 seen_txid 的数字。所以
当你的 hdfs 发生异常重启的时候,一定要比对 seen_txid 内的数字是不是你 edits 最后的
尾数。
做完之后会在$dfs.namenode.name.dir/current创建文件结构:这个目录也正是 namenode 元数据相关的文件目录:
cat VERSION
namespaceID=1752067181
clusterID=cluster84
cTime=0
storageType=NAME_NODE
blockpoolID=BP-824456762-192.168.20.39-1508928616349
layoutVersion=-60
- namespaceID/clusterID/blockpoolID:HDFS 集群的唯一标识符.防止 DataNodes 意外注册到另一个集群中的 namenode 上
- storageType:说明这个文件存储的是什么进程的数据结构信息(如果是 DataNode,storageType=DATA_NODE);
- cTime:NameNode 存储系统创建时间,首次格式化文件系统这个属性是 0,当文件系统升级之后,该值会更新到升级之后的时间戳;
- layoutVersion :表示 HDFS 永久性数据结构的版本信息,是一个负整数。
3.SecondaryNameNode:
> 这个出现的原因:
HDFS 集群运行一段事件后
edit logs 文件会变的很大,怎么去管理这个文件是一个挑战。
NameNode 重启会花费很长时间,因为有很多改动要合并到 fsimage 文件上。
如果 NameNode 挂掉了,那就丢失了一些改动。因为此时的 fsimage 文件非常旧。
作用:减小sedit logs文的件的大小和得到一个最新的fsimage
文件,减少在namenode上的压力。相当于windows的恢复功能(可以说是快照)
职责:它的职责是合并 NameNode的editlogs到fsimage文件中。
4.checkpoint
> 简介:
每达到触发条件,会由secondary namenode 将 namenode 上积累的所有 edits 和一个
最新的 fsimage 下载到本地,并加载到内存进行 merge(这个过程称为 checkpoint)
> Checkpoint 触发条件
dfs.namenode.checkpoint.period:两次连续的 checkpoint 之间的时间间隔。默认 1 小时
dfs.namenode.checkpoint.txns:最大的没有执行 checkpoint 事务的数量,满足将强制执行紧急 checkpoint,即使尚未达到检查点周期。默认设置为 100 万
拓展
1.hdfs oiv命令
命令hdfs oiv用于将fsimage,edits文件转换成其他格式的,如文本文件、XML文件。
> HDFS查看fsimage,edits
命令说明
> 必要参数
-i,–inputFile <arg> 输入FSImage文件.
-o,–outputFile <arg> 输出转换后的文件,如果存在,则会覆盖
> 可选参数:
-p,–processor <arg> 将FSImage文件转换成哪种格式:(Ls|XML|FileDistribution).默认为Ls.
-h,–help 显示帮助信息
hdfs oiv -i fsimage_0000000000016975189 -o 123.xml
hdfs oiv -i /var/lib/hadoop-yarn/test00001/data/fsimage_0000000000016975189 -o fsimage.txt
2.hadoop命令fsck命令
在HDFS中,提供了fsck命令,用于检查HDFS上文件和目录的健康状态、获取文件的block块信息和位置信息等。
> 具体命令介绍
- move: 移动损坏的文件到/lost+found目录下
- delete: 删除损坏的文件
- openforwrite: 输出检测中的正在被写的文件
- list-corruptfileblocks: 输出损坏的块及其所属的文件
- files: 输出正在被检测的文件
- blocks: 输出block的详细报告 (需要和-files参数一起使用)
- locations: 输出block的位置信息 (需要和-files参数一起使用)
- racks: 输出文件块位置所在的机架信息(需要和-files参数一起使用)
例如要查看HDFS中某个文件的block块的具体分布,可以这样写:
hadoop fsck /your_file_path -files -blocks -locations -racks
> 实例
$ hadoop fsck /qpf/yyd/test/job.properties -files -blocks -locations -racks
DEPRECATED: Use of this script to execute hdfs command is deprecated.
Instead use the hdfs command for it.
Connecting to namenode via http://yhml01cs002:50070/fsck?ugi=yarn&files=1&blocks=1&locations=1&racks=1&path=%2Fqpf%2Fyyd%2Ftest%2Fjob.properties
FSCK started by yarn (auth:SIMPLE) from /172.20.1.36 for path /qpf/yyd/test/job.properties at Mon Nov 05 18:39:04 CST 2018
/qpf/yyd/test/job.properties 276 bytes, 1 block(s): OK
0. BP-824456762-192.168.20.39-1508928616349:blk_1074586437_845778 len=276 Live_repl=3 [/default/172.20.1.36:50010, /default/172.20.1.37:50010, /default/172.20.1.38:50010]
Status: HEALTHY
Total size: 276 B
Total dirs: 0
Total files: 1
Total symlinks: 0
Total blocks (validated): 1 (avg. block size 276 B)
Minimally replicated blocks: 1 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0
Missing replicas: 0 (0.0 %)
Number of data-nodes: 3
Number of racks: 1
FSCK ended at Mon Nov 05 18:39:04 CST 2018 in 3 milliseconds
The filesystem under path '/qpf/yyd/test/job.properties' is HEALTHY
> 参数解释
0. 表示block个数;
BP-824456762-192.168.20.39-1508928616349:blk_1074586437_845778表示block id;
len=276 表示该文件块大小;
Live_repl=3 表示该block块的副本数;
3.datanode存储目录说明
current目录:真正存放block数据块文件的地方
tmp目录:这个目录主要临时存放一些正在写入的block数据文件,成功写入完成后这个临时文件就会从tmp目录移动到current目录。
> 其中subdir说明
[yarn@yhml01cs005 ~]$ cd /home/yhml01/dfs/dn/current/BP-824456762-192.168.20.39-1508928616349/current/finalized
[yarn@yhml01cs005 finalized]$ ll
total 164
drwxr-xr-x 258 hdfs hdfs 8192 Dec 5 2017 subdir0
drwxr-xr-x 258 hdfs hdfs 8192 Jan 9 2018 subdir1
drwxr-xr-x 258 hdfs hdfs 8192 Feb 8 2018 subdir2
[yarn@yhml01cs005 subdir1]$ ll
total 52176
-rw-r--r-- 1 hdfs hdfs 999018 Dec 18 2017 blk_1073824301
-rw-r--r-- 1 hdfs hdfs 7815 Dec 18 2017 blk_1073824301_83516.meta
-rw-r--r-- 1 hdfs hdfs 8042801 Dec 18 2017 blk_1073824302
-rw-r--r-- 1 hdfs hdfs 62843 Dec 18 2017 blk_1073824302_83517.meta
-rw-r--r-- 1 hdfs hdfs 4356708 Dec 18 2017 blk_1073824303
-rw-r--r-- 1 hdfs hdfs 34047 Dec 18 2017 blk_1073824303_83518.meta
-rw-r--r-- 1 hdfs hdfs 1483913 Dec 18 2017 blk_1073824304
-rw-r--r-- 1 hdfs hdfs 11603 Dec 18 2017 blk_1073824304_83519.meta
-rw-r--r-- 1 hdfs hdfs 8042801 Dec 18 2017 blk_1073824305
可以看到这个目录主要存放了block数据文件,block数据文件的命名规则是blk_$BLOCKID$,还有就是block文件的元数据文件,元数据文件的命名规则是:blk_$BLOCKID$_$时间戳$,同时大家可以看到很多累似subdir00命名的文件夹,这些文件夹其中存放的也是block数据文件及其元数据文件,hadoop规定每个目录存放的block数据文件个数是有限制的,达到限制之后就会新建sub子目录进行存放,这些sub子目录包括current目录,都会和一个FSDir对象对应。
ps:机器不同配置的目录不同(dfs.data.dir, dfs.datanode.data.dir配置)
磁盘清理维护
一、清理目录
1、执行sudo -u hdfs hadoop fs -du -h /
查询hdfs中各目录的占用的空间,进入占用最多的目录中(/tmp目录等)
2、找到目录/tmp/repay_prpjpolicypayment占用了大量空间
3、执行hdfs dfs -rm -r /tmp/repay_prpjpolicypayment删除此目录下的文件夹
4、删除的文件会被保存到/user/hdfs/.Trash,清空回收站即可
二、清空回收站
1.由于HDFS有回收站,删除文件会先放到回收站里边,如果着急释放空间,需要清理HDFS回收站
2、在删除HDFS文件时,可以使用命令:
hdfs dfs -rm -skipTrash /tmp/repay_prpjpolicypayment,文件就直接被删除,不会进入回收站(永久删除,无法恢复数据)
3、清空回收站命令:
hdfs dfs -expunge (回收站不会立即被清理,而是先Created trash checkpoint: /user/hdfs/.Trash/230309135102。显示的是一分钟后清除。)
按文件时间删除
文件按时间排序
ls -l --time-style=+%s | awk '{print $6,$7,$8,$9}' | sort -r -k1 | awk '{print $2}'
传入xargs删除
hdfs dfs -ls /tmp/datawarehouse/ | sort -r -k6,7 | head - 50 | awk '{print $6}' | xargs hdfs dfs -rm -r
current='2023-12-03'
hdfs dfs -ls /user/jmkx_data/hive_db/jmkx_data.db/
| awk -v current=$current '{if($6 > current ){print $8}}'
| xargs hdfs dfs -rm -r -skipTrash
1.查看hdfs上文件夹下文件的个数
hadoop fs -cat /tmp/mc/'`default`'.db/stg_mh_lpdyrmyy_radinfo_pacsimages_mc_temp_mc_temp/* | gunzip -c | wc -l
2.查看hdfs上文件夹下文件的大小
hadoop fs -count -h /tmp/mc/'`default`'.db/stg_mh_lpdyrmyy_radinfo_pacsimages_mc_temp_mc_temp/
3.查看hdfs文件夹下文件按时间顺序排序
[bque@sdw3 ~]$ hadoop fs -ls /tmp/mc/'`default`'.db/stg_mh_lpdyrmyy_radinfo_pacsimages_mc_temp_mc_temp/ | sort -r -k6,7
-r决定正序逆序
阿里云EMR清理历史HDFS数据
日志文件:
Spark History Server:spark-history-server.log和spark-spark-org.apache.spark.deploy.history.HistoryServer*.out
Spark Thrift Server:spark-thrift-server.log和spark-spark-org.apache.spark.sql.hive.thriftserver.HiveThriftServer2*.out
Spark History Server
出现节点磁盘写满,检查后发现HDFS上的spark-history目录下有大量的数据文章来源:https://www.toymoban.com/news/detail-826060.html
在EMR控制台Spark服务配置页面的spark-defaults.conf页签,修改spark.history.fs.cleaner.enabled的参数值为true,然后重启History Server服务。
您也可以手动清理HDFS服务/spark-history目录下最老的一部分作业数据。文章来源地址https://www.toymoban.com/news/detail-826060.html
到了这里,关于HDFS元数据管理/磁盘清理维护的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!