博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【hadoop】关于HDFS的四大机制与两大核心
阅读量:3942 次
发布时间:2019-05-24

本文共 3321 字,大约阅读时间需要 11 分钟。

文章目录

hdfs 是hadoop 生态系统的一部分,为大数据的处理提供了分布式的存储环境。

hdfs的四大机制和两大核心:

hdfs 提供的是高容错性的分布式的数据存储方案,

四大机制

hadoop集群启动的时候各个进程启动的顺序

namenode:
datanode
secondarynamenode

心跳机制

集群节点之间必须做时间同步

  • namenode负责集群上任务的分工,如果要进行分工,则必须直到各个从节点的存活状况,namenode通过datanode定期向namenode发送的心跳报告得知的,datanode默认每隔3秒发送一次心跳报告

namenode什么时候才会判定datanode死了

  • datanode每隔3秒向namenode发送一次心跳报告,当namenode连续十次没有收到datanode的心跳报告,则认为datanode可能死了,这时namenode主动向datanode发送一个检查,发送一次检查的时间默认是5min,namenode 给自己两次机会,如果一次检查没有返回信息,这时namenode 会再次进行检查,如果两次检查都没有返回信息,则会判定当前的datanode已经死了,也就是说namenode最终判断datanode死了需要2 * 5min + 3s*10 = 630s

通过配置可以改变这个时间

安全模式

集群启动的时候namenode做了什么

  • 元数据
    1、抽象目录树
    2、数据和块的映射关系
    3、数据块存储的位置信息
  • 元数据存储的位置
    1、磁盘(如果元数据存在磁盘,每次进行文件读写的时候,都会进行磁盘IO,必然会导致性能比较低,集群启动后元数据应该不在磁盘)磁盘存储的元数据只有(1、2)
    2、内存(读写快,但是一旦关机,就会造成数据丢失,所以元数据即在内存存储,又在磁盘存储)内存存储的元数据包含3部分,(1、2、3)

当集群在第一次启动的时候,首先会将磁盘上的元数据加载到内存中,如果磁盘的元数据过大,会造成加载到内存中的时间过长,所以磁盘中的元数据只存了(1、2)两部分namenode元数据的数据块存储的位置是通过datanode的心跳报获取的,namenode在启动的时候,会接datanode的心跳报告,心跳报告中还包含数据块的存储位置信息。

在集群启动的时候

  1. namenode将元数据加载到内存中
  2. namenode接收datanode的心跳报告(获取datanode的存储状况,获取块的存储信心)当接收到99%的心跳状态退出安全模式
  3. 启动secondarynamenode
    在启动的过程中,不允许外界对集群进行操作,这个时候集群处于安全模式,主要是为了加载元数据和获取datanode的心跳报告

如果集群处于维护或者是升级,也可以手动将集群设置安全模式

hdfs dfsadmin -safemode enter (进入安全模式)hdfs dfsadmin -safemode leave (离开安全模式)hdfs dfsadmin -safemode get(获取安全模式的状态)

安全模式下用户可以做的哪些事情(不能修改元数据的操作都可以)

hadoop fs -ls hadoop fs -cathadoop fs -get(下载)

安全模式下不可以做的事情(修改元数据的操作)

hadoop fs -mkdir(创建目录)hadoop fs -put(上传)修改文件名

机架策略

副本存放机制(默认情况下,每个数据块有3个副本)

三个副本的存放情况:

  • 第一份副本存放在客户端所在的节点上
  • 第二个副本存储在和第一个副本不同的机架商的任意一个节点上(防止整个机架断电,数据访问不到)
  • 第三个副本存储在与第一个副本相同的机架上的不同的节点上(在风险度相同的情况下,优先选择网络传输少的)

真实情况下需要手动配置机架策略

自定以机架策略需要考虑:

  1. 不同节点
  2. 不同机架
  3. 不同数据中心

负载均衡

什么式负载均衡,每个节点上存储的数据百分比相差不大,

假设有三个节点

5t -->2.5t   50%2t -->1t     50%8t -->4t     50%

在进行文件上传的时候,会优先选择客户端所在的节点,如果习惯性使用同一个客户端,会造成客户端所在的节点存储的数据比较多

集群会有一个自动的负载均衡的操作,这个负载均衡的速度比较慢(默认是1M的带宽,在集群空闲的情况下),可以通过配置文件修改

对于小规模(集群的节点比较少的时候)是可以的,集群规模特别大的时候自动进行负载花费的时间太长,这时需要手动进行负载均衡

