HDFS简介

HDFS（全称：Hadoop Distribute File System，Hadoop 分布式文件系统）是 Hadoop 核心组成，是分布式存储服务。
分布式文件系统横跨多台计算机，在大数据时代有着广泛的应用前景，它们为存储和处理超大规模数据提供所需的扩展能力。
HDFS是分布式文件系统中的一种。

HDFS的重要概念

HDFS 通过统一的命名空间目录树来定位文件； 另外，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色（分布式本质是拆分，各司其职）；

  • 典型的 Master/Slave 架构
    HDFS 的架构是典型的 Master/Slave 结构。
    HDFS集群往往是一个NameNode（HA架构会有两个NameNode,联邦机制）+多个DataNode组成；
    NameNode是集群的主节点，DataNode是集群的从节点。
  • 分块存储（block机制）
    HDFS 中的文件在物理上是分块存储（block）的，块的大小可以通过配置参数来规定；
    Hadoop2.x版本中默认的block大小是128M；
  • 命名空间（NameSpace）
    HDFS 支持传统的层次型文件组织结构。用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似：用户可以创建、删除、移动或重命名文件。
    Namenode 负责维护文件系统的名字空间，任何对文件系统名字空间或属性的修改都将被 Namenode 记录下来。
    HDFS提供给客户单一个抽象目录树，访问形式：
    hdfs://namenode的hostname:port/test/input
    hdfs://linux121:9000/test/input
  • NameNode元数据管理
    我们把目录结构及文件分块位置信息叫做元数据。
    NameNode的元数据记录每一个文件所对应的block信息（block的id,以及所在的DataNode节点的信息）
  • DataNode数据存储
    文件的各个 block 的具体存储管理由 DataNode 节点承担。一个block会有多个DataNode来存储，DataNode会定时向NameNode来汇报自己持有的block信息。
  • 副本机制
    为了容错，文件的所有 block 都会有副本。每个文件的 block 大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定，也可以在之后改变。
    副本数量默认是3个。

  • 一次写入，多次读出
    HDFS 是设计成适应一次写入，多次读出的场景，且不支持文件的随机修改。 （支持追加写入，不只支持随机更新）
    正因为如此，HDFS 适合用来做大数据分析的底层存储服务，并不适合用来做网盘等应用（修改不方便，延迟大，网络开销大，成本太高）

    HDFS架构

    image.png

  • NameNode(nn):Hdfs集群的管理者，Master
    维护管理Hdfs的名称空间（NameSpace）
    维护副本策略
    记录文件块（Block）的映射信息
    负责处理客户端读写请求
  • DataNode:NameNode下达命令，DataNode执行实际操作，Slave节点。
    保存实际的数据块
    负责数据块的读写

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

    HDFS客户端操作

    Shell 命令行操作HDFS

  • 基本语法

    bin/hadoop fs 具体命令 OR bin/hdfs dfs 具体命令

  • 命令大全

    hdfs dfs

  • HDFS命令演示
    1）启动Hadoop集群（方便后续的测试）

    start-dfs.sh
start-yarn.sh

    2）-help：输出这个命令参数

    hadoop fs -help rm

    3）-ls: 显示目录信息

    hadoop fs -ls /

    4）-mkdir：在HDFS上创建目录

    hadoop fs -mkdir -p /test/bigdata

    5）-moveFromLocal：从本地剪切粘贴到HDFS

    touch hadoop.txt
hadoop fs -moveFromLocal ./hadoop.txt /test/bigdata

    6）-appendToFile：追加一个文件到已经存在的文件末尾

    touch hdfs.txt
vi hdfs.txt

    输入

    namenode datanode block replication
    hadoop fs -appendToFile hdfs.txt /test/bigdata/hadoop.txt

    7）-cat：显示文件内容

    hadoop fs -cat /test/bigdata/hadoop.txt

    8）-chgrp 、-chmod、-chown：Linux文件系统中的用法一样，修改文件所属权限

    hadoop fs -chmod 666 /test/bigdata/hadoop.txt
