目录
HDFS 的工作机制
概述
HDFS 写数据流程
HDFS 读数据流程
NameNode 的工作机制
NameNode 的职责
元数据的管理
DataNode 的工作机制
概述
观察验证 DataNode 功能
HDFS 的工作机制
工作机制的学习主要是为加深对分布式系统的理解, 以及增强遇到各种问题时的分析解决能力, 形成一定的集群运维能力.
很多不是真正理解 hadoop 技术体系的人会常常觉得 HDFS 可用于网盘类应用, 但实际并非如此. 要想将技术准确用在恰当的地方, 必须对技术有深刻的理解.
概述
1.HDFS 集群分为两大角色: NameNode,DataNode
2.NameNode 负责管理整个文件系统的元数据(元数据就是文件数据块放置在 DataNode 位置和数量等信息)
3.DataNode 负责管理用户的文件数据块
4. 文件会按照固定的大小 (blocksize) 切成若干块后分布式存储在若干台 datanode 上
5. 每一个文件块可以有多个副本, 并存放在不同的 datanode 上
6.Datanode 会定期向 Namenode 汇报自身所保存的文件 block 信息, 而 namenode 则会负责保持文件的副本数量
7.HDFS 的内部工作机制对客户端保持透明, 客户端请求访问 HDFS 都是通过向 namenode 申请来进行
HDFS 写数据流程
概述
客户端要向 HDFS 写数据, 首先要跟 Namenode 通信以确认可以写文件并获得接收文件 block 的 Datanode, 然后, 客户端按顺序将文件逐个 block 传递给相应 Datanode, 并由接收到 block 的 Datanode 负责向其他 Datanode 复制 block 的副本
HDFS 写数据流程图
写数据步骤详解
1,Client 向 Namenode 通信请求上传文件, Namenode 检查目标文件是否已存在, 父目录是否存在
2,Namenode 返回是否可以上传
3,Client 请求第一个 block 该传输到哪些 Datanode 服务器上
4,Namenode 返回 3 个 Datanode 服务器 ABC
5,Client 请求 3 台 DataNode 中的一台 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 的服务器.
HDFS 读数据流程
概述
客户端将要读取的文件路径发送给 namenode,namenode 获取文件的元信息 (主要是 block 的存放位置信息) 返回给客户端, 客户端根据返回的信息找到相应 datanode 逐个获取文件的 block 并在客户端本地进行数据追加合并从而获得整个文件
HDFS 读数据流程图
读数据步骤详解
1, 跟 namenode 通信查询元数据, 找到文件块所在的 datanode 服务器
2, 挑选一台 datanode(就近原则, 然后随机)服务器, 请求建立 socket 流
3,datanode 开始发送数据(从磁盘里面读取数据放入流, 以 packet 为单位来做校验)
4, 客户端以 packet 为单位接收, 现在本地缓存, 然后写入目标文件
NAMENODE 工作机制
NAMENODE 职责
负责客户端请求的响应
元数据的管理(查询, 修改)
元数据管理
namenode 对数据的管理采用了三种存储形式:
内存元数据(NameSystem)
磁盘元数据镜像文件
数据操作日志文件(可通过日志运算出元数据)
元数据存储机制
A, 内存中有一份完整的元数据(内存 meta data)
B, 磁盘有一个 "准完整" 的元数据镜像 (fsimage) 文件(在 namenode 的工作目录中)
C, 用于衔接内存 metadata 和持久化元数据镜像 fsimage 之间的操作日志(edits 文件)
注: 当客户端对 hdfs 中的文件进行新增或者修改操作, 操作记录首先被记入 edits 日志文件中, 当客户端操作成功后, 相应的元数据会更新到内存 meta.data 中
元数据手动查看
可以通过 hdfs 的一个工具来查看 edits 中的信息
- bin/hdfs oev -i edits -o edits.xml
- bin/hdfs oiv -i fsimage_0000000000000000087 -p xml -o fsimage.xml
元数据的 checkpoint
每隔一段时间, 会由 secondary namenode 将 namenode 上积累的所有 edits 和一个最新的 fsimage 下载到本地, 并加载到内存进行 merge(这个过程称为 checkpoint)
checkpoint 的详细过程
checkpoint 流程图
checkpoint 操作的触发条件配置参数
- dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率, 60 秒
- dfs.namenode.checkpoint.dir=file://${
- hadoop.tmp.dir
- }/dfs/namesecondary
- dfs.namenode.checkpoint.edits.dir=${
- dfs.namenode.checkpoint.dir
- } #以上两个参数做 checkpoint 操作时, secondary namenode 的本地工作目录
- dfs.namenode.checkpoint.max-retries=3 #最大重试次数
- dfs.namenode.checkpoint.period=3600 #两次 checkpoint 之间的时间间隔 3600 秒
- dfs.namenode.checkpoint.txns=1000000 #两次 checkpoint 之间最大的操作记录
checkpoint 的附带作用
namenode 和 secondary namenode 的工作目录存储结构完全相同, 所以, 当 namenode 故障退出需要重新恢复时, 可以从 secondary namenode 的工作目录中将 fsimage 拷贝到 namenode 的工作目录, 以恢复 namenode 的元数据
DATANODE 的工作机制
概述
Datanode 工作职责:
1, 存储管理用户的文件块数据
2, 定期向 namenode 汇报自身所持有的 block 信息(通过心跳信息上报)(这点很重要, 因为, 当集群中发生某些 block 副本失效时, 集群如何恢复 block 初始副本数量的问题)
- <property>
- <name>dfs.blockreport.intervalMsec</name>
- <value>3600000</value>
- <description>Determines block reporting interval in milliseconds.
- </description>
- </property>
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>
观察验证 DATANODE 功能
上传一个文件, 观察文件的 block 具体的物理存放情况:
在每一台 datanode 机器上的这个目录中能找到文件的切块:
/home/hadoop/App/hadoop-2.7.3/tmp/dfs/data/current/BP-193442119-192.168.88.3-1432458743457/current/finalized
来源: http://www.bubuko.com/infodetail-3034504.html