Hadoop基础【HDFS NN和2NN工作机制、DataNode工作机制】

1、NN和2NN工作机制

        一个正常HDFS集群，读取和写入，尤其是读取是十分频繁的，读取则必然需要访问NN，读取元数据（存储数据的数据，比如索引信息），也就是说，在运行的集群中，元数据的读取是十分频繁的，而且时效性比较高，于是，元数据在运行中需要放在内存中（速度比较快）。

        将所有元数据放在内存中，又会造成一旦机器断电，所有的元数据就消失不见了。

        所以又需要将易丢失的数据放在磁盘上（持久化过程），一个64GB的NN，即使内存全部用来存储，也只能存放458129844个块，假如一块是128MB，也就是存放54PB的数据，与目前的数据量相比，54PB显然是不够的，实际上有27PB已经是很好的情况了，那么如何存储上忆PB的数据？首先想到的是将NN的内存扩大到128GB或256GB，第二是将扩大每个块的存储空间，第三个是HDFS的集群设计问题。

        总之，NN的内存可能为256GB，这么大量的数据，在持久化过程中是十分困难的，需要的时间是很长的（6-20分钟），单纯的将易丢失的数据放在磁盘上就需要6分钟，并且在工作过程中NN是不接受读写请求的。

        那么，如果NN只持久化操作，将存储元数据的操作写入磁盘中，这个操作称为编辑日志（edits.log），编辑日志中记录了操作人员的每一次操作，那么写的操作压力就变得小了许多，随之而来又会产生新的问题，一是随着操作的增加，日志文件会变得越来越大（几十TB），元数据却没有增加；二是，如果NN重启，需要将整个编辑日志从头到尾地读一遍，造成NN运行的时间越长，重启的时间就会越长。

        NN在持久化时，只想写编辑日志（edits.log）出去，但是在启动时，又偏向于完整的内存镜像（fsimage），这时就产生了新的需求，于是2NN应运而生，2NN负责每隔一段时间（距离上一次CheckPoint【合并edits和fsimage】一小时或者edits记录的操作数达到100W次【可以自定义】），将edits.log合并成fsimage，在合并的过程中NN并不会下线，2NN在后台默默的工作，合并完成之后，将合并好的文件（fsimage.chkpoint）通过TCP发送给NN，这就是2NN的作用。

        NN将edits.log发送给2NN时，NN仍然在继续工作，会产生新的edits.log，这也是2NN不能做NN