hadoop fs -chown root:root /test/bigdata/hadoop.txt

    9）-copyFromLocal：从本地文件系统中拷贝文件到HDFS路径去

    hadoop fs -copyFromLocal README.txt /

    10）-copyToLocal：从HDFS拷贝到本地

    hadoop fs -copyToLocal /test/bigdata/hadoop.txt ./

    11）-cp ：从HDFS的一个路径拷贝到HDFS的另一个路径

    hadoop fs -cp /test/bigdata/hadoop.txt /hdfs.txt

    12）-mv：在HDFS目录中移动文件

    hadoop fs -mv /hdfs.txt /test/bigdata/

    13）-get：等同于copyToLocal，就是从HDFS下载文件到本地

    hadoop fs -get /test/bigdata/hadoop.txt ./

    14）-put：等同于copyFromLocal

    hadoop fs -mkdir -p /user/root/test/
vim yarn.txt

    输入

    resourcemanager nodemanager
    hadoop fs -put ./yarn.txt /user/root/test/

    15）-tail：显示一个文件的末尾

    hadoop fs -tail /user/root/test/yarn.txt

    16）-rm：删除文件或文件夹

    hadoop fs -rm /user/root/test/yarn.txt

    17）-rmdir：删除空目录

    hadoop fs -mkdir /test
hadoop fs -rmdir /test

    18）-du统计文件夹的大小信息

    hadoop fs -du -s -h /user/root/test
hadoop fs -du -h /user/root/test

    19）-setrep：设置HDFS中文件的副本数量

    hadoop fs -setrep 10 /test/bigdata/hadoop.txt

    这里设置的副本数只是记录在NameNode的元数据中，是否真的会有这么多副本，还得看DataNode的数量。因为目前只有3台设备，最多也就3个副本，只有节点数的增加到10台时，副本数才能达到10。
    image.png

    JAVA客户端

    客户端环境准备

  • 将Hadoop-2.9.2安装包解压到非中文路径（例如：E:\hadoop-2.9.2）。
    image.png
  • 配置HADOOP_HOME环境变量
    image.png
  • 配置Path环境变量。
    image.png
  • 创建一个Maven工程ClientDemo

  • 导入相应的依赖坐标+日志配置文件

    <dependencies>
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>RELEASE</version>
</dependency>
<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.8.2</version>
</dependency>
<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-common</artifactId>
  <version>2.9.2</version>
</dependency>
<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-client</artifactId>
  <version>2.9.2</version>
</dependency>
<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-hdfs</artifactId>
  <version>2.9.2</version>
</dependency>
</dependencies>

    为了便于控制程序运行打印的日志数量，需要在项目的src/main/resources目录下，新建一个文件，命名为“log4j.properties”，文件内容：

    log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n
log4j.appender.logfile=org.apache.log4j.FileAppender
log4j.appender.logfile.File=target/spring.log
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n
  • 创建包名：com.test.hdfs

  • 创建HdfsClient类

    public class HdfsClient{
  
@Test
public void testMkdirs() throws IOException, InterruptedException, URISyntaxException {
  // 1 获取文件系统
  Configuration configuration = new Configuration();
  // 配置在集群上运行
  // configuration.set("fs.defaultFS", "hdfs://linux121:9000");
  // FileSystem fs = FileSystem.get(configuration);
  FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

  // 2 创建目录
  fs.mkdirs(new Path("/test"));

  // 3 关闭资源
  fs.close();
}
}

    遇到问题：
    如果不指定操作HDFS集群的用户信息，默认是获取当前操作系统的用户信息，出现权限被拒绝的问题，报错如下：
    image.png

    HDFS的API操作

    上传文件

  • 编写源代码

    @Test
public void testCopyFromLocalFile() throws IOException, InterruptedException, URISyntaxException {
// 1 获取文件系统
Configuration configuration = new Configuration();
configuration.set("dfs.replication", "2");
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 上传文件
fs.copyFromLocalFile(new Path("e:/test.txt"), new Path("/test.txt"));

// 3 关闭资源
fs.close();

System.out.println("end");
}

  • 将hdfs-site.xml拷贝到项目的根目录下

    <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<configuration>
<property>
  <name>dfs.replication</name>
  <value>1</value>
</property>
</configuration>

  • 参数优先级
    参数优先级排序：代码中设置的值>用户自定义配置文件>服务器的默认配置

    下载文件

    @Test
public void testCopyToLocalFile() throws IOException, InterruptedException, URISyntaxException{
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 执行下载操作
// boolean delSrc 指是否将原文件删除
// Path src 指要下载的文件路径
// Path dst 指将文件下载到的路径
// boolean useRawLocalFileSystem 是否开启文件校验
fs.copyToLocalFile(false, new Path("/test.txt"), new Path("e:/test_copy.txt"), true);

// 3 关闭资源
fs.close();
}

    删除文件/文件夹

    @Test
