HDFS简介
HDFS(Hadoop Distributed File System),是一个分布式的文件系统,用来分布式存放海量数据,该文件系统可以存在于廉价机器上,具有高容错性。
HDFS工作流程
以上传文件为例
架构图中包含4个组件
- Client
1.与NameNode通信,告知其要做的操作,如上传文件、下载文件、删除文件等;得到NameNode返回的信息,如Block分片信息,Block存放位置等
2.对要上传的文件进行分片
3.与DataNode通信,执行读、写操作
4.执行其他HDFS命令操作 - NameNode
1.从fsimage和Edits文件加载元数据到内存,写HDFS操作日志
2.处理Client请求
3.接收DataNode消息,对数据块进行校验并发出数据块指令让DataNode执行
4.同步元数据文件和操作日志给SecondaryNameNode进行合并,接收合并结果 - SecondaryNameNode
1.接收NameNode发过来的fsimage和Edits进行合并,然后将合并结果发给NameNode
2.在NameNode挂掉后,接管NameNode工作 - DataNode
1.存放真正的文件,每个文件块是链式发送的(Client发送一个文件块给DN1->DN2->DN3)
2.接收与执行Client指令
3.启动和启动后定期向NameNode发送文件块报告
4.接收并执行NameNode的指令
优点
- 海量数据处理,可以存放TB、PB级别数据,或者百万、千万级别文件数
- 高容错,因为文件在分布式文件系统中有多个副本,丢失一个副本不影响功能的提供,而且定期会检查副本数,不足会自动补齐
- 性价比高,可以部署在廉价的机器上
- 一致性,流式访问保证其一致性
缺点
- 不适合处理实时处理
- 不适合大量小文件处理,小文件会增加maptask,导致内存不足而宕机,而且寻址一个小文件时间会超过读取一个小文件时间,违背HDFS设计初衷
- 不能并发写入,一个文件只能有一个进程在同一时刻写
- 不支持文件修改(对文件追加除外)
HDFS要点
SSN机制
从图中可以看出NameNode上新Fsimage文件是由SecondaryNameNode根据从NameNode拿到的Fsimage+Edits文件合并后发送给NameNode,这样一来NameNode和SecondaryNameNode都有了元数据文件,当NameNode挂了之后,可以有SecondaryNameNode接管
此机制不是实时合并,所以在下一次合并前,NameNode宕机的话,根据时间或者业务量决定丢失元数据数量,所以这种方案存在单点故障的问题。不过此机制是Hadoop1.X的,Hadoop2.X使用了联邦
补充内容:
元数据结构图
NameNode是通过两个文件来存储元数据信息的,分别是: Fsimage->是存储和管理元数据的 Edits->HDFS的操作都会记录到此文件中
Fsimage文件和Edits文件存储的目录是放在hdfs-site.xml:dfs.name.dir/core-site.xml:hadoop.tmp.dir 对应的目录下,前者配置优于后者.。如果此两个属性没有配置,默认是在 Linux的 /tmp,因为这两个文件的重要性,建议一定要配置。
每次启动HDFS都会合并Fsimage和Edits文件,以保证元数据是最新的,也可以通过hadoop dfsadmin -rollEdits命令手动合并
合并周期默认是3600s(1小时)
文件切块
HDFS 中的文件在物理上是分块存储(block),块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在 hadoop2.x 版本中是 128M,老版本中是 64M。HDFS 的块比磁盘的块大,其目的是为了最小化寻址开销。如果块设置得足够大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。因而传输一个由多个块组成的文件的时间取决于磁盘传输速率。
做一个计算题:
如果寻址时间约为 10ms,而传输速率为 100MB/s(目前磁盘传输速率为100MB/S),为了使寻址时间仅占传输时间的 1%,将块大小设置约为 100MB,估计就是这个原因Hadoop默认块大小从64M改成了128M
正因为这个原因,所以HDFS不适合处理小文件。
回收站
默认回收站是关闭的,可以在core-site.xml中启用回收站
<property>
<name>fs.trash.interval</name>
<value>1440</value>
<description>Number of minutes between trash checkpoints. If zero, the trash feature is disabled.
</description>
</property>
value的时间单位是分钟,如果配置成0,表示不开启HDFS的回收站
1140=24*60,表示删除的文件只在回收站保存一天
如果要想从回收站恢复删除的文件可以执行如下命令
1.先查看文件所在目录
hadoop fs -lsr /user/root/.Trashan>
2.执行mv操作
hadoop fs -mv source/filename destination
其他
1.hadoop namenode -format命令只有初次安装hadoop的时候使用,用来生成fsimage和Edits文件。该命令风险性很高,如果是在正常运行的集群,执行该命令就完蛋了,所以要严格控制此命令的执行,比如在hdfs-site.xm中配置dfs.namenode.support.allow.format为false,是该命令失效
2.HDFS在启动时,每台DataNode都会向NameNode汇报自己文件块的信息,NameNode要做文件块数据的校验,检验文件块的内容是否完整,以及文件块的副本数量是否达到要求。如果检验有问题,HDFS会进入安全模,在此模式下做文件块的修复,修复完成后安全模式自动退出。安全模式下只能够读取文件。
进入安全模式:hadoop dfsadmin -safemode enter
退出安全模式:hadoop dfsadmin -safemode leave
3.伪分布式搭建,hdfs-site.xml里的副本数量配置=1,如果大于1,而又没有真正的DataNode存放更多副本,HDSF会一直处于安全模式
HADOOP2.X架构
HDFS主要包含两层
Namespace
- 由目录、文件和块组成。
- 它支持所有与Namespace相关的文件系统操作,如创建、删除、修改和列出文件和目录。
Block Storage Service(块存储服务)
分为两部分:
- Block Management(块管理)(在Namenode中执行)
通过注册和周期性心跳提供DataNode集群资格
处理block的报告并维护block的位置支持block相关操作,如创建、删除、修改和获取块位置
管理副本位置,管理副本的复制和删除 - Storage (存储)
Datanodes提供将文件存储在本地文件系统上,并提供读/写操作
在Hadoop1.x中HDFS架构只允许整个集群的一个Namespace,单个Namenode管理Namespace。HDFS Federation通过向HDFS添加多个Namenodes/Namespace的支持来解决这一限制。
为了水平扩展name service,Federation使用多个独立的Namenodes/Namespaces。 Namenodes他们是联合的,而不是捆绑在一起,彼此之间不需要协作,独立存在。
所有NameNode共用Datanodes,因此每个Datanode都注册到集群中的所有NameNode,并定期发送心跳和文件块报告给NameNode
Block pool 是属于单个Namespace的一组块,Datanodes存储群集中所有块池的块。每个块池都是独立管理的,因此允许Namespace为新块生成块ID,而无需与其他Namespace进行协调。一个Namenode挂了,集群中的Datanodes继续为其他Namenode提供服务
Namespace及其Block pool一起被称为Namespace Volume,它是一个独立的管理单元。当一个NameNode/Namespace被删除时,其BLock pool 中的块会从Datanodes删除。
在集群升级过程中,每个命名空间卷均作为一个单元进行升级
完全分布式写流程