手动进行负载均衡的命令:

stop-balance.shstart-balance.sh 命令不会立即执行,会等到集群空闲的时候,不存绝对的负载均衡,start-balance.sh -t 10% 指任意两个几点之间的存储百分比不超过10% 认为达到了负载均衡

两大核心

上传

1、hadoop fs -put 客户端向namenode 发送数据上传的请求(包含数据的长度信息)

2、namenode 进行一系列的检查

  1. 检查文件是否已经上传
  2. 检查父目录是否存在
  3. 检查权限

3、namenode 检查通过,会向客户端返回节点信息,(返回的原则,就近原则,优先返回客户端所在的节点,返回同机架的节点,再返回不同机架的节点)

4、客户端接收namenode的节点返回的响应后,会进行逻辑切块,

切块:物理切块和逻辑切分

  • 物理切分:真实的切分
  • 逻辑切分:只是概念的切分,并没有进行物理的切分

5、开始准备文件上传

6、构建文件上传的通道pipline 根据块id依次进行构建,将同一个块的所有节点构建成一个数据流通道

例如:客户端-》01-》-》02-》03 响应过程相反

7、开始真正的上传,上传过程(边上传边切分),上传的过程以package为单位进行上传(512k)

先上传到datanode01中的过程中,先写到缓存中,然后缓存中每接收到一个package就可以向下一个节点传递,缓存中的数据还会持续向磁盘中写

8、当第一个块的数据上传完成,则通道完毕

9、开始上传第二块, 重复6、7、8

10、所有的块上传完成之后,会向客户端返回结果,通知客户端数据上传成功

11、客户端向namenode 返回信息,告知namenode上传成功

12、namenode 更新元数据

文件上传的过程中出现异常:

如果上传的过程中有一个节点上传失败,hdfs会立即进行一次重试,如果还失败,会将失败的节点从pipline 中剔除,并将失败的节点告知namenode,hdfs最终可以忍受的极限是,至少有一个节点上传成功,如果三个节点都失败,会向namenode重新申请三个节点,最终上传的过程中保证至少一份就可以,其他的副本是在集群上传成功后进行异步复制得来的,在数据上传的时候,一般会返回一个客户端所在的节点,因为客户端所在的节点不存在网络传输,上传失败的可能性小,这个时候可以保证数据至少上传一个节点

下载

1、客户端向namenode发送下载请求,

2、namenode在元数据中进行查询,如果查询到则会返回给客户端数据的块及副本存储节点

blk_1  hadoop01  hadoop02 hadoop04		blk_2  hadoop01  hadoop03 hadoop05

3、客户端拿到了客户端的存储节点,就会进行第一个数据块的下载客户端进行数据下载的时候也是进行就近原则进行下载

4、第一个块下载完成之后,会生成一个crc文件,和上传时候的.meta文件进行文件完整度的校验,(校验起始偏移量和结束偏移量之间的内容)校验通过则认为第一个块下载成功

5、进行第二个块的下载,动作重复3、4

6、所有的数据块下载成功之后,向namenode发送数据下载成功响应

文件下载的过程中产生异常:数据块的某一个节点读取不到数据,这个时候会namenode节点汇报,namenode会对这个节点进行标记,(这个节点可能是问题节点)接着读取这个块存储的其他节点

转载地址:http://eanwi.baihongyu.com/

你可能感兴趣的文章
[Spring AOP] 基于AspectJ的@AfterReturning注释示例(附参考书目)
查看>>
The Big Bang Theory歌词
查看>>
Eclipse自动注释模版
查看>>
《非诚勿扰2》台词
查看>>
《班扎古鲁白玛的沉默》仓央嘉措
查看>>
《十诫诗》仓央嘉措
查看>>
《那一世》仓央嘉措
查看>>
《我问佛》仓央嘉措
查看>>
Maven中指定得AspectJ依赖无法添加得解决方案
查看>>
Spring3注释装配的最佳实践
查看>>
Mac Vi常用键
查看>>
jchardet字符编码自动检测工具
查看>>
使用Maven Archetype生成工程报错的解决
查看>>
System.getProperty()系统参数
查看>>
Linux系统下批量删除.svn目录
查看>>
大数据行业应用趋势
查看>>
Mac + Rails3 + MongoDB的Demo工程搭建
查看>>
隐藏于Python内的设计之禅彩蛋
查看>>
VSCode配置C/C++环境
查看>>
OTB测试之Visual Tracker Benchmark v1.0全过程配置流程
查看>>