NameNode、SecondaryNameNode、DataNode

一、NameNode(NN)
主要功能：接受客户端的读写请求并分发给DataNode，DataNode是文件的主要存储与处理的地方。而NameNode中会保存文件的元数据（metadate），包括：
1、文件的拥有者、权限、文件名等
2、文件包含的块（block）
3、这些block保存在哪个DataNode中（DataNode启动时上报）
这个metadata信息在磁盘中存储为文件“fsimage”，并且在NameNode启动后加载到内存，也就是说此时metadata在磁盘与内存中各持一份，而且是相同的。
之后，由于NameNode启动后DataNode也会随之启动，而DataNode启动后会上传block的位置信息到内存中的metadata，而不会到磁盘中的metadata，所以此时会导致内存与磁盘中metadata不一致。
并且之后用户上传文件产生的元数据都是操作的内存中的metadata，只是在操作metadata时，会通过一个edits文件记录操作日志。这个edits文件是存在磁盘中的。
所以，针对上面的过程就会有两个问题：
1、为什么不直接操作磁盘中的metadata(fsimage文件)
2、如何解决磁盘、内存不一致问题
第一个问题，如果直接操作磁盘，大量用户时会由于文件的频繁修改导致频繁IO，而造成线程阻塞之类的。
第二个问题，为了解决不一致，会按照一定的策略更新fsimage。而SecondaryNameNode就是来辅助NameNode来完成fsimage的更新的。

二、SecondaryNameNode(SNN)
它不是NameNode的备份，它的主要功能是帮助NameNode合并edits log，减少NameNode启动时间。
SNN执行合并的时机：
1、根据配置文件设置的时间间隔fs.checkpoint.period默认是3600秒
2、根据配置文件设置edits log大小fs.checkpoint.size规定edits文件的最大值，默认64MB。
就是说每隔一段时间合并一次，或者当edits文件满了就合并。
下图为其合并的机制

左侧是NameNode（NN）右边是SecondaryNameNode(SNN)，合并时，会将NN的磁盘中的fsimage和edits拿到SNN中，并且用一个新的edits继续记录操作日志，因为合并时用户可能还在操作。在SNN中fsimage将会根据edits的记录来更新fsimage,并将生成的新的fsimage重新送回NN中，一次更新便完成了。

三、DataNode（DN）
主要功能：存储数据块（block）
DN启动时会向NN汇报block信息，并且之后通过向NN发送心跳保持联系（3秒一次），如果NN在10分钟内没有收到DN的心跳，就认为该DN已经lost，并copy其上的block到其他DN。
有一个问题：既然DN已经挂了，那么是如何copy的？
因为元数据（metadata）中记录了该DN上的block编号，所以当然可以通过metadata来copy。但是如果该DN是在启动时就挂了呢？此时它还没来得及向NN上传block信息，该怎么办？其实，Hadoop会有一个checkSum机制，就是说当哪个block的副本数小于三时它就会做出copy，所以并不需要知道挂掉的DN中的block就可copy。