Hadoop学习——hdfs

HDFS的整体架构

在这里插入图片描述

namenode

用于存储元数据
接收读写请求
元数据包括:
1. 抽象目录树
2. 存储数据和block的对应关系
3. block存储的位置

datanode

负责真正的数据存储,存储数据的block
真正处理读写

secondnamenode

冷备份节点:助理 当namenode宕机的时候不能主动切换为namenode
主要作用是:namenode宕机的时候帮助namenode恢复
帮助namenode做一些事情,分担namenode的压力

四大机制

心跳机制

namenode什么时候会判定datanode死亡?
datanode每隔3s向namenode发送一次心跳报告,当namenode连续10次没有收到datanode的心跳报告,namenode会判定datanode可能死亡,但没有完全断定datanode死亡,这个时候namenode会向datanode发送一次检查, 间隔为5min,如果检查一次没有返回信息,这个时候namenode会再进行一次检查,如果还没有获的datanode信息,则判定死亡
也就是说namenode最终判断datanode死亡需要103s+25min = 630s

机架策略

副本存放策略(默认为3)(真实情况下可以自定义)

  1. 第一个副本一般存储在客户端所在的节点上
  2. 第二个副本存储在和第一个副本不同的机架上的任意一个节点上
  3. 第三个副本存储在和第一个副本相同机架上的不同节点上
元数据管理

元数据:抽象目录树 数据和块的映射 数据块的存储节点
元数据中的数据分为4类:

  1. 历史日志文件:编辑完成的日志文件(记录操作信息)
  2. 正在编辑的文件:对元数据修改的操作记录的文件
  3. 镜像文件:真实的元数据信息经过序列化之后的文件 在集群启动的时候会加载这个文件 4. seen_txid :合并点记录文件 记录的是下一次需要合并的文件
  4. 无论什么时候内存中保存的元数据永远是最新的最完整的元数据
元数据合并

如何fsimage不和日志文件进行合并,fsimage和内存元数据差别越来越大
所以fsimage和日志文件需要定期合并
这个合并谁在做?因为namnenode本身的主要职责是保存元数据处理客户端的请求,本身压力大,所以有secondarynamenode负责
元数据合并的过程即为checkpoint的过程
- 触发合并的条件: 3600s
- 元数据条数 100000条
触发任意一个条件都会出发checkpoint过程
secondarynamenode进行checkpoint后自己也会保留一份fsimage文件,原因是给namenode做备份,以防namenode宕机元数据丢失的时候帮助namenode
合并的目的即为保证内存中的元数据与硬盘中的元数据信息一致

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值