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就是用来备份编辑日志和镜像文件的