public void testDelete() throws IOException, InterruptedException, URISyntaxException{
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 执行删除
fs.delete(new Path("/api_test/"), true);

// 3 关闭资源
fs.close();
}

    查看文件名称、权限、长度、块信息

    @Test
public void testListFiles() throws IOException, InterruptedException, URISyntaxException{
// 1获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 获取文件详情
RemoteIterator<LocatedFileStatus> listFiles = fs.listFiles(new Path("/"), true);
while(listFiles.hasNext()){
  LocatedFileStatus status = listFiles.next();
  // 输出详情
  // 文件名称
  System.out.println(status.getPath().getName());
  // 长度
  System.out.println(status.getLen());
  // 权限
  System.out.println(status.getPermission());
  // 分组
  System.out.println(status.getGroup());
  // 获取存储的块信息
  BlockLocation[] blockLocations = status.getBlockLocations();
  for (BlockLocation blockLocation : blockLocations) {
    // 获取块存储的主机节点
    String[] hosts = blockLocation.getHosts();
    for (String host : hosts) {
      System.out.println(host);
    }
  }
  System.out.println("-----------华丽的分割线----------");
}

// 3 关闭资源
fs.close();
}

    文件夹判断

    @Test
public void testListStatus() throws IOException, InterruptedException, URISyntaxException{
// 1 获取文件配置信息
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 判断是文件还是文件夹
FileStatus[] listStatus = fs.listStatus(new Path("/"));
for (FileStatus fileStatus : listStatus) {
  // 如果是文件
  if (fileStatus.isFile()) {
    System.out.println("f:"+fileStatus.getPath().getName());
  }else {
    System.out.println("d:"+fileStatus.getPath().getName());
  }
}

// 3 关闭资源
fs.close();
}

    I/O流操作HDFS

    以上我们使用的API操作都是HDFS系统框架封装好的。我们自己也可以采用IO流的方式实现文件的上传和下载。

    文件上传
  • 需求：把本地e盘上的test.txt文件上传到HDFS根目录

  • 编写代码

    @Test
public void putFileToHDFS() throws IOException, InterruptedException, URISyntaxException {
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 创建输入流
FileInputStream fis = new FileInputStream(new File("e:/test.txt"));

// 3 获取输出流
FSDataOutputStream fos = fs.create(new Path("/test_io.txt"));

// 4 流对拷
IOUtils.copyBytes(fis, fos, configuration);

// 5 关闭资源
IOUtils.closeStream(fos);
IOUtils.closeStream(fis);
fs.close();
}
    文件下载
  • 需求：从HDFS上下载test.txt文件到本地e盘上

  • 编写代码

    @Test
public void getFileFromHDFS() throws IOException, InterruptedException, URISyntaxException{
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 获取输入流
FSDataInputStream fis = fs.open(new Path("/test_io.txt"));

// 3 获取输出流
FileOutputStream fos = new FileOutputStream(new File("e:/test_io_copy.txt"));

// 4 流的对拷
IOUtils.copyBytes(fis, fos, configuration);

// 5 关闭资源
IOUtils.closeStream(fos);
IOUtils.closeStream(fis);
fs.close();
}
    seek 定位读取
  • 需求：将HDFS上的test.txt的内容在控制台输出两次

  • 编写代码

    @Test
public void readFileSeek2() throws IOException, InterruptedException, URISyntaxException{
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://linux121:9000"), configuration, "root");

// 2 打开输入流,读取数据输出到控制台
FSDataInputStream in = null;
try{
  in= fs.open(new Path("/test.txt"));
  IOUtils.copyBytes(in, System.out, 4096, false);
  //从头再次读取
  in.seek(0); 
  IOUtils.copyBytes(in, System.out, 4096, false);
}finally {
  IOUtils.closeStream(in);
}
}

    注意:
    windows解压安装Hadoop后，在调用相关API操作HDFS集群时可能会报错，这是由于Hadoop安装缺少windows操作系统相关文件所致，如下图：
    image.png
    解决方案：
    百度找到winutils.exe拷贝放到windows系统Hadoop安装目录的bin目录下即可！！

