HDFS架构图
HDFS特性
(1)HDFS中的文件在物理上是分块存储(block),块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在hadoop2.x版本中是128M,老版本中是64M
(2)HDFS文件系统会给客户端提供一个统一的抽象目录树,客户端通过路径来访问文件,形如:hdfs://namenode:port/dir-a/dir-b/dir-c/file.data
(3)目录结构及文件分块信息(元数据)的管理由namenode节点承担
—— namenode是HDFS集群主节点,负责维护整个hdfs文件系统的目录树,以及每一个路径(文件)所对应的block块信息(block的id,及所在的datanode服务器)
(4)文件的各个block的存储管理由datanode节点承担
—— datanode是HDFS集群从节点,每一个block都可以在多个datanode上存储多个副本(副本数量也可以通过参数设置dfs.replication)
(5)HDFS是设计成适应一次写入,多次读出的场景,且不支持文件的修改
HDFS工作机制
- 概述
(1) HDFS集群分为两大角色:NameNode、DataNode (Secondary Namenode)
(2) NameNode负责管理整个文件系统的元数据
(3) DataNode 负责管理用户的文件数据块
(4) 文件会按照固定的大小(blocksize)切成若干块后分布式存储在若干台datanode上
(5) 每一个文件块可以有多个副本,并存放在不同的datanode上
(6) Datanode会定期向Namenode汇报自身所保存的文件block信息,而namenode则会负责保持文件的副本数量
(7) HDFS的内部工作机制对客户端保持透明,客户端请求访问HDFS都是通过向namenode申请来进行
- HDFS写数据流程
client要向HDFS写数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后,client按顺序将文件逐个block传递给相应datanode,并由接收到block的datanode负责向其他datanode复制block的副本
- 步骤图
- 详细步骤
1、根namenode通信请求上传文件,namenode检查目标文件是否已存在,父目录是否存在
2、namenode返回是否可以上传
3、client请求第一个 block该传输到哪些datanode服务器上
4、namenode返回3个datanode服务器DN1, DN3, DN4
5、client请求3台dn中的一台DN1上传数据(本质上是一个RPC调用,建立pipeline),DN1收到请求会继续请求DN3,然后请求DN4来建立通道,将整个个pipeline建立完成,逐级返回客户端
6、client开始往DN1上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,DN1收到一个packet就会传给DN3,DN3传给DN4;DN1每传一个packet会放入一个应答队列等待应答
7、当一个block传输完成之后,client再次请求namenode上传第二个block的服务器(即:重复以上所有步骤)
- HDFS读数据流程
client将要读取的文件路径发送给namenode,namenode获取文件的元信息(主要是block的存放位置信息)返回给client,client根据返回的信息找到相应datanode逐个获取文件的block并在client本地进行数据追加合并从而获得整个文件 - 步骤图
- 详细步骤
1、跟namenode通信查询元数据,找到文件块所在的datanode服务器
2、挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流
3、datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验)
4、客户端以packet为单位接收,现在本地缓存,然后写入目标文件
namenode & secondary namenode
namenode:负责客户端请求的响应;元数据的管理(查询,修改)
secondary namenode:负责合并edits和fsimage文件
- 元数据管理
内存元数据(NameSystem)
磁盘元数据镜像文件
数据操作日志文件(可通过日志运算出元数据) - 元数据存储机制
A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像(fsimage)文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件) - 元数据手动查看
bin/hdfs oev -i edits -o edits.xml
bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml - 元数据的checkpoint
每隔一段时间(默认30min),会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint) - checkpoint步骤图
- checkpoint的附带作用
namenode和secondary namenode的工作目录存储结构完全相同,所以,当namenode故障退出需要重新恢复时,可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录,以恢复namenode的元数据