一、HDFS原理
(1)HDFS概述
- HDFS集群分为两大角色:NameNode、DataNode
- NameNode负责管理整个文件系统的元数据
- DataNode 负责管理用户的文件数据块
- 文件会按照固定的大小(blocksize)切成若干块后分布式存储在若干台datanode上
- 每一个文件块可以有多个副本,并存放在不同的datanode上
- Datanode会定期向Namenode汇报自身所保存的文件block信息,而namenode则会负责保持文件的副本数量
- HDFS的内部工作机制对客户端保持透明,客户端请求访问HDFS都是通过向namenode申请来进行
(2)HDFS写流程
- 概述
客户端要向HDFS写数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后,客户端按顺序将文件逐个block传递给相应datanode,并由接收到block的datanode负责向其他datanode复制block的副本 - 步骤图
-
详细步骤
1、根namenode通信请求上传文件,namenode检查目标文件是否已存在,父目录是否存在
2、namenode返回是否可以上传
3、client请求第一个 block该传输到哪些datanode服务器上
4、namenode返回3个datanode服务器ABC
5、client请求3台dn中的一台A上传数据(本质上是一个RPC调用,建立pipeline),A收到请求会继续调用B,然后B调用C,将整个pipeline建立完成,逐级返回客户端
6、client开始往A上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,A收到一个packet就会传给B,B传给C;A每传一个packet会放入一个应答队列等待应答
7、当一个block传输完成之后,client再次请求namenode上传第二个block的服务器。 -
问题
1、传输blk1的过程中,dn3如果挂了,怎么处理???不做任何处理。如果dn3又重新启动了,怎么处理??? 在块报告时,namenode发出删除垃圾块指令 2、客户端建立连接时,dn3连不上怎么办??? 向namenode重新要3个节点 3、传输过程中,如果packet传输出错,怎么处理??? 包重新传输,最多重新传输4次 4、如果blk1、blk2上传成功了,但是blk3上传失败了,怎么处理???上传blk3的时候,dn1挂了,怎么处理??? 整个文件被标记为无效,下次datanode上报块报告时,检查出那些节点上存在该文件的块,通知这些datanode删除块。 5、上传blk3的过程中,如果客户端挂了怎么处理??? 超时机制
(3)HDFS读流程
-
概述
客户端将要读取的文件路径发送给namenode,namenode获取文件的元信息(主要是block的存放位置信息)返回给客户端,客户端根据返回的信息找到相应datanode逐个获取文件的block并在客户端本地进行数据追加合并从而获得整个文件 -
步骤图
-
详细步骤
1、 跟namenode通信查询元数据,找到文件块所在的datanode服务器
2、挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流
3、datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验)
4、客户端以packet为单位接收,先在本地缓存,然后写入目标文件
二、NAMENODE
(1)NAMENODE职责
- 负责客户端请求的响应
- 元数据的管理(查询,修改)
- 管理datanode的状态
(2)元数据管理的3种形态
namenode对数据的管理采用了三种存储形式:
- 内存元数据(NameSystem)
- 磁盘元数据镜像文件fsimage
- 数据操作日志文件(可通过日志运算出元数据)edits
(3)namenode的启动过程
namedode进程启动后
- 加载fsimage()
- 加载edits,namenade进入安全模式
- 等待datanode启动并报告块的信息
- datanode启动并发送块报告
- namenode统计块的信息,检查配置项,当超过0.999时,等待15秒,退出安全模式
- 保存fsimage
A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像(fsimage)文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件)注:当客户端对hdfs中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据会更新到内存meta.data中
namenode不适合存储大量小文件
(4)元数据手动查看
可以通过hdfs的一个工具来查看edits中的信息
hdfs oev -i edits -o edits.xml
hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml
(5)问题
1、如果集群的namenode宕机。hdfs的服务还能正常对外提供???
不能
2、如果namenode节点的磁盘损坏,元数据是否还能恢复???
snn也包括fsimage,但这个文件不一定是最新的数据,如何还原最新的数据???
namenode有备份节点
三、secondarynamenode
辅助namenode来进行日志的合并——checkpoint
(1)checkpoint过程
每隔一段时间,会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint)
- snn检查是否可以丛checkpoint,并通知namenode
- namenode立即回滚edits
- namenode上传镜像、日志到snn
- 内存合并元数据,先加载fsimage,后执行edits
- 将内存中的数据溢写到磁盘
- 将磁盘文件上传给namenode
- namenode校验合并后的数据
- 将checkpoint文件改名
四、datanode
(1)Datanode工作职责
- 存储管理用户的文件块数据
- 定期向namenode汇报自身所持有的block信息(通过心跳信息上报)
(这点很重要,因为,当集群中发生某些block副本失效时,集群如何恢复block初始副本数量的问题)
<property>
<name>dfs.blockreport.intervalMsec</name>
<value>3600000</value>
<description>Determines block reporting interval in milliseconds.</description>
</property>
(2)Datanode掉线判断时限参数
datanode进程死亡或者网络故障造成datanode无法与namenode通信,namenode不会立即把该节点判定为死亡,要经过一段时间,这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout,则超时时长的计算公式为:
timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。
而默认的heartbeat.recheck.interval 大小为5分钟,dfs.heartbeat.interval默认为3秒。
需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒,dfs.heartbeat.interval的单位为秒。所以,举个例子,如果heartbeat.recheck.interval设置为5000(毫秒),dfs.heartbeat.interval设置为3(秒,默认),则总的超时时间为40秒。
<property>
<name>heartbeat.recheck.interval</name>
<value>2000</value> ## 单位毫秒
</property>
<property>
<name>dfs.heartbeat.interval</name>
<value>1</value> ##单位 秒
</property>
(3)块大小
块严格按照blocksize的大小来对文件进行物理上的切分
单个文件大小2G左右,经过测试能达到集群的最优性能。
五、总结
-
hdfs 的特点
高扩展性、搞容错性、移动计算而不是移动数据
不适合小文件、不适合低延迟的需求 -
hafs的安装步骤
---- 先决条件:(1)创建一个普通用户 (2)安装JDK (3)关闭防护墙 (4)配置静态ip (5)设置hostname (6)配置hosts映射关系 (7)ssh免密
---- 安装步骤:
(1)解压安装包 (2)配置环境变量 (3)配置hadoop的运行环境hadoop-env.sh (4)配置hadoop的核心配置core-site.xml (5)配置hadoop的核心配置hdfs-site.xml (6)配置yarn的核心配置yarn-site.xml (7)配置MapReduce的核心配置mapred-site.xml (8)配置从机slaves
---- 分发安装包
---- namenodr的初始化——实际是生成一个空的fsimage文件
若需要重新初始化,则需要删除所有节点上的dfs目录
---- 批量启动:start-dfs.sh start-yarn.sh start-all.sh start-yarn.sh在启动resourcemanager时一定第启动本机 start-dfs.sh所有的角色都是通过ssh方式启动的
---- 单节点启动:
hadoop-daemon.sh start | stop namenode | datanode | secondarynamenode..... hadoop-daemons.sh start | stop namenode | datanode | secondarynamenode... yarn-daemon.sh start | stop | nodemanager yarn-daemons.sh start | stop | nodemanager
---- hadoop的端口号
8020/9000:对客户端暴露的端口号 50070/50090:web ui的监控端口 50010:datanode对客户端暴露的端口 803X:yarn相关的端口号 8088:web ui的监控端口 100020/19888:jobhistoryserver相关的端口号
---- hdfs shell命令
hdfs dfs - hadoop fs - hadoop dfsadmin - fsck:磁盘操作 oev:浏览edits文件 oiv:浏览fsimage文件 hdfs
---- 读写流程:原理(重点)
---- 工作机制(重点)namenode的职责 hdfs的启动过程 namenode的工作机制 secondarynamenode的工作职责和
---- fsimage和edits文件
fsimage保留了最新的2个版本 edits保留了最近的100万次操作
问题:hdfs和集群是否可以分开?
可以,启动的时候分别在namemode和resourcemanager上执行start- 命令