- 在HDFS中使用的是主从结构，即一个主节点，多个从节点。
- 在HDFS中主要包含四部分：Client(Shell命令/API/Java Application)、NameNode、DataNode、SecondaryNameNode。
- NameNode节点负责维护DataNode上各个块的metadata以及整个HDFS的目录树结构，并且还会将内存中的块的metadata以及fsimage、edits等持久化文件进行备份，以防宕机时数据丢失。
- fsimage文件中保存了整个HDFS中的目录树结构、我们的数据文件分成了哪些块以及块的位置等信息。
- edits文件中存储的是用户对HDFS中的数据/文件执行的操作，当用户对HDFS的数据\文件进行修改或者添加、删除等操作时，并不会立刻去执行这些操作，而是先将这些操作记录在edits文件中。满足一定条件后，会将当前的edits文件中的操作合并为fsimage文件，并创建一个新的edits文件来记录从这次合并之后又产生的新的数据操作。合并文件是为了减小edits文件的大小，以减少下次启动服务时复盘上次最后一个edits文件所消耗的时间。
- DataNode是真正负责客户端的读写请求的，并实际存储数据的节点，在NameNode的调度安排下，进行数据块的创建、复制等操作。DataNode会定时向NameNode发送心跳以汇报自己当前状态，当某个DataNode很久没有发送心跳时，NameNode会将该节点标记为宕机状态，并不再为该节点分配请求。
- 非第一次启动集群时，NameNode会先将序号最大的fsimage文件加载到内存中，这样就会将上次持久化下来的最新的目录树结构、块的信息等数据加载进来。然后将edit中的最新序号的文件也加载进来，也就是将数据操作执行一下，以保证整个集群的状态是和上次服务停掉前的状态是一致的。
可以在ui上查看启动过程：
- ?为什么HDFS中要有fsimage和edits两种文件，而不是将所有操作或数据都有序列化在fsimage中？
- 如果每次对文件或数据进行修改/删除/添加等操作，都直接持续化到fsimage中，也即每次对数据的读写请求都直接对数据进行操作，会造成大量的磁盘IO操作，耗时较多。
- SecondaryNameNode如何辅助NameNode对fsimage和edits文件进行合并？
在ui中可以看到集群启动时有一个步骤是checkpoint：
?checkpoint就是fsimage和edits文件的合并策略，这个策略可以在hdfs-default.xml中配置。hdfs-default.xml文件在$HADOOP_HOME/share/hadoop/hdfs/hadoop-hdfs-2.7.5.jar目录下。
checkpoint的策略配置：
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600</value>
<description>The number of seconds between two periodic checkpoints.
</description>
</property>
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
<description>The Secondary NameNode or CheckpointNode will create a checkpoint
of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless
of whether 'dfs.namenode.checkpoint.period' has expired.
</description>
</property>
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60</value>
<description>The SecondaryNameNode and CheckpointNode will poll the NameNode
every 'dfs.namenode.checkpoint.check.period' seconds to query the number
of uncheckpointed transactions.
</description>
</property>也即checkpoint遵从两种策略，一种是距离上次合并时间已经达到了$dfs.namenode.checkpoint.period$，默认是3600s，也就是1小时，这时会去执行一次合并；另一种策略是距离上次合并已经有了$dfs.namenode.checkpoint.txns$(默认是1000000次)这么多次的事务，这时就会执行一次合并，两个条件满足其一即会合并。$dfs.namenode.checkpoint.check.period$这个参数指定的是多久去检查一下距离上次合并之后的事务次数是否达到$dfs.namenode.checkpoint.txns$，也即60s会去检查一下事务次数是否达到1000000次，所以这个60s也就会造成合并的延迟，因为60s检查一次就会导致并不是事务一旦达到了1000000次就会立马合并。
合并过程：
真正的合并操作其实是由SecondaryNameNode来实现的。
1.NameNode中的name目录下有edits、edits_inprogress、fsimage文件，edits_inprogress表示正在使用的edits。当满足checkpoint的条件时，SecondaryNameNode会先将最新的fsimage文件(fsimage_0000000000000000085)通过http get方式从NameNode上拿下来，然后将正在使用中的edits(edits_inprogress_0000000000000000086)重命名为edits_xxxxxxxx-0000000000000000086，SecondaryNameNode再将edits_xxxxxxxx-0000000000000000086通过http拿过来，NameNode再重新创建一个edits_inprogress_******************来作为此次合并后的新的正在使用的edits文件，并更新seen_txid文件。
可以看到seen_txid中记录的就是edits_inprogress的id
?2.SecondaryNameNode收到这两个文件后，会先将fsimage文件加载到自己的内存中，然后将edits文件也加载到内存中，并将edits中的事务操作执行一下，形成一个新的fsimage，该fsimage文件会以.ckpt为后缀。然后将该fsimage_xxxx.ckpt文件通过http协议发送给NameNode。
可以看到SecondaryNameNode节点上是没有edits_inprogress-xxxxx文件的，因为正在进行中的事务的操作都是记录在NameNode上的，而这里的edits_xxxxx和fsimage_xxxx都是在合并时NameNode发送过来的。
3.NameNode收到返回来的fsimage_xxxx.ckpt文件，对其进行重命名，将.ckpt后缀去掉，得到最新的fsimage文件工下次合并使用。