HDFS文件系统权限问题：
hdfs的文件权限机制与linux系统的文件权限机制类似！！
r:read w:write x:execute 权限x对于文件表示忽略，对于文件夹表示是否有权限访问其内容
如果linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS当中的owner就是zhangsan
HDFS文件权限的目的，防止好人做错事，而不是阻止坏人做坏事。HDFS相信你告诉我你是谁，你就是谁！！
解决方案：
1）指定用户信息获取FileSystem对象
2）关闭HDFS集群权限校验

vim hdfs-site.xml

添加如下属性

<property>
  <name>dfs.permissions</name>
  <value>true</value>
</property>

修改完成之后要分发到其它节点，同时要重启HDFS集群
3）基于HDFS权限本身比较鸡肋的特点，我们可以彻底放弃HDFS的权限校验，如果生产环境中我们可以考虑借助kerberos以及sentry等安全框架来管理大数据集群安全。所以我们直接修改HDFS的根目录权限为777

hadoop fs -chmod -R 777 /

HDFS读写解析

HDFS读数据流程

image.png

  1. 客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。
  2. 挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。
  3. DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以Packet为单位来做校验）。

  4. 客户端以Packet为单位接收，先在本地缓存，然后写入目标文件。

    HDFS写数据流程

    image.png

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

验证Packet代码

@Test
public void testUploadPacket() throws IOException {
  //1 准备读取本地文件的输入流
  FileInputStream in = new FileInputStream(new File("e:/test.txt"));

  //2 准备好写出数据到hdfs的输出流
  FSDataOutputStream out = fs.create(new Path("/test.txt"), new Progressable() {
    //这个progress方法就是每传输64KB（packet）就会执行一次
    public void progress() {
      System.out.println("&");
    }
  });

  //3 实现流拷贝，默认关闭流选项是true，所以会自动关闭
  IOUtils.copyBytes(in, out, configuration); 

  //4 关流 可以再次关闭也可以不关了
}

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在内存中对数据进行增删改。

  • 第二阶段：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。

    Fsimage与Edits文件解析

    NameNode在执行格式化之后，会在/opt/test/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等
    image.png
    image.png

    Fsimage文件内容

    官方地址

    https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoophdfs/HdfsImageViewer.html

  • 查看oiv和oev命令

    hdfs

    oiv Offline Image Viewer View a Hadoop fsimage INPUTFILE using the specified PROCESSOR,saving the results in OUTPUTFILE.
    oev Offline edits viewer Parse a Hadoop edits log file INPUT_FILE and save results in OUTPUT_FILE

  • 基本语法
    hdfs oiv -p 文件类型(xml) -i 镜像文件 -o 转换后文件输出路径

  • 案例实操

    cd /opt/test/servers/hadoop-2.9.2/data/tmp/dfs/name/current
hdfs oiv -p XML -i fsimage_0000000000000000265 -o /opt/test/servers/fsimage.xml
cat /opt/test/servers/fsimage.xml
    <?xml version="1.0"?>
<fsimage>
  <version>
      <layoutVersion>-63</layoutVersion>
      <onDiskVersion>1</onDiskVersion>
      <oivRevision>826afbeae31ca687bc2f8471dc841b66ed2c6704</oivRevision>
  </version>
  <NameSection>
      <namespaceId>1393381414</namespaceId>
      <genstampV1>1000</genstampV1>
      <genstampV2>1024</genstampV2>
      <genstampV1Limit>0</genstampV1Limit>
      <lastAllocatedBlockId>1073741848</lastAllocatedBlockId>
      <txid>265</txid>
  </NameSection>
  <INodeSection>
      <inode>
          <id>16398</id>
          <type>DIRECTORY</type>
          <name>history</name>
          <mtime>1592376391028</mtime>
          <permission>root:supergroup:0777</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16399</id>
          <type>DIRECTORY</type>
          <name>done_intermediate</name>
          <mtime>1592375256896</mtime>
          <permission>root:supergroup:1777</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16400</id>
          <type>DIRECTORY</type>
          <name>root</name>
          <mtime>1592378079208</mtime>
          <permission>root:supergroup:0777</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16413</id>
          <type>FILE</type>
          <name>job_1592375222804_0001-1592375231176-root-word+count-
