Hadoop-HDFS总结（四）

HDFS工作机制

HDFS的数据流

文件写入
1）客户端向namenode请求上传文件，namenode检查目标文件是否已存在，父目录是否存在。

2）namenode返回是否可以上传。

3）客户端请求第一个 block上传到哪几个datanode服务器上。

4）namenode返回3个datanode节点，分别为dn1、dn2、dn3。

5）客户端请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成

6）dn1、dn2、dn3逐级应答客户端

7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答

8）当一个block传输完成之后，客户端再次请求namenode上传第二个block的服务器。（重复执行3-7步）
1.客户端通过调用DistributedFileSystem的create方法创建新文件。

2.DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前， namenode会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过， namenode就会记录下新文件，否则就会抛出IO异常。

3.前两步结束后，会返回FSDataOutputStream的对象，与读文件的时候相似， FSDataOutputStream被封装成DFSOutputStream。DFSOutputStream可以协调namenode和 datanode。客户端开始写数据到DFSOutputStream，DFSOutputStream会把数据切成一个个小的packet，然后排成队 列data quene（数据队列）。

4.DataStreamer会去处理接受data quene，它先询问namenode这个新的block最适合存储的在哪几个datanode里（比如重复数是3，那么就找到3个最适合的 datanode），把他们排成一个pipeline。DataStreamer把packet按队列输出到管道的第一个datanode中，第一个 datanode又把packet输出到第二个datanode中，以此类推。

5.DFSOutputStream还有一个对列叫ack quene，也是由packet组成，等待datanode的收到响应，当pipeline中的所有datanode都表示已经收到的时候，这时ack quene才会把对应的packet包移除掉。

如果在写的过程中某个datanode发生错误，会采取以下几步： 
1)pipeline被关闭掉； 
2)为了防止防止丢包ack quene里的packet会同步到data quene里； 
3)把产生错误的datanode上当前在写但未完成的block删掉； 
4)block剩下的部分被写到剩下的两个正常的datanode中； 
5)namenode找到另外的datanode去创建这个块的复制。当然，这些操作对客户端来说是无感知的。

6.客户端完成写数据后调用close方法关闭写入流。

7.DataStreamer把剩余得包都刷到pipeline里，然后等待ack信息，收到最后一个ack后，通知datanode把文件标视为已完成。

注意：客户端执行write操作后，写完的block才是可见的(注:和下面的一致性所对应)，正在写的block对客户端		是不可见的，只有 调用sync方法，客户端才确保该文件的写操作已经全部完成，当客户端调用close方法时，会		默认调用sync方法。是否需要手动调用取决你根据程序需 要在数据健壮性和吞吐率之间的权衡
#### 网络拓扑

在本地网络中，两个节点被称为“彼此近邻”是什么意思？在海量数据处理中，其主要限制因素是节点之间数据的传输速率——带宽很稀缺。这里的想法是将两个节点间的带宽作为距离的衡量标准。

​ 节点距离：两个节点到达最近的共同祖先的距离总和。

例如，假设有数据中心d1机架r1中的节点n1。该节点可以表示为/d1/r1/n1。利用这种标记，这里给出四种距离描述。

Distance(/d1/r1/n1, /d1/r1/n1)=0（同一节点上的进程）

Distance(/d1/r1/n1, /d1/r1/n2)=2（同一机架上的不同节点）

Distance(/d1/r1/n1, /d1/r3/n2)=4（同一数据中心不同机架上的节点）

Distance(/d1/r1/n1, /d2/r4/n2)=6（不同数据中心的节点）

机架感知

• 官方ip地址：

http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/RackAwareness.html

http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#Data_Replication

• 低版本Hadoop副本节点选择

第一个副本在client所处的节点上。如果客户端在集群外，随机选一个。

第二个副本和第一个副本位于不相同机架的随机节点上。

第三个副本和第二个副本位于相同机架，节点随机。

• 高副本节点选择

  ​第一个副本在client所处的节点上。如果客户端在集群外，随机选一个。

  ​第二个副本和第一个副本位于相同机架，随机节点。

  ​第三个副本位于不同机架，随机节点。

