HDFS笔记1

zhangyujie12138

已于 2022-03-21 00:55:24 修改

阅读量372

点赞数

文章标签： hadoop

于 2022-03-20 19:10:26 首次发布

本文链接：https://blog.csdn.net/zhangyujie12138/article/details/123616048

版权

HDFS笔记1

1.HDFS重要命令

通过hdfs --help查看,主要为以下几个命令
dfsadmin run a DFS admin client
fsck run a DFS filesystem checking utility
dfs run a filesystem command on the file system
namenode run the DFS namenode

dfs这个命令当然不用多说用的比较多了
其次就是namenode命令了
还记得在安装hadoop的时候使用到了

hdf namenode -format

dfadmin

其次是dfsadmin，主要为安全模式有关的一个命令

hdfs dfsadmin -safemode get

用于查看hdfs的安全模式一般来说为
Safe mode is OFF
OFF关闭，读写都是ok
ON开启，读是ok，写不行
安全模式最好是关
如果ON，也就进入了安全模式，有2种情况

被动进入
说明HDFS集群有问题，相当于保护模式
主动进入
主要是做维护，保证这段时间HDFS不会有新数据/新文件写入

fsck

再然后是

hdfs fsck /

用于查看hdfs的最基本情况，结果如下
在这里插入图片描述
可以发现与hadoop 9870端口的内容较像

回收站

然后是有关回收站的知识
配置回收站需要进入位于hadoop/etc/hadoop/目录下的hadoop配置文件core-site.xml

vi core-site.xml

在配置文件内加入

    <property>
        <name>fs.trash.interval</name>
        <value>10080</value>
    </property>

value中10080单位为分钟=7天
当然修改完配置文件后别忘了重启
重启完成后创建测试文件进行测试

hdfs dfs -mkdir -p delete/test1
hdfs dfs -mkdir -p delete/test2

删除文件test1

hdfs dfs -rm -r delete/test1

按下回车后会出现提示：
INFO fs.TrashPolicyDefault: Moved: ‘hdfs://zhangyujie:9000/user/zhangyujie/delete/test1’ to trash at: hdfs://zhangyujie:9000/user/zhangyujie/.Trash/Current/user/zhangyujie/delete/test1
说明被删除的test1文件被移到了.Trash文件夹内了，与windows的回收站类似
可以通过 hdfs dfs -ls查看被删除的文件

hdfs dfs -ls /user/zhangyujie/.Trash/Current/user/zhangyujie/delete/
Found 1 items

还有一种跳过回收站的删除方法

hdfs dfs -rm -r -skipTrash  delete/test2

关键字为-skipTrash
但是鉴于删除操作较为敏感，所以为了防止文件的误删生产上禁用跳过回收站的删除方法
万一删除操作失误，错误输入了rm -rf /并确认还跳过删除就会被迫变成删库跑路

关于很多的配置文件的修改可以去官网上寻找相关信息
hadoop官网

2.HDFS主从架构

NameNode SecondaryNameNode DataNode

2.1 NN 名称节点

存储的内容包括：
1 文件的名称
2 文件的目录结构
3 文件的属性（权限、副本数、创建时间等）
简而言之就是可以用hfds dfs -ls 能够看到的内容
4 一个文件被对应切割哪些数据库（包括副本数的块）==》对应分布在哪些DataNode
管理文件系统的命名空间，其实就是维护文件系统树的文件和文件夹
主要文件：
镜像文件：fsimage
编辑日志文件：edits
文件目录为 /home/zhangyujie/tmp/dfs/name/current

2.2 SNN 第二名称节点

/home/zhangyujie/tmp/dfs/namesecondary /current
主要文件：

edits_inprogress_0000000000000000455
把上一块的镜像文件fsimage_0000000000000000520以及edits_0000000000000000526文件
通过检查点（checkpoint）合并成fsimage_0000000000000000526
edits_inprogress_0000000000000000526为正在记录的
写满了或者到一定时间会将里面的数据放入edits_inprogress_0000000000000000526
然后新建edits_inprogress_000000000000000057
循环往复
写满或到一定时间
dfs.namenode.checkpoint.period 3600 1小时
dfs.namenode.checkpoint.txns 1000000 写满100w
早起为了解决NN是单点的就可能会发生单点故障，增加一个SNN一小时做一个checkpoint
但是现在生产上不用SNN
比如21：00 checkpoint NN和SNN是一样的
21：19 突然NN挂了，且无法恢复
那么这19分钟内做的所有操作都没了
即使拿SNN上的fsimage，也只能恢复到21：00
如果在业务高峰期是很可怕的
现在主要用
HA Highil Available 高可靠
通过配置另一个实时备份NN节点，随时等待active的NN挂掉，然后成为active NN backup NN
写入的时候往两个里面一起写，读的话是从active里面读的

HA 也是不hadoop专属的，其他很多东西都有

2.3 DN 数据节点

存储数据块和数据库的元数据
主要文件：
块一个快默认最大128M
块的元数据
每隔一段时间会发送blockreport（块报告）给到NN
dfs.blockreport.intervalMsec 21600000 单位为毫秒 = 6H
在给NN发送blockreport（块报告）时需要检查自己
dfs.datanode.directoryscan.interval 21600单位为秒 = 6H
这两个的以秒为单位的时间要一致即检查好了再发给NN