HDFS架构设计

1.块 block

	 <property>
	         <name>dfs.blocksize</name>
	         <value>134217728</value>
	 </property>
	 <property>
	         <name>dfs.replication</name>
	         <value>3</value>
	 </property>
	 块的大小为128M
	 副本数为3
	 比如一个文件260M
	实际存储          规格
块A: 128M      128M  A0 A1 A2
块B: 128M      128M  B0 B1 B2
块C: 4M	       128M  C0 C1 C2
	 面试题：一个文件160m,块大小128m，副本数2。请问实际几个块，实际物理存储多少？
	 答：一共两个块，但是副本是2，那么2*2就是4个块，实际物理存储就是160M*2=320M

> 2.HDFS架构设计（重要）：

进程：

namenode 也叫nn					名称节点
datanode 也叫dn					数据节点
ssecondary namenode 也叫snn		第二名称节点

主从架构：

Rack :  机架 可以放多个主机 10个， GPU主机 5个，放多少是根据机柜的电流来计算的，
		 总的电流量除以单个主机的电流量 然后初步估算。

nn：

	 nn是文件系统的命名空间
	 a.文件名称
	 b.文件目录结构
	 c.文件属性 创建时间 权限 副本数
	 d.文件对应哪些数据块
	 --->数据块对应在哪些datanode节点上
	 nn维护的blockmap：
	 nn节点不会持久存储这种映射关系，dn定期发送blockreport 给nn，以此nn在【内存】
	 中动态维护这种映射关系！

	 (生产上 hdfs不适合存储小文件？为什么不合适？如果真的有小文件，该怎么办？该怎么合并)
	 假设 nn 内存空间8G
	 如果全是小文件，那么内存很容易被撑爆了
	 1个小文件：nn节点需要250字节，一亿：1亿*250个字节。
	 
	 假如真的有小文件，那么我们就将小文件合并成一个大文件
	 100个小文件合并成一个大文件：nn节点可能只需要300字节，一亿/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秒发送一次心跳  在datanode上可以看到上一次的通信时间，每3秒刷新一次
b.每10次心跳发送一次当前节点的blockreport
作用：读写文件的数据块

snn：

 存储：fsiamage+editlog
 作用：定期合并fsimage+editlog文件为新的fsimage文件，推送给nn节点，简称为检查点checkpoint
 参数：dfs.namenode.checkpoint.period  3600s 
 由于snn只能备份一小时之前的数据，这一小时的数据不会被备份，所以在生产上一般还会采用其他
方式进行热备份