在上一章中，我们了解了HDFS的设计思想，从而引出了一些相关概念，比如块、名称节点（Namenode）、数据节点（Datanode）、还有SecondaryNamenode等等。在这一章，我们从HDFS的整体结构上再来全面了解一下。
一、体系结构简介
HDFS 采用的是master/slaves这种主从的结构模型来管理数据，这种结构模型主要由四个部分组成，分别是Client(客户端)、Namenode(名称节点)、Datanode(数据节点)和SecondaryNameNode(第二节点，上面的图解中没有涉及到，下面会讲解)。真正的一个HDFS集群包括一个Namenode和若干数目的Datanode。Namenode是一个中心服务器，负责管理文件系统的命名空间 (Namespace )及客户端对文件的访问。集群中的Datanode一般是一个节点运行一个DataNode进程，负责管理客户端的读写请求，在Namenode的统一调度下进行数据块的创建、删除和复制等操作。数据块实际上都是保存在Datanode本地的Linux文件系统中的。每个Datanode会定期的向Namenode发送数据，报告自己的状态(我们称之为心跳机制)。没有按时发送心跳信息的Datanode会被Namenode标记为“宕机”，不会再给他分配任何I/O请求。
用户在使用Client进行I/O操作时,仍然可以像使用普通文件系统那样，使用文件名去存储和访问文件，只不过，在HDFS内部，一个文件会被切分成若干个数据块，然后被分布存储在若干个Datanode上。
比如，用户在Client上需要访问一个文件时，HDFS的实际工作流程如此：客户端先把文件名发送给Namenode，Namenode根据文件名找到对应的数据块信息及其每个数据块所在的Datanode位置，然后把这些信息发送给客户端。之后，客户端就直接与这些Datanode进行通信，来获取数据（这个过程，Namenode并不参与数据块的传输）。这种设计方式，实现了并发访问，大大提高了数据的访问速度。
HDFS集群中只有唯一的一个Namenode,负责所有元数据的管理工作。这种方式保证了Datanode不会脱离Namenode的控制，同时，用户数据也永远不会经过Namenode，大大减轻了Namenode的工作负担，使之更方便管理工作。通常在部署集群中，我们要选择一台性能较好的机器来作为Namenode。当然，一台机器上也可以运行多个Datanode，甚至Namenode和Datanode也可以在一台机器上，只不过实际部署中，通常不会这么做的哦。
二、体系解析
1、Client
严格意义上，HDFS集群上是没有客户端这一部分的，它只是提供了用户操作HDFS的程序接口。HDFS提供了各种各样的客户端接口，比如命令行接口、Java API, Thrift接口、C语言库、用户空间文件系统〔Filesystem in Userspace,FUSE)等。这样，用户就可以有选择的使用客户端程序来操纵HDFS进行浏览、读取和写入等操作了。
客户端程序可以在集群外的任意一台机器上，也可以在集群中的一个节点上。只要客户端能拥有Namenode的ip地址以及端口号信息。
2、Namenode
Namenode是集群主从(master/slaves)结构模型中的唯一一个管理者(master)，它负责维护HDFS文件系统的命名空间，以及管理数据块位置信息。
命名空间(Namespace)的管理：命名空间指的就是文件系统树及整棵树内的所有文件和目录的元数据，Namenode会在内存里维护文件系统的元数据以及，同时还使用fsimage和editlog两个文件来辅助管理元数据，并持久化到本地磁盘上。
fsimage：命名空间镜像文件，它是文件系统元数据的一个完整的永久检查点，内部维护的是最近一次检查点的文件系统树和整棵树内部的所有文件和目录的元数据，如修改时间，访问时间，访问权限，副本数据，块大小，文件的块列表信息等等。
editlog：编辑日志文件，当hdfs文件系统发生打开、关闭、创建、删除、重命名等操作产生的信息除了在保存在内存中外，还会持久化到编辑日志文件。比如上传一个文件后，日志文件里记录的有这次事务的txid,文件的inodeid,数据块的副本数，数据块的id，数据块大小，访问时间，修改时间等
Namenode在内存中，也记录着每个文件的各个块所在的数据节点的位置信息(数据块-Datanode映射信息)，但是并不持久保存位置信息，因为这些信息会在文件系统启动时动态的重建这些信息(心跳机制，blockreport)。
当然，Namenode也管理着客户端对文件的访问等操作，比如客户端想要访问一个文件，得需要通过Namenode的检查，比如权限检查，文件是否存在，及其数据块的Datanode列表信息等。