HDFS架构

目录

1.NameNode 

1.1NameNode管理文件系统的命名空间

1.2存储结构

2.SecondaryNameNode

2.1存在的意义

2.2工作流程

2.3检查点创建时机

2.4存储结构

3.DataNode

3.1存储结构

3.2存储数据模型（重点）

4.数据块副本放置策略

5.HDFS的权限（了解）

---

1.NameNode 

1.1NameNode管理文件系统的命名空间

1. 文件和目录的元数据：(运行时，元数据放内存)

        文件的block副本个数

        修改和访问的时间

        访问权限

        block大小以及组成文件的block列表信息

2.以两种方式在NameNode本地进行持久化：

命名空间镜像文件（fsimage）和编辑日志（edits log）。

3.fsimage文件不记录每个block所在的DataNode信息，这些信息在每次系统启动的时候从DataNode重建。之后DataNode会周期性地通过心跳包向NameNode报告block信息。DataNode向NameNode注册的时候NameNode请求DataNode发送block列表信息。

1、文件名称和路径 2、文件的大小 3、文件的所属关系 4、文件的block块大小  128MB   5、文件的副本个数  3   MR  10个副本 6、文件的修改时间 7、文件的访问时间 8、文件的权限 9、文件的block列表 blk1:0,134217728‬,node1,node13,node26：blockID blk2:134217728,134217728‬,node7,node89,node1002 blk2:134217728*2,134217728‬,node7,node89,node1002 blk2:134217728*3,134217728‬,node7,node89,node1002 blk2:134217728*4,134217728‬,node7,node89,node1002 blk2:134217728*5,134217728‬,node7,node89,node1002 blk2:134217728,134217728‬,node7,node89,node1002 blk2:134217728,134217728‬,node7,node89,node1002 ...

1.2存储结构

一个运行的NameNode如下的目录结构，该目录结构在第一次格式化的时候创建

        如果属性dfs.namenode.name.dir指定了多个路径，则每个路径中的内容是一样的，尤其是当其中一个是挂载的NFS的时候，这种机制为管理提供了一些弹性。备份数据

        in_use.lock文件用于NameNode锁定存储目录。这样就防止其他同时运行的NameNode实例使用相同的存储目录。

        edits表示edits log日志文件

        fsimage表示文件系统元数据镜像文件

        NameNode在checkpoint之前首先要切换新的edits log文件，在切换时更新seen_txid的值。上次合并fsimage和editslog之后的第一个操作编号

        VERSION文件是一个Java的属性文件

        layoutVersion是一个负数，定义了HDFS持久化数据结构的版本。这个版本数字跟hadoop发行的版本无关。当layout改变的时候，该数字减1（比如从-57到-58）。当对HDFDS进行了升级，就会发生layoutVersion的改变。

        namespaceID是该文件系统的唯一标志符，当NameNode第一次格式化的时候生成。

        clusterID是HDFS集群使用的一个唯一标志符，在HDFS联邦的情况下，就看出它的作用了，因为联邦情况下，集群有多个命名空间，不同的命名空间由不同的NameNode管理。

        blockpoolID是block池的唯一标志符，一个NameNode管理一个命名空间，该命名空间中的所有文件存储的block都在block池中。

        cTime标记着当前NameNode创建的时间。对于刚格式化的存储，该值永远是0，但是当文件系统更新的时候，这个值就会更新为一个时间戳。

        storageType表示当前目录存储NameNode内容的数据结构。

        当文件系统客户端进行了写操作（例如创建或移动了文件），这个事务首先在edits log中记录下来。NameNode在内存中有文件系统的元数据，当edits log记录结束后，就更新内存中的元数据。内存中的元数据用于响应客户端的读请求。

        edits log在磁盘上表现为一定数量的文件。每个文件称为片段（Segment），前缀“edits”，后缀是其中包含的事务ID（transaction IDs）。每个写操作事务都仅仅打开一个文件（比如：edits_inprogress_00000000000010），写完后冲刷缓冲区并同步到磁盘，然后返回客户端success状态码。如果NameNode的元数据需要写到多个目录中，则对于每个写事务需要所有的写操作都完成，并冲刷缓冲区同步到磁盘才返回success状态码。这样就可以保证在发生宕机的时候没有事务数据丢失。

        用户的操作是一个事务，每个操作NN都要先将操作记录到edits log中，如果给NN指定了多个目录，则在多个目录中都存在edits log文件，用户的操作要在多个目录中都写完成，才让NN同步数据到内存中。当NN在内存中也同步了数据，就返回客户端success。

        每个fsimage文件都是系统元数据的一个完整的持久化检查点（checkpoint）（后缀表示镜像中的最后一个事务）。写操作不更新这个数据，因为镜像文件通常为GB数量级，写到磁盘很慢。如果NameNode宕机，可以将最新fsimage加载到内存，同时执行edits log对应于该faimage之后的操作，就可以重建元数据的状态。而这正是每次启动NameNode的时候NameNode要做的工作。

tb_user
update tb_user set username='张三' where id=7000;

my.log : update tb_user set username='张三' where id=7000;

2.SecondaryNameNode

2.1存在的意义

        edits log会随着对文件系统的操作而无限制地增长，这对正在运行的NameNode而言没有任何影响，如果NameNode重启，则需要很长的时间执行edits log的记录以更新fsimage（元数据镜像文件）。在此期间，整个系统不可用。

        在系统启动期间，NameNode合并fsimage+edits log

fsimage=0

