从上图可以明显的看出，Hdfs是一个典型的主/从架构。
我们看看它有什么组件
NameNodeMaster由一个NameNode组成，是一个主服务器，主要功能如下：
负责管理文件系统的命名空间，存储元数据（文件名称、大小、存储位置等）
协调客户端对文件的访问
NameNode会将所有的文件和文件夹存储在一个文件系统的目录树中，并且记录任何元数据的变化。
我们知道Hdfs会将文件拆分为多个数据块保存，其中文件与文件块的对应关系也存储在文件系统的目录树中，由NameNode维护。
除了文件与数据块的映射信息，还有一个数据块与DataNode 的映射信息，
因为数据块最终是存储到DataNode中。我们需要知道一个文件数据块存在那些DataNode中，
或者说DataNode中有哪些数据块。这些信息也记录在NameNode中。
从上图中可以看到，NameNode与DataNode之间还有心跳。
NameNode会周期性的接收集群中DataNode的“心跳”和“块报告”。
通过“心跳”检测DataNode的状态（是否宕机），决定是否需要作出相关的调整策略。
“块报告”包含DataNode上所有数据块列表的信息
DataNode是Hdfs的从节点，一般会有多个DataNode（一般一个节点一个DataNode）。
主要功能如下：
管理它们所运行节点的数据存储
周期性向NameNode上报自身存储的“块信息”
这里的管理指的是在Client对Hdfs进行数据读写操作的时候，会接收来自NameNode的指令，执行数据块的创建、删除、复制等操作。
DataNode中的数据保存在本地磁盘。
Blcok从上图可以看出，在内部，一个文件会被切割为多个块（Blocks），这些块存储在一组Datanodes中，同时还有对Block进行备份（Replication）。
Hdfs文件以Block的形式存储，默认一个Block大小为128MB（1.x为64Mb）
简单来说就是一个文件会被切割为多个128MB的小文件进行储存，如果文件小于128MB则不切割，按照实际的大小存储，不会占用整个数据块的大小。
关于Hdfs读写后续会写一个源码追踪的文章，到时候就知道如何实现按照实际大小存储了。
默认Block之所以是128M，主要是降低寻址开销和获得较佳的执行效率。
因为Block越小，那么切割的文件就越多，寻址耗费的时间也会越多。
但如果Block太大，虽然切割的文件比较少，寻址快，但是单个文件过大，执行时间过长，发挥不了并行计算的优势。
每个Block的元数据也记录在NameNode中，可以说Block的大小一定程度也会影响整个集群的存储能力
同时为了容错，一般会有三个副本，副本的存放策略一般为：
备份编号 位置1 Standalone模式：上传文件的节点
Cluster模式：随机选一台内存充足的机器
2 与1号备份同机架的不同节点
3 不同机架的节点
备份除了容错，也是数据本地性（移动计算）的一个强有力支撑。
Secondary NameNode有一说一，
Secondary NameNode 取了一个标题党的的名字，这个让人感觉这就是第二个NameNode。
实际上不是，在介绍 Secondary NameNode 之前，我们得先了解NameNode是怎么存储元数据的。
我们之前说的Hdfs的元数据信息主要存在两个文件中：fsimage和edits。
fsimage：文件系统的映射文件，存储文件的元数据信息，包括文件系统所有的目录、文件信息以及数据块的索引。
edits：Hdfs操作日志文件，记录Hdfs对文件系统的修改日志。
NameNode 对这两个文件的操作如下图：