HDFS分布式文件系统

头像
chain_xx_wdm
    阅读 5 分钟

    HDFS简介

    HDFS是Hadoop核心组成, 是分布式存储服务

    HDFS是分布式文件系统中的一种

    HDFS的重要概念

    HDFS通过统一的命名空间目录树来定位文件
另外, 它是分布式的, 由很多服务器联合起来实现其功能. 集群中的服务器有各自的角色(分布式本质是拆分, 各司其职)
    • 典型的Master/Slave架构
      HDFS的架构是典型的Master/Slave结构
      HDFS集群往往是一个NameNode+多个DataNode组成
      NameNode是集群的主节点, DataNode是集群的从节点
    • 分块存储(block机制)
      HDFS中的文件在物理是分块存储(block)的, 块的大小可以通过配置参数来指定
      Hadoop2.x版本中默认的block大小是128M
    • 命名空间(NameSpace)
      HDFS支持传统的层次型文件组织结构.
      用户或者应用程序可以创建目录, 然后将文件保存在这些目录里.
      文件系统命名空间的层次结构和大多数现有的文件系统类似: 用户可以创建, 删除, 移动或重命名文件

      NameNode负责维护文件系统的命名空间, 任何对文件系统命名空间或属性的修改都将被NameNode记录下来

    • NameNode元数据管理
      我们把目录结构及文件分块位置叫做元数据
      NameNode的元数据记录每一个文件所对应的block信息(block的id, 以及所在的DataNode节点)
    • DataNode数据存储
      文件的各个block的具体存储管理由DataNode节点来承担
      一个block会有多个DataNode来存储, DataNode会定时向NameNode来汇报自己持有的block信息
    • 副本机制
      为了容错, 文件的所有block都会有副本
      每个文件的block大小和副本系数都是可配置的
      应用程序可以指定某个文件的副本数目
      副本系数可以在文件创建的时候指定, 也可以在之后改变
      副本数量默认是3个
    • 一次写入, 多次读出
      HDFS设计成适应一次写入, 多次读出的场景, 且不支持文件的随机修改 . (支持追加写入, 不支持随机更新)
      正因为如此, HDFS适合用来做大数据分析的底层存储, 并不适合用来做网盘等应用 (修改不方便, 延迟大, 网络开销大, 成本太高)

    HDFS架构

    image.png

    • NameNode: HDFS集群的管理者, Master

      • 维护管理HDFS的命名空间(NameSpace)
      • 维护副本策略
      • 记录文件块(Block)的映射信息
      • 负责处理客户端读写请求

    • DataNode: NameNode下达命令, DataNode执行实际操作, Slave

      • 保存实际的数据块
      • 负责数据块的读写

    • Client: 客户端

      • 上传文件到HDFS的时候, Client负责将文件切分成Block, 然后进行上传
      • 请求NameNode交互, 获取文件的位置信息
      • 读取或写入文件, 与DataNode交互
      • Client可以使用一些命令来管理HDFS或访问HDFS

    image.png

    HDFS读写解析

    HDFS读数据流程

    image.png

    • 客户端通过Distributed FileSystem向NameNode请求下载文件, NameNode通过查询元数据找到文件块所在的DataNode地址
    • 挑选一台DataNode(就近原则, 然后随机)服务器, 请求读取数据
    • DataNode开始传输数据给客户端 (从磁盘里面读取数据输入流, 以Packet为单位来做校验)
    • 客户端以Packet为单位接收, 先在本地缓存, 然后写入目标文件

    HDFS写数据流程

    image.png

    • 客户端通过Distributed FileSystem模块向NameNode请求上传文件, NameNode检查目标文件是否已存在, 父目录是否存在
    • NameNode返回是否可以上传
    • 客户端请求第一个Block上传到哪几个DataNode服务器上
    • NameNode返回3个DataNode节点, 分别是dn1, dn2, dn3
    • 客户端通过FSDataOutputStream模块请求dn1上传数据, dn1收到请求会继续调用dn2, 然后dn2调用dn3, 将这个通信管道建立完成
    • dn1, dn2, dn3逐级应答客户端
    • 客户端开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存), 以Packet为单位, dn1收到一个Packet就会传给dn2, dn2传给dn3; dn1每传一个packet会放入一个确认队列等待确认
    • 当一个Block传输完成之后, 客户端再次请求NameNode上传第二个Block的服务器 (重复执行3-7步)

    NN与2NN

    HDFS元数据管理机制

    • 问题1: NameNode如何管理和存储元数据?
      计算机中存储数据有两种方式: 内存或者磁盘
      元数据存储磁盘: 存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应, 但是安全性高
      元数据存储内存: 元数据存放内存, 可以高效的查询以及快速响应客户端的查询请求, 数据保存在内存, 如果断点, 内存中的数据全部丢失
      解决方案: 内存+磁盘; NameNode存在内存, FsImage文件存在磁盘
    • 问题2: 磁盘和内存中元数据如何划分?
      两个数据一模一样? 还是两个数据合并到一起才是一份完整的数据呢?
      若一模一样: client如果对元数据进行增删改操作, 需要保证两个数据的一致性. FsImage文件操作起来效率也不高
      若两个合并=完整数据: NameNode引入了一个edits文件(日志文件: 只能追加写入). edits文件记录的是client的增删改操作, 不再选择让NameNode把数据dump出来形成FsImage文件(这种操作是比较消耗资源)

    元数据管理流程如下:
    image.png

    • 第一阶段: NameNode启动

      • 第一次启动NameNode格式化后, 创建FsImage和Edits文件. 如果不是第一次启动, 直接加载编辑日志和镜像文件到内存
      • 客户端对元数据进行增删改的请求
      • NameNode记录操作日志, 更新滚动日志
      • NameNode在内存中对数据进行增删改

    • 第二阶段: SecondaryNameNode工作

      • SecondaryNameNode询问NameNode是否需要CheckPoint. 直接带回NameNode是否执行检查点操作结果
      • SecondaryNameNode请求执行CheckPoint
      • NameNode滚动正在写的Edits日志
      • 将滚动前的编辑日志和镜像文件拷贝到SecondaryNameNode
      • SecondaryNameNode加载编辑日志和镜像文件到内存, 并合并
      • 生成新的镜像文件fsimage.chkpoint
      • 拷贝fsimage.chkpoint到NameNode
      • NameNode将fsimage.chkpoint重新命名成fsimage

    Fsimage与Edits文件解析

    NameNode在执行格式化之后, 会在 /opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current目录下产生如下文件
    image.png

    • FsImage文件: 是NameNode中关于元数据的镜像, 一般称为检查点. 这里包含了HDFS文件系统所有目录以及文件相关信息(Block数量, 副本数量, 权限等信息)
    • Edits文件: 存储了客户端对HDFS文件系统所有的更新操作记录. Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中(不包括查询操作)
    • seen_txid: 该文件是保存了一个数字, 数字对应着最后一个Edits文件名的数字
    • VERSION: 该文件记录namenode的一些版本号信息. 比如:CusterId, namespaceID等

    NameNode启动时会将FsImage文件加载到内存中, 同时也把之前未合并元数据的Edits文件加载, 集合两个文件中的元数据这样保证了NameNode中的元数据是最新最全的

    通俗点说, 就是NameNode启动时把FsImage和Edits文件进行了合并

    checkpoint周期

    修改的文件是 hdfs-default.xml

    <!-- 定时一小时 -->