edist log=很大

内存

fsimage=GB

edits log=很大 TB

内存->执行edits log条目

        解决方案就是运行SecondaryNameNode，它的作用就是为NameNode内存中的文件系统元数据生成检查点（checkpoint）。

2.2工作流程

edits_inprogress_00000000018_0000000028  seen_txid=29

1、secondarynamenode请求namenode生成新的edits log文件并向其中写日志。NameNode会在所有的存储目录中更新seen_txid文件

2、SecondaryNameNode通过HTTP GET的方式从NameNode下载fsimage和edits文件到本地。

3、SecondaryNameNode将fsimage加载到自己的内存，并根据edits log更新内存中的fsimage信息，然后将更新完毕之后的fsimage写到磁盘上。

4、SecondaryNameNode通过HTTP PUT将新的fsimage文件发送到NameNode，NameNode将该文件保存为.ckpt的临时文件备用。

5、NameNode重命名该临时文件并准备使用。此时NameNode拥有一个新的fsimage文件和一个新的很小的edits log文件（可能不是空的，因为在SecondaryNameNode合并期间可能对元数据进行了读写操作）。管理员也可以将NameNode置于safemode，通过hdfs dfsadmin -saveNamespace命令来进行edits log和fsimage的合并。

SecondaryNameNode要和NameNode拥有相同的内存。对大的集群，SecondaryNameNode运行于一台专用的物理主机。

 2.3检查点创建时机

对于创建检查点（checkpoint）的过程，有三个参数进行配置：

1、默认情况下，SecondaryNameNode每个小时进行一次checkpoint合并

由dfs.namenode.checkpoint.period设置，单位秒

2、在不足一小时的情况下，如果edits log存储的事务达到了1000000个也进行一次checkpoint合并

由dfs.namenode.checkpoint.txns设置事务数量

3、事务数量检查默认每分钟进行一次

由dfs.namenode.checkpoint.check.period设置，单位秒。

2.4存储结构

1、SecondaryNameNode中checkpoint目录布局（dfs.namenode.checkpoint.dir）和NameNode中的一样。

2、如果NameNode完全坏掉（没有备用机，也没有NFS），可以快速地从SecondaryNameNode恢复。有可能丢数据

3、如果SecondaryNameNode直接接手NameNode的工作，需要在启动NameNode进程的时候添加-importCheckpoint选项。该选项会让NameNode从由dfs.namenode.checkpoint.dir属性定义的路径中加载最新的checkpoint数据，但是为了防止元数据的覆盖，要求dfs.namenode.name.dir定义的目录中没有内容。

3.DataNode

3.1存储结构

DataNode不需要显式地格式化;关键文件和目录结构如下：

1、HDFS块数据存储于blk_前缀的文件中，包含了被存储文件原始字节数据的一部分。

2、每个block文件都有一个.meta后缀的元数据文件关联。该文件包含了一个版本和类型信息的头部，后接该block中每个部分的校验和。

3、每个block属于一个block池，每个block池有自己的存储目录，该目录名称就是该池子的ID（跟NameNode的VERSION文件中记录的block池ID一样）。

当一个目录中的block达到64个（通过dfs.datanode.numblocks配置）的时候，DataNode会创建一个新的子目录来存放新的block和它们的元数据。这样即使当系统中有大量的block的时候，目录树也不会太深。同时也保证了在每个目录中文件的数量是可管理的，避免了多数操作系统都会碰到的单个目录中的文件个数限制（几十几百上千个）。

如果dfs.datanode.data.dir指定了位于在不同的硬盘驱动器上的多个不同的目录，则会通过轮询的方式向目录中写block数据。需要注意的是block的副本不会在同一个DataNode上复制，而是在不同的DataNode节点之间复制。

3.2存储数据模型（重点）

1、文件线性切割成块（Block）（按字节切割）

2、Block分散存储在集群节点中

3、单一文件Block大小一致，文件与文件可以不一致

hdfs  dfs  -D  dfs.blocksize=1048576  -D dfs.replication=3  -put hello.txt  /

4、Block可以设置副本数，副本分散在不同节点中

        a) 副本数不要超过节点数量

        b) 承担计算

        c) 容错

5、文件上传可以设置Block大小和副本数

6、已上传的文件Block副本数可以调整，大小不变

7、只支持一次写入多次读取，同一时刻只有一个写入者，对同一个文件，一个时刻只有一个写入者

8、可以append追加数据

4.数据块副本放置策略

Block的副本放置策略

第一个副本：放置在上传文件的DN；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。

第二个副本：放置在于第一个副本不同的 机架的节点上。

第三个副本：与第二个副本相同机架的节点。

更多副本：随机节点

源代码：

5.HDFS的权限（了解）

1、每个文件和目录都和一个拥有者和组相关联。

2、文件或者目录对与拥有者、同组用户和其他用户拥有独立的权限。

3、对于一个文件，r表示读取的权限，w表示写或者追加的权限。对于目录而言，r表示列出目录内容的权限，w表示创建或者删除文件和目录的权限，x表示访问该目录子项目的权限。

4、默认情况下hadoop运行时安全措施处于停用模式。一个客户端可以在远程系统上通过创建和任意一个合法用户同名的账号来进行访问。 hadoop  root

5、安全措施可以防止用户或自动工具及程序意外修改或删除文件系统的重要部分。（dfs.permissions.enabled属性）。防止好人做错事。

6、超级用户是namenode进程的标识。对于超级用户，系统不会执行任何权限检查。