2. HDFS读流程

1）客户端向namenode请求下载文件，namenode通过查询元数据，找到文件块所在的datanode地址。
2）挑选一台datanode（就近原则，然后随机）服务器，请求读取数据。
3）datanode开始传输数据给客户端（从磁盘里面读取数据放入流，以packet为单位来做校验）。
4）客户端以packet为单位接收，先在本地缓存，然后写入目标文件。
1.首先调用FileSystem对象的open方法，其实是一个DistributedFileSystem的实例。

2.DistributedFileSystem通过rpc获得文件的第一批block的locations，同一个block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面。

3.前两步会返回一个FSDataInputStream对象，该对象会被封装DFSInputStream对象，DFSInputStream可 以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream最会找出离客户端最近的datanode 并连接。

4.数据从datanode源源不断的流向客户端。

5.如果第一块的数据读完了，就会关闭指向第一块的datanode连接，接着读取下一块。这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流。

6.如果第一批block都读完了， DFSInputStream就会去namenode拿下一批block的locations，然后继续读，如果所有的块都读完，这时就会关闭掉所有的流。

7.如果在读数据的时候， DFSInputStream和datanode的通讯发生异常，就会尝试正在读的block的排序第二近的datanode,并且会记录哪个 datanode发生错误，剩余的blocks读的时候就会直接跳过该datanode
DFSInputStream也会检查block数据校验和，如果发现一个坏的block,就会先报告到namenode节点，然后 DFSInputStream在其他的datanode上读该block的镜像。

8.该设计就是客户端直接连接datanode来检索数据并且namenode来负责为每一个block提供最优的datanode， namenode仅仅处理block location的请求，这些信息都加载在namenode的内存中，hdfs通过datanode集群可以承受大量客户端的并发访问。

3. 一致性模型

debug调试如下代码

package HDFS_01;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;

import java.net.URI;

public class HDFS01 {
    
    
    public static void main(String[] args) throws Exception {
    
    
        //1. 创建配置信息对象
        Configuration conf = new Configuration();
        //2.获取文件系统
        FileSystem fs = FileSystem.get(new URI("hdfs://linux1:9000"), conf, "root");
        //3.创建文件输入流

        FSDataOutputStream fos = fs.create(new Path("/data/A.txt"));

        //3.写入数据
        fos.write("aaaaaa".getBytes());
        //4.一致性刷新
       // fos.hflush();
        //fos.hsync();
        //5关流
        fos.close();
    }
}

总结

​ 写入数据时，如果希望数据被其他client立即可见，调用如下方法

​ FSDataOutputStream. hflush (); //清理客户端缓冲区数据，被其他client立即可见

NameNode工作机制

1. NameNode和Secondary NameNode工作机制- 第一阶段：namenode启动

• 第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志(edits)和镜像文件(fsimage)到内存
• 客户端对元数据进行增删改的请求
• namenode记录操作日志，更新滚动日志
• namenode在内存中对数据进行增删改查
• 第二阶段：Secondary NameNode工作
  • Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
  • Secondary NameNode请求执行checkpoint。
  • namenode滚动正在写的edits日志
  • 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
  • Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
  • 生成新的镜像文件fsimage.chkpoint
  • 拷贝fsimage.chkpoint到namenode
  • namenode将fsimage.chkpoint重新命名成fsimage
• chkpoint检查时间参数设置
  • 通常情况下，SecondaryNameNode每隔一小时执行一次。

#[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>

2. 镜像文件和编辑日志文件

• 概念

• namenode被格式化之后，将在/opt/module/hadoop-2.8.4/data/dfs/name/current目录中产生如下文件,注只能在NameNode所在的节点才能找到此文件

可以执行find . -name edits* 来查找文件

edits_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION

（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。

（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。

（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字

（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

oiv查看fsimage文件

• 基本语法

- hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
-p	–processor <arg>   指定转换类型: binary (二进制格式), xml (默认，XML格式),stats
-i	–inputFile <arg>     输入edits文件，如果是xml后缀，表示XML格式，其他表示二进制
-o 	–outputFile <arg> 输出文件，如果存在，则会覆盖