1592375281926-1-1-SUCCEEDED-default-1592375261492.jhist</name>
          <replication>3</replication>
          <mtime>1592375282039</mtime>
          <atime>1592375281980</atime>
          <preferredBlockSize>134217728</preferredBlockSize>
          <permission>root:supergroup:0777</permission>
          <blocks>
              <block>
                  <id>1073741834</id>
                  <genstamp>1010</genstamp>
                  <numBytes>33584</numBytes>
              </block>
          </blocks>
          <storagePolicyId>0</storagePolicyId>
      </inode>
      <inode>
          <id>16414</id>
          <type>FILE</type>
          <name>job_1592375222804_0001_conf.xml</name>
          <replication>3</replication>
          <mtime>1592375282121</mtime>
          <atime>1592375282053</atime>
          <preferredBlockSize>134217728</preferredBlockSize>
          <permission>root:supergroup:0777</permission>
          <blocks>
              <block>
                  <id>1073741835</id>
                  <genstamp>1011</genstamp>
                  <numBytes>196027</numBytes>
              </block>
          </blocks>
          <storagePolicyId>0</storagePolicyId>
      </inode>
      <inode>
          <id>16415</id>
          <type>DIRECTORY</type>
          <name>done</name>
          <mtime>1592376776670</mtime>
          <permission>root:supergroup:0777</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16427</id>
          <type>DIRECTORY</type>
          <name>logs</name>
          <mtime>1592378009623</mtime>
          <permission>root:root:0770</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16428</id>
          <type>DIRECTORY</type>
          <name>application_1592376944601_0001</name>
          <mtime>1592378045481</mtime>
          <permission>root:root:0770</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16430</id>
          <type>DIRECTORY</type>
          <name>wcoutput</name>
          <mtime>1592378037463</mtime>
          <permission>root:supergroup:0755</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16436</id>
          <type>FILE</type>
          <name>part-r-00000</name>
          <replication>3</replication>
          <mtime>1592378037264</mtime>
          <atime>1592378037074</atime>
          <preferredBlockSize>134217728</preferredBlockSize>
          <permission>root:supergroup:0644</permission>
          <blocks>
              <block>
                  <id>1073741842</id>
                  <genstamp>1018</genstamp>
                  <numBytes>43</numBytes>
              </block>
          </blocks>
          <storagePolicyId>0</storagePolicyId>
      </inode>
      <inode>
          <id>16445</id>
          <type>FILE</type>
          <name>linux123_39919</name>
          <replication>3</replication>
          <mtime>1592378045469</mtime>
          <atime>1592378045331</atime>
          <preferredBlockSize>134217728</preferredBlockSize>
          <permission>root:root:0640</permission>
          <blocks>
              <block>
                  <id>1073741848</id>
                  <genstamp>1024</genstamp>
                  <numBytes>56910</numBytes>
              </block>
          </blocks>
          <storagePolicyId>0</storagePolicyId>
      </inode>
      <inode>
          <id>16446</id>
          <type>DIRECTORY</type>
          <name>0617</name>
          <mtime>1592387393490</mtime>
          <permission>root:supergroup:0755</permission>
          <nsquota>-1</nsquota>
          <dsquota>-1</dsquota>
      </inode>
      <inode>
          <id>16449</id>
          <type>FILE</type>
          <name>banzhang.txt</name>
          <replication>1</replication>
          <mtime>1592388309046</mtime>
          <atime>1592388309026</atime>
          <preferredBlockSize>134217728</preferredBlockSize>
          <permission>root:supergroup:0644</permission>
          <storagePolicyId>0</storagePolicyId>
      </inode>
  </INodeSection>
</fsimage>

    问题：Fsimage中为什么没有记录块所对应DataNode？
    image.png
    在内存元数据中是有记录块所对应的dn信息，但是fsimage中就剔除了这个信息；HDFS集群在启动的时候会加载image以及edits文件，block对应的dn信息都没有记录，集群启动时会有一个安全模式（safemode）,安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。后续每隔一段时间dn都要汇报自己持有的block信息。

    Edits文件内容

  • 基本语法
    hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

  • 案例实操

    hdfs oev -p XML -i edits_0000000000000000266-0000000000000000267 -o /opt/test/servers/hadoop-2.9.2/edits.xml
cat /opt/test/servers/hadoop-2.9.2/edits.xml
    <?xml version="1.0" encoding="UTF-8"?>
