7.hdfs工作流程及机制
1. hdfs基本工作流程
1. hdfs初始化目录结构
hdfs namenode -format 只是初始化了namenode的工作目录
而datanode的工作目录是在datanode启动后自己初始化的
namenode在format初始化的时候会形成两个标识:
blockPoolId:
clusterId:
新的datanode加入时,会获取这两个标识作为自己工作目录中的标识
一旦namenode重新format后,namenode的身份标识已变,而datanode如果依然
持有原来的id,就不会被namenode识别
2. hdfs的工作机制
- hdfs集群分为两大角色:NameNode,DataNode (Secondary NameNode)
- NameNode负责管理整个文件的元数据(命名空间信息,块信息) 相当于Master
- DataNode负责管理用户的文件数据块 相当于Salve
- 文件会按照固定的大小(block=128M)切成若干块后分布式存储在若干个datanode节点上
- 每一个文件块有多个副本(默认是三个),存在不同的datanode上
- DataNode会定期向NameNode汇报自身所保存的文件block信息,而namenode则会负责保持文件副本数量
- hdfs的内部工作机制会对客户的保持透明,客户端请求方法hdfs都是通过向namenode申请来进行访问
- SecondaryNameNode有两个作用,一是镜像备份,二是日志与镜像的定期合并
3. hdfs写入数据流程
1.客户端要向hdfs写入数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后,客户端按照顺序将文件block逐个传给相应datanode,并由接收到block的datanode负责向其他datanode复制block副本
4. 写入数据步骤详细解析
- 客户端向namenode通信,请求上传文件,namenode检查目标文件是否已经存在,父目录是否存在
- namenode返回给客户端,告知是否可以上传
- 客户端请求第一个block该传输到那些datanode服务器上
- namenode返回3个datanode服务器abc
- 客户端请求3台datanode的一台a上传数据(本质上是一个rpc调用,建立pipeline),A收到请求后会继续调用b,然后b调用c,将整个pipeline建立完成,逐级返回客户端。
- 客户端开始忘a上传第一个block(先从磁盘读取数据放入本地内存缓存),以packet为单位,a收到一个packet将会传给b,b传给c,a每传一个packet会放入一个应答队列等待应答
- 宕一个block传输完之后,客户端再次请求namenode上传第二个block的服务器
5. hdfs读取数据流程
- 客户端将要读取的文件路径发送给namenode
- namenode获取文件的元信息(主要是block的存放位置信息)返回给客户端
- 客户端根据返回的信息找到相应的datanode逐个获取文件的block
- 客户端本地进行数据的追加合并从而获得整个文件
6. 读取数据详细步骤解析
- 客户端跟namenode通信查询元数据,找到文件块所在的datanode服务器
- 挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流
- datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位做校验)
- 客户端以packet为单位接收,先在本地缓存,然后写入目标文件。
2. namenode工作机制
1. namenode常见问题
- 集群启动后,可以查看文件,但是上传文件报错,打开web页面看到namenode正在处于sofemode状态,怎么处理?
- namenode服务器磁盘故障导致namenode宕机,如何解决?
- namenode是否可以有多个?
- namenode内存要配置多大?
- namenode跟集群数据存储能力有关系吗?
- 文件的blocksize究竟调大好,还是调小好?
2. namenode的工作职责
- 负责客户端的请求及相应
- 元数据的管理(查询,修改)
3. 元数据管理
- namenode对数据的管理采用三种存储形式
- 内存元数据(NameSystem)
- 磁盘元数据镜像文件
- 数据操作日志文件(可通过日志运算出元数据)类似于mysql的binlog
4. 元数据存储机制
- 内存中有一份完整的元数据(内存 metadata)
- 磁盘有一个 “准完整” 的元数据镜像(fsimage)文件(在namenode工作目录中)
- 用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits log文件)
- 当客户端对hdfs中的文件进行新增或者修改操作,操作记录首先被记入edits日志文件中,当客户端操作成功后,相应的元数据会更新到内存metadata中
5. 元数据查看
- hdfs oev -i edits_0000000000000000162-0000000000000000163 -o edits.xml
- hdfs oiv -i fsimage_0000000000000000262 -p XML -o fsimage.xml
6. 元数据的checkpoint
- 每隔一段时间,secondary namenode 将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程为checkpoint)
- 详细过程
7. 解决namenode的灾难性错误的方法
首先在hdfs-site.xml配置
<property><name>dfs.name.dir</name><value>/data/hadoop/name1,/data/hadoop/name2</value></property>
- 停止集群
重新格式化
hadoop namenode -format
开始集群
8. checkpoint操作的触发条件配置参数
#dfs.namenode.checkpoint.check.period=60 #检查触发条件是否满足的频率,60秒
#hdfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
#以上两个参数做checkpoint操作时,secondary namenode的本地工作目录
#dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}
#dfs.namenode.checkpoint.max-retries=3 #最大重试次数
#dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的时间间隔3600秒
#dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录
9. checkpoint的附带作用
- namenode和secondary namenode的工作目录存储结构完全相同,所以当namenode故障退出需要重新恢复时,可以从secondary namenode 的工作目录将fsimage拷贝到namenode的工作目录。以恢复namenode的元数据
10. 元数据目录说明
当第一次部署好hadoop集群的时候,在namenode上格式化硬盘后会在${dfs.namenode.name.dir}/current目录产生如下文件结构:
#ls /tmp/hadoop-root/dfs/name/current ---VERSION ---edits_* ---fsimage_* ---seen_txid
dfs.namenode.name.dir在hdfs-site.xml文件中配置
<property><name>dfs.namenode.name.dir</name><value>file://${hadoop.tmp.dir}/dfs/name</value> </property>
注:dfs.namenode.name.dir的属性可以配置多个目录,每个目录存在的文件结构和内容都是一样的,相当于备份,好处是其中有一个目录损坏了,也不会影响到hadoop的元数据。
hadoop.tmp.dir在core-site.xml文件中配置
<property><name>hadoop.tmp.dir</name><value>/tmp/hadoop-${user.name}</value><description>A base for other temporary directories.</description> </property>
VERSION文件是java属性文件
[root@hadoop-1 current]# cat VERSION #Thu Jun 22 11:42:19 EDT 2017 namespaceID=1169207959 clusterID=CID-ce01b250-9850-4da5-b81f-ab24905fbdd7 cTime=0 storageType=NAME_NODE blockpoolID=BP-1786918471-172.16.1.207-1498146139482 layoutVersion=-63
namespace
文件系统的唯一标识符,在文件系统首次格式化后生成的
StorageType
说明这个文件存储的是什么进程的数据结构信息(如果是DataNode,storageType=DATA_NODE);
cTime
NameNode存储时间的创建时间,由于我的NameNode没有更新过,所以这里的记录值为0,如果NameNode升级后,cTime将会记录更新时间戳
layoutVersion
HDFS永久性数据结构的版本信息,只要数据结构变更,版本号也要递减,此时的hdfs也需要升级,否则磁盘仍旧是使用旧版本的数据结构,这会导致新版本的NameNode无法使用。
clusterID
系统生成或者手动指定的集群id,在-clusterid选项中可以使用它
1. $HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>] 选择一个唯一的cluster_id,并且这个cluster_id不能与环境中其他集群有冲突。如果没 有提供cluster_id,则会自动生成一个唯一的ClusterID。 2. 使用如下命令格式化其他Namenode:$HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id> 3. 升级集群至最新版本。在升级过程中需要提供一个ClusterID,例如: $HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR -upgrade -clusterId <cluster_ID> 如果没有提供ClusterID,则会自动生成一个ClusterID。
blockpoolID
针对每一个NameSpace所对应的blockpool的ID,上面的这个
BP-1786918471-172.16.1.207-1498146139482 就是我在ns1的namespace下的存储块池的ID,这个id包括了对应的namenode节点服务器ip地址
seen_teid文件
存放transactionid的文件,format之后是0,它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候,会按照seen_txid的数字,循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候,一定要比对seen_txid内的数字是不是你edits最后的尾数,不然会发生建置namenode时metaData的资料有缺少,导致误删Datanode上多余Block.
文件中记录的是edits滚动的序号,每次重启namenode时,namenode就知道要将哪些edits进行加载editscurrent目录下在format的同时也好生成fsimage和edits文件及其对应的md5校验文件,
3. DataNode的工作机制
Datanode工作职责:
存储管理用户的文件块数据
定期向namenode汇报自身所持有的block信息(通过心跳信息上报)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.interva的单位为秒,所以,举个例子,如果heartbeat.recheck.interval设置为5000(毫秒),dfs.heartbeat.interval设置为3(秒,默认),则总的超时时间为40秒。
转载于:https://www.cnblogs.com/liu-yao/p/7078217.html
7.hdfs工作流程及机制相关推荐
- Redis——Redis主从复制(工作流程详解)
Redis主从复制 主从复制简介 主从复制的概念 主从复制的作用 主从复制工作流程 阶段一:建立连接阶段 主从连接(slave连接master) 第一种方式 第二种方式 第三种方式 授权访问 阶段二: ...
- 我们来研究一下Eureka的工作流程机制及相关原理
作者:代码忘烦恼 blog.csdn.net/qwe86314/article/details/94552801 Eureka 工作原理 我们来学习 Eureka,了解它的相关概念.工作流程机制等. ...
- kafka工作流程及文件存储机制
1.kafka工作流程 如图topicA有3个分区,每个分区有两个副本(包含一个leader,一个follower),发送消息可以一个一个的发送,也可以批量发送,0,1,2这种是offset偏移量,每 ...
- Eureka工作原理(Eureka简介Eureka ServerEureka Client自我保护机制分布式系统中的CAP理论Eureka 工作流程)
一.Eureka简介 Eureka Server(注册中心,相当于zookeeper) Eureka Client: Provider Consumer 多个Eureka就叫集群.集群之间会定时通过r ...
- 工作流程管理系统,表结构与运行机制
驰骋工作流引擎,工作流程管理系统,表结构与运行机制. 前言: 1, ccflow 有自动修复数据表功能, 所以表的字段的变化不需要用户干预由ccflow自动完成. 所以如果你看到sql的错误,在执行一 ...
- SpringCloud进阶-Hystrix的熔断机制+Hystrix的工作流程
提示:本文主要对SpringCloud中的Hystrix的熔断机制和工作流程进行总结 文章目录 前言 一.简介 1.熔断是什么 二.实操 1.实现 2.测试 三.总结 1.大神结论 2.熔断类型 3. ...
- 2021年大数据Hadoop(十四):HDFS的高可用机制
全网最详细的Hadoop文章系列,强烈建议收藏加关注! 后面更新文章都会列出历史文章目录,帮助大家回顾知识重点. 目录 本系列历史文章 前言 HDFS的高可用机制 HDFS高可用介绍 组件介绍 Nam ...
- Yarn框架和工作流程研究
一.概述 将公司集群升级到Yarn已经有一段时间,自己也对Yarn也研究了一段时间,现在开始记录一下自己在研究Yarn过程中的一些笔记.这篇blog主要主要从大体上说说Yarn的基本架构以及其 ...
- Yarn框架和工作流程简介
大数据现在越来越火,各种计算框架不断出现,比如内存计算框架(Spark).流式计算框架(Storm).迭代式计算框架(iMapReduce)等新型计算框架的出现,经典MR计算框架(MRv1)的局限性日 ...
最新文章
- php 比较数组中的元素,php – 比较多维数组中的元素
- boost::hana::scan_right用法的测试程序
- 使用混合多云每个人都应避免的3个陷阱(第4部分)
- linux exit 流程,Shell exit流程控制语句及用法
- Zephry_GPIO的中断使用详解以及中断原理
- UVA 1615 Highway 高速公路 (区间选点)
- python类和对象详解_python面向对象编程:类和对象详解介绍 – Python高级开发教程...
- atitit.groovy 语法特性
- 投票php实验结果分析与总结,实验的结果分析怎么写
- 送书福利|少儿编程能够一玩就会吗?够胆量的家长,让孩子打卡30天玩会编程!...
- 基于单片机的数字温度计设计
- 常见登录密码加密方式
- 理解分布式一致性:Paxos协议之Multi-Paxos
- JAVA面向对象学习心得
- postgreSQl请求方式
- AMD芯片支持oracle数据库,ORACLE宣布支援AMD OPTERON处理器
- 爬取5K分辨率超清唯美壁纸
- 【ES实战】ES分词器介绍
- 卡图星小机器人怎么过_《瑞奇与叮当》黄金螺丝收集 黄金螺丝收集图文攻略...
- python nltk 10 分析句子的意思