HDFS的体系结构

目录

1. 体系结构解析

         1.1HDFS进程之NameNode

        1.2HDFS进程之DataNode

        1.3HDFS进程之SecondaryNamennode

        1.4HDFS的Client接⼝

2. 映像⽂件fsimage

3.⽇志⽂件edit

---

1. 体系结构解析

HDFS采⽤的是master/slaves这种主从的结构模型来管理数据，这种结构模型主要由 四个部分组成，分别是

Client(客户端)、Namenode(名称节点)、Datanode(数据节点)和SecondaryNameNode。

真正的⼀个 HDFS 集群包括⼀个 Namenode 和若⼲数⽬的 Datanode 。

Namenode(名称节点)

        Namenode是⼀个中⼼服务器，负责管理⽂件系统的命名空间 (Namespace ), 它在内存中维护着命名空间的最新状态，同时并持久性⽂件（fsimage 和 edit ）进⾏备份， 防⽌宕机后，数据丢失。namenode 还负责管理客户端对⽂件的访问，⽐如权限验证 等。

Datanode(数据节点) 

        集群中的Datanode ⼀般是⼀个节点运⾏⼀个 Datanode 进程，真正负责管理客户端的 读写请求，在Namenode 的统⼀调度下进⾏数据块的创建、删除和复制等操作。数据块 实际上都是保存在Datanode 本地的 Linux ⽂件系统中的。每个 Datanode 会定期的向 Namenode发送数据，报告⾃⼰的状态 ( 我们称之为⼼跳机制 ) 。没有按时发送⼼跳信息 的Datanode 会被 Namenode 标记为 “ 宕机 ” ，不会再给他分配任何 I/O 请求。

        ⽤户在使⽤Client 进⾏ I/O 操作时 , 仍然可以像使⽤普通⽂件系统那样，使⽤⽂件名去

存储和访问⽂件，只不过，在 HDFS 内部，⼀个⽂件会被切分成若⼲个数据块，然后被分

布存储在若⼲个 Datanode 上

        ⽐如，⽤户在Client 上需要访问⼀个⽂件时， HDFS 的实际⼯作流程如此：客户端先把 ⽂件名发送给Namenode ， Namenode 根据⽂件名找到对应的数据块信息及其每个数据 块所在的Datanode 位置，然后把这些信息发送给客户端。之后，客户端就直接与这些 Datanode进⾏通信，来获取数据（这个过程， Namenode 并不参与数据块的传输）。 这种设计⽅式，实现了并发访问，⼤⼤提⾼了数据的访问速度。

唯⼀⼀个Namenode

        集群中只有唯⼀的⼀个Namenode, 负责所有元数据的管理⼯作。这种⽅式保证了 Datanode不会脱离 Namenode 的控制，同时，⽤户数据也永远不会经过 Namenode ，⼤ ⼤减轻了Namenode 的⼯作负担，使之更⽅便管理⼯作。通常在部署集群中，我们要选 择⼀台性能较好的机器来作为Namenode 。当然，⼀台机器上也可以运⾏多个 Datanode，甚⾄ Namenode 和 Datanode 也可以在⼀台机器上，只不过实际部署中，通 常不会这么做的

         1.1HDFS进程之NameNode

-  namenode 进程只有⼀个（ HA 除外）

-   管理 HDFS 的命名空间，并以 fsimage 和 edit 进⾏持久化保存。

-   在内存中维护数据块的映射信息

-   实施副本冗余策略

-   处理客户端的访问请求

        1.2HDFS进程之DataNode

-   存储真正的数据 ( 块进⾏存储 )

-  执⾏数据块的读写操作

-   ⼼跳机制（ 3 秒）

        1.3HDFS进程之SecondaryNamennode

-  帮助 NameNode 合并 fsimage 和 edits ⽂件

- 不能实时同步，不能作为热备份节点

        1.4HDFS的Client接⼝

- HDFS实际上提供了各种语⾔操作HDFS的接⼝。

- 与NameNode进⾏交互，获取⽂件的存储位置（读/写两种操作）

- 与DataNode进⾏交互，写⼊数据，或者读取数据

- 上传时分块进⾏存储，读取时分⽚进⾏读取

2. 映像⽂件fsimage

        命名空间指的就是⽂件系统树及整棵树内的所有⽂件和⽬录的元数据，每个 Namenode只能管理唯⼀的⼀命名空间。 HDFS 暂不⽀持软链接和硬连接。

        Namenode会在内存⾥维护⽂件系统的元数据，同时还使⽤ fsimage 和 edit ⽇志两个 ⽂件来辅助管理元数据，并持久化到本地磁盘上。

- fsimage

        命名空间镜像⽂件，它是⽂件系统元数据的⼀个完整的永久检查点，内部维护的是 最近⼀次检查点的⽂件系统树和整棵树内部的所有⽂件和⽬录的元数据，如修改时间，访 问时间，访问权限，副本数据，块⼤⼩，⽂件的块列表信息等等。

        fsimage默认存储两份，是最近的两次检查点

- 使⽤ XML 格式查看 fsimage ⽂件：

        [root@hadoop01 current]# hdfs oiv -i 【 fsimage_xxxxxxx 】 -  o 【⽬标⽂件路径】 -p XML

        案例如下：

        [root@hadoop01 current]# hdfs oiv -i fsimage_00000000052 -o  ~/fs52.xml -p XML

3.⽇志⽂件edit

        集群正常运⾏时，客户端的所有更新操作( 如打开、关闭、创建、删除、重命名等 ) 除 了在内存中维护外，还会被写到edit ⽇志⽂件中，⽽不是直接写⼊ fsimage 映像⽂ 件。

        因为对于分布式⽂件系统⽽⾔，fsimage 映像⽂件通常都很庞⼤，如果客户端所 有的更新操作都直接往fsimage ⽂件中添加，那么系统的性能⼀定越来越差。相 对⽽⾔，edit ⽇志⽂件通常都要远远⼩于 fsimage, ⼀个 edit ⽇志⽂件最⼤ 64M ， 更新操作写⼊到EditLog 是⾮常⾼效的。

        那么edit ⽇志⽂件⾥存储的到底是什么信息呢，我们可以将 edit ⽇志⽂件转成 xml ⽂ 件格式，进⾏查看

查看 editlog ⽂件的⽅式：

[root@hadoop01 current]# hdfs oev -i 【 edits_inprogress_xxx 】 -  o 【⽬标⽂件路径】 -p XML

参考 xml ⽂件后，我们可以知道⽇志⽂件⾥记录的内容有：

1. ⾏为代码：⽐如 打开、创建、删除、重命名、关闭

2. 事务 id

3. inodeid

4. 副本个数

5. 修改时间

6. 访问时间

7. 块⼤⼩

8. 客户端信息

9. 权限等

10. 块 id 等