Hadoop(02) HDFS


HDFS架构图

HDFS架构图


HDFS特性

(1)HDFS中的文件在物理上是分块存储(block),块的大小可以通过配置参数( dfs.blocksize)来规定,默认大小在hadoop2.x版本中是128M,老版本中是64M

(2)HDFS文件系统会给客户端提供一个统一的抽象目录树,客户端通过路径来访问文件,形如:hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

(3)目录结构及文件分块信息(元数据)的管理由namenode节点承担
            —— namenode是HDFS集群主节点,负责维护整个hdfs文件系统的目录树,以及每一个路径(文件)所对应的block块信息(block的id,及所在的datanode服务器)

(4)文件的各个block的存储管理由datanode节点承担
            —— datanode是HDFS集群从节点,每一个block都可以在多个datanode上存储多个副本(副本数量也可以通过参数设置dfs.replication)

(5)HDFS是设计成适应一次写入,多次读出的场景,且不支持文件的修改


HDFS工作机制

  • 概述
    (1) HDFS集群分为两大角色:NameNode、DataNode (Secondary Namenode)
    (2) NameNode负责管理整个文件系统的元数据
    (3) DataNode 负责管理用户的文件数据块
    (4) 文件会按照固定的大小(blocksize)切成若干块后分布式存储在若干台datanode上
    (5) 每一个文件块可以有多个副本,并存放在不同的datanode上
    (6) Datanode会定期向Namenode汇报自身所保存的文件block信息,而namenode则会负责保持文件的副本数量
    (7) HDFS的内部工作机制对客户端保持透明,客户端请求访问HDFS都是通过向namenode申请来进行


  • HDFS写数据流程
           client要向HDFS写数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后,client按顺序将文件逐个block传递给相应datanode,并由接收到block的datanode负责向其他datanode复制block的副本

    • 步骤图
      这里写图片描述

    • 详细步骤
      1、根namenode通信请求上传文件,namenode检查目标文件是否已存在,父目录是否存在
      2、namenode返回是否可以上传
      3、client请求第一个 block该传输到哪些datanode服务器上
      4、namenode返回3个datanode服务器DN1, DN3, DN4
      5、client请求3台dn中的一台DN1上传数据(本质上是一个RPC调用,建立pipeline),DN1收到请求会继续请求DN3,然后请求DN4来建立通道,将整个个pipeline建立完成,逐级返回客户端
      6、client开始往DN1上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,DN1收到一个packet就会传给DN3,DN3传给DN4;DN1每传一个packet会放入一个应答队列等待应答
      7、当一个block传输完成之后,client再次请求namenode上传第二个block的服务器(即:重复以上所有步骤)




  • HDFS读数据流程
           client将要读取的文件路径发送给namenode,namenode获取文件的元信息(主要是block的存放位置信息)返回给client,client根据返回的信息找到相应datanode逐个获取文件的block并在client本地进行数据追加合并从而获得整个文件

  • 步骤图
    read

  • 详细步骤
    1、跟namenode通信查询元数据,找到文件块所在的datanode服务器
    2、挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流
    3、datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验)
    4、客户端以packet为单位接收,现在本地缓存,然后写入目标文件



namenode & secondary namenode

namenode:负责客户端请求的响应;元数据的管理(查询,修改)
secondary namenode:负责合并edits和fsimage文件

  • 元数据管理
    内存元数据(NameSystem)
    磁盘元数据镜像文件
    数据操作日志文件(可通过日志运算出元数据)

  • 元数据存储机制
    A、内存中有一份完整的元数据(内存meta data)
    B、磁盘有一个“准完整”的元数据镜像(fsimage)文件(在namenode的工作目录中)
    C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志(edits文件)

  • 元数据手动查看
    bin/hdfs oev -i edits -o edits.xml
    bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml

  • 元数据的checkpoint
    每隔一段时间(默认30min),会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint)

  • checkpoint步骤图
    checkpoint

    checkpoint的附带作用
           namenode和secondary namenode的工作目录存储结构完全相同,所以,当namenode故障退出需要重新恢复时,可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录,以恢复namenode的元数据

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值