Hadoop必知必会——重要部分整理

Posted 2021-07-24 Z-hhhhh

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Hadoop必知必会——重要部分整理相关的知识，希望对你有一定的参考价值。

一、HDFS在读文件时，如果一个块突然坏了

客户端读取完DataNode上的块之后会进行checksum验证，就是把客户端读取到本地的块与HDFS上的原始块进行校验，如果发现校验结果不一致，客户端会通知通知NameNode，然后再从下一个拥有该block副本的DataNode继续读。

二、HDFS在上传文件的时候，如果其中一个DataNode突然挂掉了

客户端上传文件时与DataNode建立pipeline管道，管道正是向客户端DataNode发送的数据包，管道反向时，向DataNode向客户端发送ack确认，也就是正确接收到数据包之后发送一个已确认接受的应答，当DataNode突然挂掉，客户端接收不到这个DataNode发送的ack确认，客户端会通知NameNode,NameNode检查该块的副本与规定不符，NameNode会通知DataNode去复制副本，并讲挂掉的DataNode做下线处理，不让其再参与文件的上传与下载。

三、NameNode在启动时会做哪些操作

NameNode 数据存储在内存和本地磁盘，本地磁盘数据储存在fsimage镜像文件和edits编辑日志文件

首次启动

1、格式化文件系统，生成fsimage镜像文件

2、启动NameNode

读取fsimage文件，将文件内容加载到内存

等待DataNode注册与发送block report

3、启动DataNode

向NameNode注册

发送block report

检查fsimage 中记录的块的数量和block report中的快的总是是否相同

4、对文件系统进行操作(创建目录，上传文件，删除文件等)

此时内存中已经有文件系统改变的信息，但是磁盘中没有文件系统改变的信息，此时会将这些改变信息写入edits文件中，edits文件中存储的是文件系统元数据改变的信息

第二次启动NameNode

去读fsimage和edits文件

将fsimage和edits文件合并成新的fsimage文件

创建新的edits文件，内容为空

启动DataNode

四、Secondary NameNode工作机制

Secondary NameNode是合并NameNode的edits logs到fsimage文件中具体如下：

1、Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果

2、Secondary NameNode请求执行chekpoint

3、NameNode滚动正在写的edits日志

4、将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

5、Secondary NameNode加载编辑日志和镜像文件到内存，并合并

6、生成新的镜像文件fsimage.chkpoint

7、拷贝到fsimage.chkpoint 到 NameNode

8、NameNode将fsimage.chkpoint重命名为fsimage

所以如果NameNode 中的元数据丢失，是可以从Secondary NameNode 恢复一部分元数据信息的，但不是全部，因为NameNode 正在写的edits 日志还没有拷贝到Secondary NameNode，这部分恢复不了。

五、Secondary NameNode 不能恢复NameNode 的全部数据，那如何保证NameNode 数据存储安全

NameNode具有高可用，就是NameNode HA

当一个NameNode有单点故障问题，那就配置双NameNode。一、必须要保证两个NN的元数据信息保持同步，二、当一个NN挂掉之后，另外一个立刻补上

一、为了保证两个NN数据同步，采用的是"共享存储"。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份NN从共享存储同步日志，这样就能保证两个NN的切换

二、zookeeper对NN进行监控，两个NN 节点分别有一个进程监控程序，实施读取ZK 中有NN 的状态，来判断当前的NN 是不是已经down 机。如果standby 的NN 节点的ZKFC 发现主节点已经挂掉，那么就会强制给原本的active NN 节点发送强制关闭请求，之后将备用的NN 设置为active。

六、NameNode HA中是否会出现脑裂，怎么解决脑裂

(假设NameNode1 当前为Active 状态，NameNode2 当前为Standby 状态。如果某一时刻NameNode1 对应的ZKFailoverController 进程发生了“假死”现象，那么Zookeeper服务端会认为NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代NameNode1 进入Active 状态。但是此时NameNode1 可能仍然处于Active 状态正常运行，这样NameNode1 和NameNode2 都处于Active 状态，都可以对外提供服务。这种情况称为脑裂)

解决

fencing,把旧的Active NameNode隔离起来，使他不能正常对外服务

首先尝试调用这个旧Active NameNode 的HAServiceProtocol RPC 接口的transitionToStandby 方法，看能不能把它转换为Standby 状态。
如果transitionToStandby 方法调用失败，那么就执行Hadoop 配置文件之中预定义的隔离措施，Hadoop 目前主要提供两种隔离措施，通常会选择sshfence：
(1) sshfence：通过SSH 登录到目标机器上，执行命令fuser 将对应的进程杀死
(2) shellfence：执行一个用户自定义的shell 脚本来将对应的进程隔离

七、小文件过多，怎么避免

hadoop上大量HDFS远数据存储在NameNode内存中，因此当小文件过多时，会压垮NameNode的内存。

每个元数据对象约占150byte，所以如果有1 千万个小文件，每个文件占用一个block，则NameNode 大约需要2G 空间。如果存储1 亿个文件，则NameNode需要20G 空间
显而易见的解决这个问题的方法就是合并小文件,可以选择在客户端上传时执行一定的策略先合并,或者是使用Hadoop 的CombineFileInputFormat<K,V>实现小文件的合并