<property>
    <name>dfs.namenode.checkpoint.period</name>
    <value>3600</value>
</property>

<!-- 一分钟检查一次操作次数, 当操作次数达到1百万时, SecondaryNameNode执行一次 -->
<property>
    <name>dfs.namenode.checkpoint.txns</name>
    <value>1000000</value>
    <description>操作动作次数</description>
</property>

<property>
    <name>dfs.namenode.checkpoint.check.period</name>
    <value>60</value>
    <description>1分钟检查一次操作次数</description>
</property>

    NN故障处理

    NameNode故障后, HDFS集群就无法正常工作, 因为HDFS文件系统的元数据需要由NameNode来管理维护并与Client交互

    如果元数据出现损坏和丢失, 同样会导致NameNode无法正常工作进而HDFS文件系统无法正常对外提供服务

    如果元数据出现丢失损坏如何恢复?

    1. 将2NN的元数据拷贝到NN的节点下 ---> 该方式会存在元数据的丢失
    2. 搭建HDFS的HA(高可用)集群, 解决NN的单点故障问题 ---> 借助Zookeeper实现HA, 一个Active的NameNode, 一个Standby的NameNode)

    Hadoop的限额与归档以及集群安全模式

    HDFS文件限额配置

    HDFS文件的限额配置允许我们以文件大小或文件个数来限制我们在某个目录下上传的文件数量或者文件内容总量, 以便达到我们类似百度网盘等限制每个用户允许上传的最大的文件的量

    HDFS的安全模式

    安全模式是HDFS所处的一种特殊状态. 在这种状态下 , 文件系统只接受读数据请求, 而不接受删除/修改等变更请求

    在NameNode主节点启动时, HDFS首先进入安全模式, DataNode在启动的时候会向NameNode汇报可用的block等状态. 当整个系统达到安全标准时, HDFS自动离开安全模式

    如果HDFS处于安全模式下, 则文件block不能进行

    Hadoop归档技术

    hdfs
    chain_xx_wdm
    64 声望2 粉丝

    1.领养代替买卖

    « 上一篇
    Apache Hadoop的重要组成
    下一篇 »
    [解决]ssh: connect to host xxx port 22: Network is unreachable

    引用和评论

    推荐阅读
    头像
    [解决]ssh: connect to host xxx port 22: Network is unreachable

    chain_xx_wdm赞 1阅读 16.9k

    0 条评论
    得票最新