• HDFS的写流程：

    image.png

    1. 客户端通过Distribute FileSystem模块向NameNode请求上传文件，NameNode检验客户端权限，然后检查目标文件是否已经存在，父目录是否纯在。
    2. NameNode返回是否可以上传文件
    3. 客户端请求上传第一个Block，请求NameNode返回应该上传到哪几个DateNode服务器上。
    4. NameNode根据副本存储规则，返回3个DataNode节点，分别为dn1、dn2、dn3。
    5. 客户端通过FSDataOutputStram模块请求dn1上传数据，dn1接到请求后会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
    6. dn1,dn2,dn3逐级给客户端做出应答。
    7. 客户端收到应答后，开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存)，以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答响应队列。
    8. 当Block传输完成之后，客户端在其请求NameNode上传第二个Block的服务器。重复执行c-h步
    • HDFS节点距离计算
      • 节点距离：两个节点到大最近的共同祖先的距离总和。

    image.png

    • Hadoop3.1.3副本节点选择
      • 第一个副本在Client所处的节点上。如果客户端在集群外，则随机选择一个
      • 第二个副本在另一个机架的随以一个节点
      • 第三个副本在第二个副本所在机架的随机节点
    • HDFS的读流程：
    • NameNode工作机制

    image.png

    • 第一阶段：
      • 服务器启动，加载edits编辑日志和fsimage镜像文件到内存中。
      • 客户端对元数据进行增删改操作，向NameNode提出请求。
      • NameNode先记录操作日志，滚动更新日志，然后再在内存中对元数据进行增删改。

    • 第二阶段：

      • SecondaryNameNode询问NameNode是否需要CheckPoint，CheckPoint的触发条件是：①定时时间到②Edits中的数据满了。直接带回NameNode是否检查结果。
      • 2NN请求执行CheckPoint。
      • NameNode滚动正在写的操作日志，将edits_inprogress_001滚动为edits_inprogree_002，同时，如果此时有新的客户端请求操作，则记录在edits_001中。
      • 将edits_inprogress_002和fsimage文件拷贝到2NN中
      • 2NN加载操作日志和镜像文件到内存中，进行合并(根据初始数据和账本，开始清算)。
      • 合并之后新生成一个fsimage_checkpoint文件，可以理解为执行操作日志中的操作时候得到的镜像文件。
      • 将合并后的fsimage_checkpoint拷贝到NameNode中。
      • 将NameNode中的fsimage_checkpoint重命名为fsimage。

    • Fsimage和Edits解析、

      • Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件inode序列化信息。
      • Edits文件：存放HDFS文件系统中所有变更操作的路径，文件系统客户端执行的所有写操作首先会被记录到Edits文件中。
      • seentxid文件保存的是一个数字，就是最后一个edits的数字。
      • 正常情况是无法通过cat查看fsimage进行文件的
      • 查看oiv和oev命令
        • 基本语法：hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
        • hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径

      • CheckPoint时间设置

        • 通常情况下，checkpoint每隔1小时执行一次，edits操作次数为1百万次。

        • 修改：[hdfs-default.xml]

          image.png

      • 2NN怎么知道Edits中的操作是否到了1百万次呢？

        • 每隔60查看一次NN中edits_inprogress中文件数有没有1百万次

    image.png