:-:  hdfs组成架构 架构主要由四个部分组成，分别为 HDFS Client、NameNode、DataNode 和Secondary NameNode。 <br/> 结合前面安装环境启动的进程，HDSF 启动的时候有 NameNode、DataNode 和 Secondary NameNode进程。 <br/> **1. Client**：就是客户端，自己编写的代码+Hadoop API。其主要功能： （1）进行文件切分。文件上传 HDFS 的时候，Client 将文件切分成一个一个的 Block，然后进行存储。 （2）当我们要查询一个文件时，与 NameNode 交互，获取文件的位置信息。 （3）与 DataNode 交互，读取或者写入数据。 （4）Client 提供一些命令来管理 HDFS，比如启动或者关闭 HDFS。 （5）Client 可以通过一些命令来访问 HDFS。 <br/> **2. NameNode**：就是 Master，它是一个主管、管理者。也叫 HDFS 的元数据节点。集群中只能有一个活动的 NameNode 对外提供服务。 （1）管理 HDFS 的名称空间（文件目录树）；HDFS 很方便的一点就是对于用户来说很友好，用户不考虑细节的话，看到的目录结构和我们使用 Window 和Linux 文件系统很像。 （2）管理数据块（Block）映射信息及副本信息；一个文件对应的块的名字以及块被存储在哪里，以及每一个文件备份多少都是由 NameNode 来管理。 （3）处理客户端读写请求。 <br/> **3. DataNode**：就是 Slave。实际存储数据块的节点，根据 NameNode 下达的命令，DataNode 执行实际的操作。 （1）存储实际的数据块。 （2）根据NameNode的命令执行数据块的读/写操作。 <br/> **4. Secondary NameNode**：并非 NameNode 的热备。当 NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。它的功能如下： （1）辅助 NameNode，分担其工作量。 （2）定期合并 Fsimage 和 Edits，并推送给 NameNode。 （3）在紧急情况下，可辅助恢复 NameNode。 Secondary NameNode 的工作与 HDFS 设计是相关的，主要针对元数据设计的。它维护了两种文件 **Fsimage** 和 **Edits**。 <br/> Fsimage 镜像文件，是元数据在某个时间段的快照，Edits 记录了生成快照之后的一系列操作。<br/> HDFS 在最初格式化启动时，创建 Edits 和 Fsimage 文件，并在内存中维护一版元数据信息，这时候，Fsimage 和内存中的元数据信息是相同的。后续每一次客户端操作时，会先记录客户端执行的操作到 Edits 文件中，然后再更新内存中对应的目录树结构，比如用户删除一个文件，会先在 Edits 文件中记录一个 delete 操作，然后在内存中真正删除文件。<br/> 也就是说，内存中的元数据信息是完整的。前面生成的快照 Fsimage 只是元数据的一部分，执行完 Edits 文件中相关操作才能与内存中元数据相同。<br/> 为什么要这么设计呢？ 首先，为什么不直接更新Fsimage，而是要新添加Edits文件。这里就需要明确Fsimage里面存的是元数据目录树信息，其实是一个内存对象序列化后的内容。要更新这个文件，首先得反序列化对象加载到内存中，在实际工作，这个文件很大，序列化和反序列化过程会很繁重，速度会很慢。而 Edits 文件只需要 append操作记录即可。这样既保证了元数据不会丢失，也提高了性能。<br/> SecondaryNameNode 具体干什么事情？ 当 HDFS 运行一段时间后，需要重启动时，<ins>需要将Fsimage加载到内存中，并把Eidts文件中的操作执行一遍，才是完整的元数据信息</ins>。假如操作记录比较频繁或者长时间没有重启过，Edits 文件会很大。重启的时候合并Fsimage+Edits文件的操作也是很耗时的，增加了启动时间。SecondaryNameNode就是解决这种问题的，它是一个独立的进程，<ins>定期（满足一定条件）会将 Fsimage+Edits 合并成一个新的 Fsimage，减少 HDFS 重启时间</ins>。