【博学谷学习记录】超强总结，用心分享丨大数据超神之路(五)：Hadooop进阶版

第1章 问题解答

1.1 Hadoop架构

• NameNode

  1、NameNode管理整个HDFS集群
  2、NameNode管理整个HDFS的所有元数据(/a.txt rwx 1K 3  {
       blk:node1,node2,node3})
  3、Client要上传或者下载文件必须先找NameNode
  4、一旦NameNode挂掉，整个HdFS集群将无法工作
  5、各个DataNode隔一段时间向NameNode汇报自己的Block信息和磁盘信息
  

• DataNode

  1、DataNode是具体存数据的，HDFS所有真实数据都在DataNode存储
  2、各个DataNode隔一段时间向NameNode汇报自己的Block信息和磁盘信息
  3、Client在上传和下载文件时，和NameNode交流之后，真实的数据上传和下载是在Client和DataNode之间
  

• SecondaryNameNode

 1、辅助NameNode进行元数据管理，将NameNode内存中元数据保存到硬盘上

   问题一：HDFS块的大小应该如何设置？
   块设置的太小，会增加寻址时间，程序会一直在找块的开始位置。
   块设置的太大，从磁盘传输的时间会明显大于定位块的时间，导致程序在处理这块数据时，非常慢。
   综上，块的设置大小主要取决于磁盘传输速率：固态硬盘可以设置500MB，机械硬盘100-200MB

第2章 Trash垃圾回收

   HDFS本身也是一个文件系统，那么就会涉及到文件数据的删除操作。默认情况下，HDFS中是没有回收站垃圾桶概念的，删除操作的数据将会被直接删除，没有后悔药。
   Trash机制，叫做回收站或者垃圾桶。Trash就像Windows操作系统中的回收站一样。它的目的是防止你无意中删除某些东西。默认情况下是不开启的。
   启用Trash功能后，从HDFS中删除某些内容时，文件或目录不会立即被清除，它们将被移动到回收站Current目录中(/user/${username}/.Trash/current)。
   .Trash中的文件在用户可配置的时间延迟后被永久删除。也可以简单地将回收站里的文件移动到.Trash目录之外的位置来恢复回收站中的文件和目录。

检查点仅仅是用户回收站下的一个目录，用于存储在创建检查点之前删除的所有文件或目录。如果你想查看回收站目录，可以在/user/$username/.Trash/timestam{p}_o{f}_{c}heckpoin{t}_{c}reation处看到:最近删除的文件被移动到回收站Current目录，并且在可配置的时间间隔内，HDFS会为在Current回收站目录下的文件创建检查点/user/${username}/.Trash/<日期>，并在过期时删除旧的检查点。

2.1 功能开启，修改core-site.xml

<property>  
    <name>fs.trash.interval</name>  
    <value>1440</value>  
</property>  
<property>  
    <name>fs.trash.checkpoint.interval</name>  
    <value>0</value>  
</property>

   fs.trash.interval：分钟数，当超过这个分钟数后检查点会被删除。如果为零，Trash回收站功能将被禁用。
   fs.trash.checkpoint.interval：检查点创建的时间间隔(单位为分钟)。其值应该小于或等fs.trash.interval。如果为零，则将该值设置为fs.trash.interval的值。每次运行检查点时，它都会从当前版本中创建一个新的检查点，并删除在数分钟之前创建的检查点

2.2 功能使用

   开启Trash功能后，正常执行删除操作，文件实际并不会被直接删除，而是被移动到了垃圾回收站。
   有的时候，我们希望直接把文件删除，不需要再经过Trash回收站了，可以在执行删除操作的时候添加一个参数：-skipTrash.

