一. HDFS写数据流程
1) 客户端创建一个分布式文件系统(Distributed File System)模块向NameNode发送上传文件的请求, NameNode检查目标文件是否存在, 客户端请求的父目录是否存在
2) NameNode返回是否可以上传文件的消息
3) 客户端向NameNode发送上传第一个块的请求, 同时要求返回上传的DataNode位置
4) NameNode返回可以上传的3个节点
5) 客户端通过FSDataOutputStream模块向DataNode1发送建立传输通道的请求, DataNode1收到后会继续向DaTaNode2发送建立传输通道请求, 其次是DataNode2向DataNode3做同样的动作, 最终完成通信管道(pipe)的建立
6) DataNode1, 2, 3逐级应答客户端
7) 客户端开始向DataNode1传输第一个Block. 此时, 也会在客户端本地保存一个内存缓存, 以防止传输过程中发生错误文件丢失. 向DataNode1传输文件时, 不会以Block而是以包(Packet)为单位进行传输(即512字节的chunk加上4字节的校验码). 当DataNode1收到一个包后, 就会将此包向下传输给DataNode2, 依此类推.
8) 当一个块传输完成后, 客户端再次向NameNode发起请求上传第二个块的DataNode位置(即重复执行3 - 7步)
二. 副本储存节点选择策略(机架感知)
节点距离: 两个节点到达最近的共同祖先的距离总和
> 第一个副本选在客户端所处节点上, 若客户端在集群之外, 则随机选择一个节点
> 第二个副本在另一个机架的随机节点
> 第三个副本在第二个副本所在机架上的其他随机节点
三. HDFS读数据流程
1) 客户端通过Distributed File System模块向NameNode请求下载文件, NameNode通过查询元数据, 找到HDFS上是否有客户端所请求的文件
2) 客户端就近选择一台DataNode, 请求读取第一个块, 如果最近的DataNode服务繁忙, 则随机选择另外一台DataNode
3) DataNode向客户端传输数据(以Packet为单位)
4) 客户端以Packet为单位接收, 先在本地缓存, 然后写入目标文件
四. NameNode和SecondaryNameNode的工作机制
NameNode中, 用于储存元数据的部分称为FsImage(镜像), 其作为备份, 能在元数据丢失时进行备份. 但如果只用FsImage储存元文件信息, 则当内存中的元文件更新是, 如果同时更新FsImage, 则会导致效率过低. 而且一旦NameNode节点断点, 则所有元数据就会丢失.
为此, 引入了Edits文件记录元数据的修改 *** 作. 每当元数据有更新时, 修改的记录便会追加至Edits中, 这样一旦NameNode节点断点, 也可以通过合并FsImage和Edits获得最新的元数据.
然而, 这又引入了另一个新的问题: 如果长时间未进行合并, 会导致Edits文件数据过大, 断点后恢复元数据的效率低. 因此, 引入SecondaryNameNode专门用于定时合并FsImage和Edits.
FsImage和Edits解析
1) FsImage文件是HDFS元数据的永久性检查点, 其中包含HDFS文件系统的所有目录和文件的序列化信息
2) Edits文件用于存放HDFS更新 *** 作, 所有写 *** 作都会首先记录到Edits中
3) seen_txid文件保存的是edits_inprogress(最新的edits文件)的数字
4) VERSION文件中储存了一系列的集群信息, 最主要的是集群的ID. 集群ID是每个集群特有的, 当一个NameNode格式化之后, 集群ID就会发生变化. 只有当每个节点的集群ID一致时, 集群才能够正常通讯.
查看FsImage文件
hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径
> FsImage中 并不会记录每个文件块所对应的DataNode, 这是因为每次集群启动后, DataNode会主动向NemNode上报数据块信息, 并且隔一段时间后会再次上报
查看Edits文件
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
CheckPoint时间设置
SecondaryNameNode的默认合并时间间隔是一个小时. 其时间间隔可在hdfs-default.xml中查看
dfs.namenode.checkpoint.period 3600s
同时, SecondaryNameNode也会每个一分钟检查一次 *** 作次数, 当 *** 作次数达到一百万次时, SecondaryNameNode同样会执行一次合并 *** 作
dfs.namenode.checkpoint.txns 1000000 *** 作动作次数 dfs.namenode.checkpoint.check.period 60s 1分钟检查一次 *** 作次数
五. DataNode工作机制
1) 一个数据块在DataNode上以文件形式储存在磁盘上, 包括两个文件: 一个是数据本身, 另一个是元数据, 包括数据块的长度, 数据块校验码, 以及时间戳. 其中, 校验码采用CRC校验.
2) DataNode启动后, 会先通过校验码检查自身数据的完整性, 然后向NameNode注册, 汇报数据情况. 通过注册后, DataNode会周期性(默认6个小时一次)向NameNode汇报块信息
在hdfs-default.xml中, 同样可查看到汇报信息的时间间隔设置:
dfs.blockreport.intervalMsec 21600000 Determines block reporting interval in milliseconds.
以及自我扫描块信息的间隔时间:
dfs.datanode.directoryscan.interval 21600s Interval in seconds for Datanode to scan data directories and reconcile the difference between blocks in memory and on the disk. Support multiple time unit suffix(case insensitive), as described in dfs.heartbeat.interval.
3) DataNode正常工作时, 会间隔3秒中对NameNode返回一次心跳, 其中带有NameNode给该DataNode的命令. 如果超过十分钟+30秒没有收到某个DataNode的心跳, 则认为该节点不可用.
若定义超时时间为TimeOut, 则超时时长的计算公式为:
TimeOut = 2 * dfs.heartbeat.recheck.interval + 10 * dfs.heartbeat.interval
默认dfs.heartbeat.recheck.interval大小为5分钟, dfs.heartbeat.interval3秒
在hdfs-site.xml中可修改这两个参数的大小. 需要注意的是, 配置文件中, dfs.heartbeat.recheck-interval的单位为毫秒, dfs.heartbeat.interval的单位为秒.
dfs.namenode.heartbeat.recheck-interval 300000 dfs.heartbeat.interval 3
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)