<EDITS>
  <EDITS_VERSION>-63</EDITS_VERSION>
  <RECORD>
      <OPCODE>OP_START_LOG_SEGMENT</OPCODE>
      <DATA>
          <TXID>113</TXID>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>114</TXID>
          <SRC>/wcoutput/_SUCCESS</SRC>
          <MODE>493</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>115</TXID>
          <SRC>/wcoutput/part-r-00000</SRC>
          <MODE>493</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>116</TXID>
          <SRC>/wcoutput</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>117</TXID>
          <SRC>/wcoutput/_SUCCESS</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>118</TXID>
          <SRC>/wcoutput/part-r-00000</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_DELETE</OPCODE>
      <DATA>
          <TXID>119</TXID>
          <LENGTH>0</LENGTH>
          <PATH>/wcoutput/part-r-00000</PATH>
          <TIMESTAMP>1592377324171</TIMESTAMP>
          <RPC_CLIENTID></RPC_CLIENTID>
          <RPC_CALLID>-2</RPC_CALLID>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>120</TXID>
          <SRC>/</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>121</TXID>
          <SRC>/tmp</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>122</TXID>
          <SRC>/tmp/hadoop-yarn</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>123</TXID>
          <SRC>/tmp/hadoop-yarn/staging</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>124</TXID>
          <SRC>/tmp/hadoop-yarn/staging/history</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>125</TXID>
          <SRC>/tmp/hadoop-yarn/staging/history/done</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
  <RECORD>
      <OPCODE>OP_SET_PERMISSIONS</OPCODE>
      <DATA>
          <TXID>126</TXID>
          <SRC>/tmp/hadoop-yarn/staging/history/done/2020</SRC>
          <MODE>511</MODE>
      </DATA>
  </RECORD>
</EDITS>

    备注：Edits中只记录了更新相关的操作，查询或者下载文件并不会记录在内！！

问题：NameNode启动时如何确定加载哪些Edits文件呢？
nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件，nn如何判断哪些edits已经被合并了？
可以通过fsimage文件自身的编号来确定哪些已经被合并。
image.png

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

  3. 数量限额

    #创建hdfs文件夹
hdfs dfs -mkdir -p /user/root/test 
# 给该文件夹下面设置最多上传两个文件，上传文件，发现只能上传一个文件
hdfs dfsadmin -setQuota 2 /user/root/test 
# 清除文件数量限制
hdfs dfsadmin -clrQuota /user/root/test

  4. 空间大小限额

    # 限制空间大小4KB
hdfs dfsadmin -setSpaceQuota 4k /user/root/test
#上传超过4Kb的文件大小上去提示文件超过限额
hdfs dfs -put /export/softwares/xxx.tar.gz /user/root/test
#清除空间限额
hdfs dfsadmin -clrSpaceQuota /user/root/test
#查看hdfs文件限额数量
hdfs dfs -count -q -h /user/root/test

    HDFS的安全模式

    安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求。在NameNode主节点启动时，HDFS首先进入安全模式，DataNode在启动的时候会向NameNode汇报可用的block等状态，当整个系统达到安全标准时，HDFS自动离开安全模式。如果HDFS出于安全模式下，则文件block不能进行任何的副本复制操作，因此达到最小的副本数量要求是基于DataNode启动时的状态来判定的，启动时不会再做任何复制（从而达到最小副本数量要求），HDFS集群刚启动的时候，默认30S钟的时间是出于安全期的，只有过了30S之后，集群脱离了安全期，然后才可以对集群进行操作。

    hdfs dfsadmin -safemode

    Hadoop归档技术

    主要解决HDFS集群存在大量小文件的问题！！
    由于大量小文件会占用NameNode的内存，因此对于HDFS来说存储大量小文件造成NameNode内存资源的浪费！
    Hadoop存档文件HAR文件，是一个更高效的文件存档工具，HAR文件是由一组文件通过archive工具创建而来，在减少了NameNode的内存使用的同时，可以对文件进行透明的访问，通俗来说就是HAR文件对NameNode来说是一个文件减少了内存的浪费，对于实际操作处理文件依然是一个一个独立的文件。
    image.png
    案例

  5. 启动YARN集群

    start-yarn.sh

  6. 归档文件
    把/user/test/input目录里面的所有文件归档成一个叫input.har的归档文件，并把归档后文件存储到/user/test/output路径下。

    hadoop archive -archiveName input.har –p /user/root/input /user/root/output

  7. 查看归档

    hadoop fs -lsr /user/root/output/input.har
hadoop fs -lsr har:///user/root/output/input.har

  8. 解归档文件

    hadoop fs -cp har:///user/root/output/input.har/* /user/root

标签: Hadoop, HDFS

评论已关闭