[root@node1 hadoop-3.3.0]# hadoop fs -ls /
Found 4 items
-rw-r--r--   3 root supergroup      15697 2022-10-21 10:16 /LICENSE.txt
drwxr-xr-x   - root supergroup          0 2022-10-20 19:15 /output
drwxrwx---   - root supergroup          0 2022-10-20 17:25 /tmp
drwxr-xr-x   - root supergroup          0 2022-10-20 17:15 /wcinput
[root@node1 hadoop-3.3.0]# hadoop fs -rm /LICENSE.txt
2022-10-21 11:18:24,961 INFO fs.TrashPolicyDefault: Moved: 'hdfs://node1:8020/LICENSE.txt' to trash at: hdfs://node1:8020/user/root/.Trash/Current/LICENSE.txt

第3章 Archive档案的使用

第4章 Hadoop的shell操作

2.1 上传

• hadoop fs -put/-copyFromLocal：上传
• hadoop fs -moveFromLocal：从本地剪切粘贴到HDFS
• hadoop fs -appendToFile：追加一个文件到已经存在的文件末尾
  

2.2 下载

• hadoop fs -copyToLocal/-get：从HDFS拷贝到本地
• hadoop fs -getmerge：合并下载多个文件,把hdfs系统上多个文件合并下载成一个文件，用的很少
  

2.3 直接操作

• hadoop fs -ls /：显示目录信息
• hadoop fs -mkdir -p：创建目录
• hadoop fs -cat：显示文件内容
• hadoop fs -rm：删除文件或者文件夹
• hadoop fs -setrep：设置HDFS中文件的副本数量，这里设置的副本数只是记录在NameNode的元数据中，是否真的会有这么多副本，还得看DataNode的数量。因为目前只有3台设备，最多也就3个副本，只有节点数的增加到10台时，副本数才能达到10。

2.4 元数据辅助管理

第4章 Hadoop的客户端操作（开发重点）

   涉及的主要类
   在Java中操作HDFS，主要涉及以下Class：

• Configuration：该类的对象封转了客户端或者服务器的配置
• FileSystem：该类的对象是一个文件系统对象，可以用该对象的一些方法来对文件进行操作，通过FileSystem的静态方法get获得该对象。FileSystem fs = FileSystem.get(conf);
• get方法从conf中的一个参数 fs.defaultFS的配置值判断具体是什么类型的文件系统。如果我们的代码中没有指定fs.defaultFS，并且工程classpath下也没有给定相应的配置，conf中的默认值就来自于hadoop的jar包中的core-default.xml，默认值为： file:///，则获取的将不是一个DistributedFileSystem的实例，而是一个本地文件系统的客户端对象。
• 官方API文档：https://hadoop.apache.org/docs/r3.3.0/api/index.html

4.1 获取FileSystem方式

4.1.1 获取FileSystem方式

注意：如果get方法不指定hadoop用户名则很多文件夹没有权限

@Test
public void getFileSystem2() throws  Exception{
   
    FileSystem fileSystem = FileSystem.get(new URI("hdfs://node1:8020"), new Configuration(),"root");
    System.out.println("fileSystem:"+fileSystem);
}

第5章 NameNode和SecondaryNameNode

5.1 NN和2NN工作机制

思考：NameNode中的元数据是存储在哪里的？

   首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。
   这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。
   但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。

NN和2NN工作机制详解：
Fsimage：NameNode内存中元数据序列化后形成的文件。
Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据）。
NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息。然后，NameNode会在内存中执行元数据的增删改的操作。
由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage）。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。
SecondaryNameNode首先会询问NameNode是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了）。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动Edits的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint，然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。

1）第一阶段：NameNode启动
（1）第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求。
（3）NameNode记录操作日志，更新滚动日志。
（4）NameNode在内存中对元数据进行增删改。
2）第二阶段：Secondary NameNode工作
（1）Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
（2）Secondary NameNode请求执行CheckPoint。
（3）NameNode滚动正在写的Edits日志。
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint。
（7）拷贝fsimage.chkpoint到NameNode。
（8）NameNode将fsimage.chkpoint重新命名成fsimage

5.2 Fsimage和Edits解析

转载：https://blog.csdn.net/Mrxuchen/article/details/127385202