Hadoop版本特性及读写过程

上一回我们已经讲完HDFS的教程与命令示例，笔者作为一名苦逼大学生，不到考试前的最后一刻，是时时刻刻都在摆烂的，但是木办法，马上要考试了，所以继续完善HDFS部分。没有看前一篇文章的朋友，请先移步下文进行基础学习，再来习本文=v=。
HDFS教程及命令实例

本文比较枯燥 静下心来慢慢来，如果看不下去了 建议Jump让室友保研

Hadoop 版本特性

1. NN和2NN工作机制

如果元数据存储在NameNode节点的磁盘中，因为经常需要随机访问，还有响应客户请求，必然是效率过低。

因此元数据需要存放在内存中。但如果元数据仅存放在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此，需要在磁盘中备份元数据，fsimage。

当在内存中的元数据更新时，如果同时更新fsimage，就会导致效率过低。但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会造成数据丢失。

引入edits文件，只进行追加（append）操作，效率很高。每当有元数据有更新或者增加元数据时，修改内存中的元数据并追加到edits中。这样，NameNode断电，可以通过fsimage和edits的合并，合成元数据。

但是这样又出现了问题，如果长时间增加数据到edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间更长。因此，**需要定时进行fsimage和edits的合并。**如果这个操作由NameNode节点完场，会降低效率。这时，我们引入一个新的节点SecondaryNameNode，专门用于fsimage和edits的合并。

工作过程：

2. Hadoop 2版本特性 -1

2.1 Fsimage和Edits解析

在NameNode节点上进入current文件夹
cd $HADOOP_HOME/data/tmp/dfs/name/current/


在SecondaryNameNode进入current文件夹
cd $HADOOP_HOME/data/tmp/dfs/namesecondary/current

可以看到SecondaryNameNode节点上Current文件夹没有edits_inprogress文件，这是因为SecondaryNameNode节点负责合并，而NameNode节点还在正常运行，所以在合并过程中，正在使用的edits被锁定，生成一个新的edits文件使用

查看seen_txid即可证明该点。

此例说明namenode正在使用edits_inprogress_*159文件。

要想查看fsimage、edits文件的内容，通过vim、cat等是乱码格式、如图：


这时我们就要采用HDFS提供的工具来查看该文件。
查看fsimage
命令：hdfs ovi
参数：
-p：选择文件的处理器
-i：输入的文件
-o：输出的文件

示例：bin/hdfs oiv -p XML -i fsimage_xxx -o fsimage.xml


查看该文件：

该文件格式较乱，可以在服务端导出，通过IDEA等查看。

通过IDEA格式化后可得到如下：

<?xml version="1.0"?>
<fsimage>
    <NameSection>
        <genstampV1>1000</genstampV1>
        <genstampV2>1013</genstampV2>
        <genstampV1Limit>0</genstampV1Limit>
        <lastAllocatedBlockId>1073741834</lastAllocatedBlockId>
        <txid>158</txid>
    </NameSection>
    <INodeSection>
        <lastInodeId>16417</lastInodeId>
        <inode>
            <id>16385</id>
            <type>DIRECTORY</type>
            <name></name>
            <mtime>1636637670618</mtime>
            <permission>root:supergroup:rwxr-xr-x</permission>
            <nsquota>9223372036854775807</nsquota>
            <dsquota>-1</dsquota>
        </inode>
        <inode>
            <id>16386</id>
            <type>DIRECTORY</type>
            <name>tmp</name>
            <mtime>1636637670618</mtime>
            <permission>root:supergroup:rwxrwxrw-</permission>
            <nsquota>-1</nsquota>
            <dsquota>-1</dsquota>
        </inode>
        <inode>
            <id>16387</id>
            <type>DIRECTORY</type>
            <name>hadoop-yarn</name>
            <mtime>1636458061577</mtime>
            <permission>root:supergroup:rwxrwx---</permission>
            <nsquota>-1</nsquota>
            <dsquota>-1</dsquota>
        </inode>
        <inode>
            <id>16388</id>
            <type>DIRECTORY</type>
            <name>staging</name>
            <mtime>1636458061577</mtime>
            <permission>root:supergroup:rwxrwx---</permission>
            <nsquota>-1</nsquota>
            <dsquota>-1</dsquota>
        </inode>
        <inode>
            <id>16389</id>
            <type>DIRECTORY</type>
            <name>history</name>
            <mtime>1636458061633</mtime>
            <permission>root:supergroup:rwxrwx---</permission>
            <nsquota>-1</nsquota>
            <dsquota>-1</dsquota>
        </inode>
        <inode>
            <id>16390</id>
            <type>DIRECTORY</type>
            <name>done</name>
            <mtime>1636458061577</mtime>
            <permission>root:supergroup:rwxrwx---</permission>
            <nsquota>-1</nsquota>
            <dsquota>-1</dsquota>
        </inode>
        <inode>
            <id>16391</id>
            <type>DIRECTORY</type>
            <name>done_intermediate</name>
            <mtime>1636458061633</mtime>
            <permission>root:supergroup:rwxrwxrwt</permission