|
Hadoop 集群中有两种节点，一种是namenode，还有一种是datanode。 其中datanode主要负责数据的存储，namenode主要负责三个功能，分别是(1)管理元数据 (2)维护目录树 (3)响应客户请求 首先介绍下，元数据格式
hdfs在外界看来就是普通的文件系统，可以通过路径进行数据的访问等操作，但在实际过程存储中，却是分布在各个节点上。如上图所示，是一条元数据，/test/a.log 是在hdfs文件系统中的路径，3是这个文件的副本数(副本数可以通过在配置文件中的配置来修改的)。在hdfs中，文件是进行分块存储的，如果文件过大，就要分成多块存储，每个块在文件系统中存储3个副本，以上图为例，就是分成blk_1和blk_2两个块，每个块在实际的节点中有3个副本，比如blk_1的3个副本分别存储在h0，h1，h3中。 现在由此引出一个问题，namenode中的元数据是存储在哪里的？首先，我们做个假设，如果存储在namenode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断点，元数据丢失，整个集群就无法工作了！！！因此必须在磁盘中有备份，在磁盘中的备份就是fsImage，存放在namenode节点对应的磁盘中。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新fsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦namenode节点断点，就会产生数据丢失。因此，引入edits.log文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到edits.log中。这样，一旦namenode节点断电，可以通过fsImage和edits.log的合并，合成元数据。但是，如果长时间添加数据到edit.log中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行fsImage和edits.log的合并，如果这个操作有namenode节点完成，又会效率过低。因此，引入一个新的节点secondaryNamenode，专门用于fsImage和edits.log的合并。 检查点处理过程的具体步骤如下 1)namenode节点每隔一定时间请求secondaryNamenode合并操作 2)secondaryNamenode请求namenode进行edits.log的滚动，这样新的编辑操作就能够进入新的文件中 3)secondaryNamenode从namenode中下载fsImage和edits.log 4)secondaryNamenode进行fsImage和edits.log的合并,成为fsImage.checkpoint文件 5)namenode下载合并后的fsImage.checkpoin文件 6)将fsImage.checkpoint和edits.new命名为原来的文件名(这样之后fsImage和内存中的元数据只差edits.new) 具体的过程如下图所示
|
|
|