案例实操

[itstar@bigdata111 current]$ hdfs oev -p XML -i edits_0000000000000000135-0000000000000000135 -o /opt/module/hadoop-2.8.4/edits.xml -p stats

[itstar@bigdata111 current]$ cat /opt/module/hadoop-2.8.4/edits.xml

每个RECORD记录了一次操作，比如图中的

OP_ADD代表添加文件操作、OP_MKDIR代表创建目录操作。里面还记录了

文件路径（PATH）

修改时间（MTIME）

添加时间（ATIME）

客户端名称（CLIENT_NAME）

客户端地址（CLIENT_MACHINE）

权限（PERMISSION_STATUS）等非常有用的信息

3. 滚动编辑日志

​ 正常情况HDFS文件系统有更新操作时，就会滚动编辑日志。也可以用命令强制滚动编辑日志。

• 滚动编辑日志（前提必须启动集群）

[dingshiqi@bigdata111 current]$ hdfs dfsadmin -rollEdits

举例：原文件名edits_inprogress_0000000000000000321

执行以下命令后

[root@bigdata111 current]# hdfs dfsadmin -rollEdits

Successfully rolled edit logs.

New segment starts at txid 323

edits_inprogress_0000000000000000321 => edits_inprogress_0000000000000000323

• 镜像文件什么时候产生

  NameNode启动时加载镜像文件和编辑日志

4. NameNode版本号

• 查看namenode版本号

在/opt/module/hadoop-2.8.4/data/dfs/name/current这个目录下查看VERSION

namespaceID=1778616660

clusterID=CID-bc165781-d10a-46b2-9b6f-3beb1d988fe0

cTime=1552918200296

storageType=NAME_NODE

blockpoolID=BP-274621862-192.168.1.111-1552918200296

layoutVersion=-63

namenode版本号具体解释

1） namespaceID在HDFS上，会有多个Namenode，所以不同Namenode的namespaceID是不同的，分别管理一组blockpoolID。

（2）clusterID集群id，全局唯一

（3）cTime属性标记了namenode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

（4）storageType属性说明该存储目录包含的是namenode的数据结构。

（5）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。

（6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

（7）storageID (存储ID)：是DataNode的ID,不唯一

5. SecondaryNameNode目录结构

​ Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。

在/opt/module/hadoop-2.8.4/data/dfs/namesecondary/current这个目录中查看SecondaryNameNode目录结构。

edits_0000000000000000001-0000000000000000002
fsimage_0000000000000000002
fsimage_0000000000000000002.md5
VERSION

SecondaryNameNode的namesecondary/current目录和主namenode的current目录的布局相同。

好处：在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。

方法一：将SecondaryNameNode中数据拷贝到namenode存储数据的目录；

方法二：使用-importCheckpoint选项启动namenode守护进程，从而将SecondaryNameNode中数据拷贝到namenode目录中。

• 案例实操（一）

  模拟namenode故障，并采用方法一，恢复namenode数据

（1）kill -9 namenode进程

