7.2 KiB

Raw Blame History Unescape Escape

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

一、概述

NameNode是整个文件系统的管理节点，它主要维护着整个文件系统的文件目录树，文件/目录的信息和每个文件对应的数据块列表，并且还负责接收用户的操作请求

文件目录树

表示目录之间的层级关系，就是我们在hdfs上执行ls命令可以看到的那个目录结构信息

文件/目录的信息

表示文件/目录的的一些基本信息，所有者属组修改时间文件大小等信息

数据块列表

如果一个文件太大，那么在集群中存储的时候会对文件进行切割，这个时候就类似于会给文件分成一块一块的，存储到不同机器上面。所以HDFS还要记录一下一个文件到底被分了多少块，每一块都在什么地方存储着

二、元数据文件

fsimage：元数据镜像文件，存储某一时段NameNode内存元数据信息
edits：操作日志文件
seen_txid：是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性。
VERSION：保存了集群的版本信息

根据hdfs-site.xml文件配置，找到dfs.namenode.name.dir属性，可以找到元数据目录$dfs.namenode.name.dir/current ! in_use.lock 这个只是一个普通文件，但是它其实有特殊的含义，文件名后缀值lock 表示是锁的意思，文件名是in_use 表示这个文件现在正在使用，不允许你再启动namenode。当我们启动namonde的时候会判断这个目录下是否有in_use.lock 这个相当于一把锁，如果没有的话，才可以启动成功，启动成功之后就会加一把锁，停止的时候会把这个锁去掉。 !

2.1 fsimage

fsimage文件有两个文件名相同的，有一个后缀是md5，md5是一种加密算法，这个其实主要是为了做md5校验的，为了保证文件传输的过程中不出问题，相同内容的md5是一样的，所以后期如果我把这个fsimage和对应的fsimage.md5发给你然后你根据md5对fsimage的内容进行加密，获取一个值和fsimage.md5中的内容进行比较，如果一样，说明你接收到的文件就是完整的。

通过命令将fsimage转为xml，方便查看

hdfs oiv -p XML -i fsimage_0000000000000000056 -o fsimage56.xml

里面最外层是一个fsimage标签，看里面的inode标签，这个inode表示是hdfs中的每一个目录或者文件信息

<inode>
            <id>16393</id>
            <type>FILE</type>
            <name>LICENSE.txt</name>
            <replication>2</replication>
            <mtime>1586332513657</mtime>
            <atime>1586332513485</atime>
            <preferredBlockSize>134217728</preferredBlockSize>
            <permission>root:supergroup:0644</permission>
            <blocks>
                <block>
                    <id>1073741827</id>
                    <genstamp>1003</genstamp>
                    <numBytes>150569</numBytes>
                </block>
            </blocks>
            <storagePolicyId>0</storagePolicyId>
</inode>

id：唯一编号 type：文件类型 name：文件名称 replication：文件的副本数量 mtime：修改时间 atime：访问时间 preferredBlockSize：推荐每一个数据块的大小 permission：权限信息 blocks：包含多少数据块【文件被切成数据块】 block：内部的id表示是块id，genstamp是一个唯一编号，numBytes表示当前数据块的实际大小，storagePolicyId表示是数据的存储策略

这个文件中其实就维护了整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表，所以说fsimage中存放了hdfs最核心的数据。

2.2 edits

当我们上传大文件的时候，一个大文件会分为多个block，那么edits文件中就会记录这些block的上传状态，只有当全部block都上传成功了以后，这个时候edits中才会记录这个文件上传成功了，那么我们执行hdfs dfs -ls 的时候就能查到这个文件了，所以当我们在hdfs中执行ls命令的时候，其实会查询fsimage和edits中的内容。

查看edits文件：

hdfs oev -i  edits_0000000000000000057-0000000000000000065  -o edits.xml

OP_ADD：执行上传操作 OP_ALLOCATE_BLOCK_ID：申请block块id OP_SET_GENSTAMP_V2：设置GENSTAMP OP_ADD_BLOCK：添加block块 OP_CLOSE：关闭上传操作

<RECORD>
    <OPCODE>OP_ADD</OPCODE>
    <DATA>
        <TXID>58</TXID>
        <LENGTH>0</LENGTH>
        <INODEID>16396</INODEID>
        <PATH>/user.txt</PATH>
        <REPLICATION>3</REPLICATION>
        <MTIME>1586349095694</MTIME>
        <ATIME>1586349095694</ATIME>
        <BLOCKSIZE>134217728</BLOCKSIZE>
        <CLIENT_NAME>DFSClient_NONMAPREDUCE_-1768454371_1</CLIENT_NAME>
        <CLIENT_MACHINE>192.168.182.1</CLIENT_MACHINE>
        <OVERWRITE>true</OVERWRITE>
        <PERMISSION_STATUS>
            <USERNAME>yehua</USERNAME>
            <GROUPNAME>supergroup</GROUPNAME>
            <MODE>420</MODE>
        </PERMISSION_STATUS>
        <ERASURE_CODING_POLICY_ID>0</ERASURE_CODING_POLICY_ID>
        <RPC_CLIENTID>1722b83a-2dc7-4c46-baa9-9fa956b755cd</RPC_CLIENTID>
        <RPC_CALLID>0</RPC_CALLID>
    </DATA>
</RECORD>
<RECORD>
    <OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
    <DATA>
        <TXID>59</TXID>
        <BLOCK_ID>1073741830</BLOCK_ID>
    </DATA>
</RECORD>

每一个record都有一个事务id，txid，事务id是连续的（从58到59，正常情况下有5个步骤，所以有5个连续的txid），其实一个put操作会在edits文件中产生很多的record，对应的就是很多步骤，这些步骤对我们是屏蔽的。

2.3 seen_txid

! seen_txid文件，HDFS format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性。

2.4 VERSION

三、SNN合并日志

edits隔一段时间就会对fsimage进行同步(合并)。edits在执行读写合并操作时，是被占用状态，整个namenode不能对外提供服务。用户一来会先找edits。这样不好。namenode是整个集群的管理和元数据记录。读写操作消耗很大。合并这件事可以定期发送给SecondaryNameNode来做。为了保证实时提供服务创建新的edits临时替代原来的edits对外提供服务。SecondaryNameNode的fsimage和edits合并后得到新的fsimage(SecondaryNameNode的edits被删除)传回给namenode，namenode的edits被清空。

7.2 KiB Raw Blame History Unescape Escape