HDFS架构设计
进程
namenode nn 名称节点
secondary namenode snn 第二名称节点
datanode dn 数据节点
主从架构
Rack : 机架 可以放多个主机 10个 GPU主机 5个
nn: 文件系统的命名空间
a.文件名称
b.文件目录结构
c.文件属性 创建时间 权限 副本数
d.文件对应哪些数据块
-->数据块对应哪些datanode节点上
blockmap
nn节点不会持久化存储这种映射关系
dn定期发送blockreport 给nn,
以此nn在【内存】中动态维护这种映射关系！
假设 nn 8G内存,如果小文件很多会撑爆了内存
(生产上 hdfs不适合存储小文件？为什么不合适？如果真的有小文件，该怎么办？该怎么合并)
1个小文件: nn节点需要250字节
1亿: 1亿*250字节 大
假如真的有小文件 合并
100小文件合并一个大文件 : nn节点需要300字节
1亿/100 * 300字节 小
建议: 合并为一个文件尽量在块大小 120m <=128m
作用:
管理文件系统的命名空间，
维护文件系统树，以两种文件永久保存在磁盘上
命名空间镜像文件 fsimage
编辑日志editlog
[root@hadoop001 current]# pwd
/tmp/hadoop-root/dfs/name/current
[root@hadoop001 current]# ll
total 1040
-rw-r--r--. 1 root root 1048576 Feb 17 20:23 edits_inprogress_0000000000000000001
-rw-r--r--. 1 root root 321 Feb 17 19:23 fsimage_0000000000000000000
-rw-r--r--. 1 root root 62 Feb 17 19:23 fsimage_0000000000000000000.md5
-rw-r--r--. 1 root root 2 Feb 17 19:23 seen_txid
-rw-r--r--. 1 root root 219 Feb 17 19:23 VERSION
[root@hadoop001 current]#
dn:
存储: 数据块 和数据块的校验和
与nn通信:
a.每隔3秒发送一个心跳
hadoop001:50070
b.每10次心跳发送一次当前节点的blockreport
作用: 读写文件的数据块
snn:
存储: fsiamge+editlog
作用: 定期合并fsimage+editlog文件为新的fsimage文件
推送个nn节点，简称为检查点 checkpoint
参数 ：
dfs.namenode.checkpoint.period 3600s
snn对nn每一小时备份一次，如果nn在12点30挂了，文件损坏，那么12点到12点半的数据相当于的数据snn没有备份，用snn恢复只能恢复到12点的数据，所以这种架构是不可靠的，这种架构是在hadoop1.x上的架构，后边有出现了HA，他有两个nn，做了实时的热备，snn相当于做了一个冷备，HA如果一个节点nn挂了，另一个nn瞬间起来，对外提供服务。
editlog： 读写的记录
fsiamge: 读写的记录
所在目录/tmp/hadoop-root/dfs/name/current
secondarynamenode就是用来备份编辑日志和镜像文件的