（2）删除namenode存储的数据（/opt/module/hadoop-2.8.4/data/dfs/name）
	rm -rf /opt/module/hadoop-2.8.4/data/dfs/name/*
		
		注：此时hadoop-daemon.sh stop namenode关闭NN,
		然后hadoop-daemon.sh start namenode重启NN,发现50070页面启动不了

（3）拷贝SecondaryNameNode中数据到原namenode存储数据目录
	cp -r /opt/module/hadoop-2.8.4/data/dfs/namesecondary/* 
	  /opt/module/hadoop-2.8.4/data/dfs/name/

（4）重新启动namenode
	sbin/hadoop-daemon.sh start namenode

案例实操（二）

模拟namenode故障，并采用方法二，恢复namenode数据

• 修改hdfs-site.xml中的配置，value的单位是秒，默认3600，即1小时，仅配置一台即可

 <property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>120</value>
</property>

<property>
  <name>dfs.namenode.name.dir</name>
  <value>/opt/module/hadoop-2.8.4/data/dfs/name</value>
</property>

• kill -9 namenode进程

• 删除namenode存储的数据（/opt/module/hadoop-2.8.4/data/dfs/name）

  rm -rf /opt/module/hadoop-2.8.4/data/dfs/name/*

• 如果SecondaryNameNode不和Namenode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到Namenode存储数据的平级目录。

[dingshiqi@bigdata111 dfs]$ pwd
/opt/module/hadoop-2.8.4/data/dfs
[dingshiqi@bigdata111 dfs]$ ls
data  name  namesecondary

导入检查点数据（等待一会ctrl+c结束掉）

bin/hdfs namenode -importCheckpoint

启动namenode

sbin/hadoop-daemon.sh start namenode

如果提示文件锁了，可以删除in_use.lock

rm -rf /opt/module/hadoop-2.8.4/data/dfs/namesecondary/in_use.lock

6. 集群安全模式操作

• 概述

  Namenode启动时，首先将映像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。此时，namenode开始监听datanode请求。但是此刻，namenode运行在安全模式，即namenode的文件系统对于客户端来说是只读的。

  系统中的数据块的位置并不是由namenode维护的，而是以块列表的形式存储在datanode中。在系统的正常操作期间，namenode会在内存中保留所有块位置的映射信息。在安全模式下，各个datanode会向namenode发送最新的块列表信息，namenode了解到足够多的块位置信息之后，即可高效运行文件系统。

  如果满足“最小副本条件”，namenode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以namenode不会进入安全模式。

• 基本语法

  集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。

1）bin/hdfs dfsadmin -safemode get		（功能描述：查看安全模式状态）
（2）bin/hdfs dfsadmin -safemode enter  	（功能描述：进入安全模式状态）
（3）bin/hdfs dfsadmin -safemode leave	（功能描述：离开安全模式状态）
（4）bin/hdfs dfsadmin -safemode wait		（功能描述：等待安全模式状态）

案例 模拟等待安全模式

• 先进入安全模式

bin/hdfs dfsadmin -safemode enter

执行下面的脚本

编辑一个脚本(注：必须已设置环境变量，要不就写绝对路径)

#!bin/bash
hdfs dfsadmin -safemode wait
hadoop fs -put /opt/BBB /

再打开一个窗口，执行

bin/hdfs dfsadmin -safemode leave

• 编辑一个脚本(注：必须已设置环境变量，要不就写绝对路径)

7. NameNode多目录配置

• namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。
• 具体配置如下

#hdfs-site.xml

<property>
    <name>dfs.namenode.name.dir</name>
<value>file:///${
    
    hadoop.tmp.dir}/dfs/name1,file:///${
    
    hadoop.tmp.dir}/dfs/name2</value>
</property>
#1.停止集群 删除data 和 logs  rm -rf data/* logs/*
#2.hdfs namenode -format
#3.start-dfs.sh
#4.去展示
#https://blog.csdn.net/qq_39657909/article/details/85553525

实验总结：
思考1：如果在非Namenode节点、进行格式化(hdfs namenode -format)
是否和在NN节点上同样会生成name1和name2目录呢？

答：只要配置了以上得配置，在该节点下同样会生成name1和name2

• 具体解释：
  格式化做了哪些事情？

  在NameNode节点上，有两个最重要的路径，分别被用来存储元数据信息和操作日志，而这两个路径来自

  于配置文件，它们对应的属性分别是dfs.name.dir和dfs.name.edits.dir，同时，它们默认的路径均是/tmp/hadoop/dfs/name。格式化时，NameNode会清空两个目录下的所有文件，之后，格式化会在目录dfs.name.dir下创建文件

  hadoop.tmp.dir 这个配置，会让dfs.name.dir和dfs.name.edits.dir会让两个目录的文件生成在一个目录里

  思考2：非NN上如果生成了name1和name2，那么他和NN上生成得有没有差别？

  **答：**有区别、NN节点上会产生新得edits_XXX，非NN不会fsimage会更新，而非NN不会，只会产生一个仅初始化得到得fsimage，不会生成edits,更不会发生日志滚动。