hadoop namenode的工作机制

Posted 2021-03-14 zourui4271

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)

具体的过程如下图所示

 

 

 

 

================================================

namenode的fsimage与editlog详解

Namenode主要维护两个文件，一个是fsimage，一个是editlog。

fsimage保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。

editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录，HDFS客户端执行所有的写操作都会被记录到editlog中。

 

简单来想，NameNode维护了文件与数据块的映射表以及数据块与数据节点的映射表，什么意思呢？就是一个文件，它切分成了几个数据块，以及这些数据块分别存储在哪些datanode上，namenode一清二楚。Fsimage就是在某一时刻，整个hdfs 的快照，就是这个时刻hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，各自的副本个数。然后客户端对hdfs所有的更新操作，比如说移动数据，或者删除数据，都会记录在editlog中。

 

为了避免editlog不断增大，secondary namenode会周期性合并fsimage和edits成新的fsimage，新的操作记录会写入新的editlog中，这个周期可以自己设置（editlog到达一定大小或者定时）。

 

 

可以很清晰看出，第一步：将hdfs更新记录写入一个新的文件——edits.new。

第二步：将fsimage和editlog通过http协议发送至secondary namenode。

第三步：将fsimage与editlog合并，生成一个新的文件——fsimage.ckpt。这步之所以要在secondary namenode中进行，是因为比较耗时，如果在namenode中进行，或导致整个系统卡顿。

第四步：将生成的fsimage.ckpt通过http协议发送至namenode。

第五步：重命名fsimage.ckpt为fsimage，edits.new为edits。

 

这样的话，fsimage与editlog合并的过程就完成了。所以如果namenode宕机，其实secondary namenode还保存这一份不久前的fsimage，还能挽回一些损失吧。

 

另外上篇中说，一旦有datanode挂掉了（宕机或者是网络阻塞），namenode能很快感知到，并且将宕机的节点上的数据块转移至其余空闲节点。这点是因为hdfs中心跳机制（heartbeat）。

心跳机制默认3s中一次，datanode会向namenode发送一次一跳，告知namenode当前节点上存放的数据文件是什么。如果namenode中记录的是该datanode存放了文件A的两个数据块和文件B的一个数据块，但是心跳中只有文件A的一个数据块信息，namenode就会知道该datanode数据块损坏了，会把损坏的数据块在别的datanode上补充。

转载自：namenode的fsimage与editlog详解

==========================================

接下来详细介绍HDFS读写数据的流程，以及一致性模型相关的一些概念。

7.1 读文件

大致读文件的流程如下：

1）客户端传递一个文件Path给FileSystem的open方法

2）DFS采用RPC远程获取文件最开始的几个block的datanode地址。Namenode会根据网络拓扑结构决定返回哪些节点（前提是节点有block副本），如果客户端本身是Datanode并且节点上刚好有block副本，直接从本地读取。

3）客户端使用open方法返回的FSDataInputStream对象读取数据（调用read方法）

4）DFSInputStream（FSDataInputStream实现了改类）连接持有第一个block的、最近的节点，反复调用read方法读取数据

5）第一个block读取完毕之后，寻找下一个block的最佳datanode，读取数据。如果有必要，DFSInputStream会联系Namenode获取下一批Block 的节点信息(存放于内存，不持久化），这些寻址过程对客户端都是不可见的。

6）数据读取完毕，客户端调用close方法关闭流对象

在读数据过程中，如果与Datanode的通信发生错误，DFSInputStream对象会尝试从下一个最佳节点读取数据，并且记住该失败节点， 后续Block的读取不会再连接该节点 
读取一个Block之后，DFSInputStram会进行检验和验证，如果Block损坏，尝试从其他节点读取数据，并且将损坏的block汇报给Namenode。 
客户端连接哪个datanode获取数据，是由namenode来指导的，这样可以支持大量并发的客户端请求，namenode尽可能将流量均匀分布到整个集群。 
Block的位置信息是存储在namenode的内存中，因此相应位置请求非常高效，不会成为瓶颈。

7.2 写文件

步骤分解 
1）客户端调用DistributedFileSystem的create方法

2）DistributedFileSystem远程RPC调用Namenode在文件系统的命名空间中创建一个新文件，此时该文件没有关联到任何block。 这个过程中，Namenode会做很多校验工作，例如是否已经存在同名文件，是否有权限，如果验证通过，返回一个FSDataOutputStream对象。 如果验证不通过，抛出异常到客户端。

3）客户端写入数据的时候，DFSOutputStream分解为packets，并写入到一个数据队列中，该队列由DataStreamer消费。

4）DateStreamer负责请求Namenode分配新的block存放的数据节点。这些节点存放同一个Block的副本，构成一个管道。 DataStreamer将packer写入到管道的第一个节点，第一个节点存放好packer之后，转发给下一个节点，下一个节点存放 之后继续往下传递。

5）DFSOutputStream同时维护一个ack queue队列，等待来自datanode确认消息。当管道上的所有datanode都确认之后，packer从ack队列中移除。

6）数据写入完毕，客户端close输出流。将所有的packet刷新到管道中，然后安心等待来自datanode的确认消息。全部得到确认之后告知Namenode文件是完整的。 Namenode此时已经知道文件的所有Block信息（因为DataStreamer是请求Namenode分配block的），只需等待达到最小副本数要求，然后返回成功信息给客户端。

Namenode如何决定副本存在哪个Datanode？

HDFS的副本的存放策略是可靠性、写带宽、读带宽之间的权衡。默认策略如下：

• 第一个副本放在客户端相同的机器上，如果机器在集群之外，随机选择一个（但是会尽可能选择容量不是太慢或者当前操作太繁忙的）
• 第二个副本随机放在不同于第一个副本的机架上。
• 第三个副本放在跟第二个副本同一机架上，但是不同的节点上，满足条件的节点中随机选择。
• 更多的副本在整个集群上随机选择，虽然会尽量便面太多副本在同一机架上。 
  副本的位置确定之后，在建立写入管道的时候，会考虑网络拓扑结构。下面是可能的一个存放策略：

这样选择很好滴平衡了可靠性、读写性能

• 可靠性：Block分布在两个机架上
• 写带宽：写入管道的过程只需要跨越一个交换机
• 读带宽：可以从两个机架中任选一个读取

 ========================================

HDFS写流程中，如果某个DataNode挂掉了，会怎么处理？

在写入的时候不会重新重新分配datanode。 如果写入时，一个datanode挂掉，会将已经写入的数据放置到queue的顶部，并将挂掉的datanode移出pipline，讲数据写入到剩余的datanode.在写入结束后， namenode会收集datanode的信息，发现此文件的replication没有达到配置的要求（default=3）,然后寻找一个datanode保存副本。