NameNode 负责管理整个分布式系统的元数据，主要包括：
目录树结构；文件到数据库 Block 的映射关系；Block 副本及其存储位置等管理数据；DataNode的状态监控，两者通过段时间间隔的心跳；这些数据保存在内存中，同时在磁盘保存两个元数据管理文件：fsimage 和 editlog。（元数据持久化为2种形式）
fsimage：是内存命名空间元数据在外存的镜像文件；editlog：则是各种元数据操作的 write-ahead-log 文件，在体现到内存数据变化前首先会将操作记入 editlog 中，以防止数据丢失。这两个文件相结合可以构造完整的内存数据。
负责数据块的实际存储和读写工作，当客户端上传一个大文件时，HDFS 会自动将其切割成固定大小的 Block，为了保证数据可用性，每个 Block 会以多备份的形式存储，默认是3份。
定期从 NameNode 拉取 fsimage 和 editlog 文件，并对两个文件进行合并，形成新的 fsimage 文件并传回 NameNode，这样做的目的是减轻 NameNode的工作压力，本质上 SNN 是一个提供检查点功能服务的服务点。 Secondary NameNode工作机制
参考：HDFS架构
在HDFS中，Namenode可能成为集群的单点故障，Namenode不可用时，整个文件系统是不可用的。HDFS针对单点故障提供了2种解决机制： 1）备份持久化元数据 将文件系统的元数据同时写到多个文件系统， 例如同时将元数据写到本地文件系统及NFS。这些备份操作都是同步的、原子的。 2）Secondary Namenode Secondary节点定期合并主Namenode的namespace image和edit log， 避免edit log过大，通过创建检查点checkpoint来合并。它会维护一个合并后的namespace image副本， 可用于在Namenode完全崩溃时恢复数据。
在HDFS集群中，NameNode依然是单点故障，元数据同时写到多个文件系统以及Second NameNode定期checkpoint有利于保护数据丢失，但是并不能提高可用性。 这是因为NameNode是唯一一个对文件元数据和file-block映射负责的地方， 当它挂了之后，包括MapReduce在内的作业都无法进行读写。 当NameNode故障时，常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于：
多文件系统写入中的备份Second NameNode的检查点文件Hadoop的HA方案 采用HA的HDFS集群配置两个NameNode，分别处于Active和Standby状态。当Active NameNode故障之后，Standby接过责任继续提供服务。 1） 主备需共享edit log存储。 2）DataNode需要同时往主备发送Block Report
RPC：远程过程调用，简单的理解是一个节点请求另一个节点提供的服务 参考：读写流程
参考：常见面试题
参考：hadoop的常用配置
整个HDFS集群由Namenode和Datanode构成master-worker（主从）模式。Namenode负责构建命名空间，管理文件的元数据等，而Datanode负责实际存储数据，负责读写工作。
副本存放
第一个副本放在客户端相同的机器上第二个副本随机放在不同于第一个副本的机架上第三个副本放在跟第二个副本同一机架上HDFS的读写详解
hadoop fs 可以用于其他文件系统，不止是hdfs文件系统内 hadoop dfs 专门针对hdfs分布式文件系统 hdfs dfs 只HDFS文件系统相关，常用
