大数据面试题(一):HDFS核心高频面试题

举报
Lansonli 发表于 2022/12/12 21:38:10 2022/12/12
【摘要】 ​HDFS核心高频面试题一、HDFS的存储机制(读写流程)HDFS存储机制,包括HDFS的写入过程和读取过程两个部分​1)客户端向namenode请求上传文件,namenode检查目标文件是否已存在,父目录是否存在。2)namenode返回是否可以上传。3)客户端请求第一个 block上传到哪几个datanode服务器上。4)namenode返回3个datanode节点,分别为dn1、dn2...

​HDFS核心高频面试题

一、HDFS的存储机制(读写流程)

HDFS存储机制,包括HDFS的写入过程和读取过程两个部分

1)客户端向namenode请求上传文件,namenode检查目标文件是否已存在,父目录是否存在。

2)namenode返回是否可以上传。

3)客户端请求第一个 block上传到哪几个datanode服务器上。

4)namenode返回3个datanode节点,分别为dn1、dn2、dn3。

5)客户端请求dn1上传数据,dn1收到请求会继续调用dn2,然后dn2调用dn3,将这个通信管道建立完成。

6)dn1、dn2、dn3逐级应答客户端

7)客户端开始往dn1上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,dn1

收到一个packet就会传给dn2,dn2传给dn3;dn1每传一个packet会放入一个应答队列等待应答

8)当一个block传输完成之后,客户端再次请求namenode上传第二个block的服务器。(重复执行3-7步)

1)客户端向namenode请求下载文件,namenode通过查询元数据,找到文件块所在的datanode地址。

2)挑选一台datanode(就近原则,然后随机)服务器,请求读取数据。

3)datanode开始传输数据给客户端(从磁盘里面读取数据放入流,以packet为单位来做校验)。

4)客户端以packet为单位接收,先在本地缓存,然后写入目标文件。


二、SecondaryNameNode 工作机制

第一阶段:namenode启动

1、第一次启动namenode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。

2、客户端对元数据进行增删改的请求

3、namenode记录操作日志,更新滚动日志。

4、namenode在内存中对数据进行增删改查

第二阶段:Secondary NameNode工作

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

2、Secondary NameNode请求执行checkpoint。

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

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

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

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

7、拷贝fsimage.chkpoint到namenode

8、namenode将fsimage.chkpoint重新命名成fsimage


三、NameNode与SecondaryNameNode 的区别与联系

区别:

  1. NameNode负责管理整个文件系统的元数据,以及每一个路径(文件)所对应的数据块信息。
  2. SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。

联系:

  1. SecondaryNameNode中保存了一份和namenode一致的镜像文件(fsimage)和编辑日志(edits)。
  2. 在主namenode发生故障时(假设没有及时备份数据),可以从SecondaryNameNode恢复数据。


四、服役新数据节点和退役旧节点步骤

1、节点上线操作

当要新上线数据节点的时候,需要把数据节点的名字追加在 dfs.hosts 文件中

  1. 关闭新增节点的防火墙
  2. 在 NameNode 节点的 hosts 文件中加入新增数据节点的 hostname
  3. 在每个新增数据节点的 hosts 文件中加入 NameNode 的 hostname
  4. 在 NameNode 节点上增加新增节点的 SSH 免密码登录的操作
  5. 在 NameNode 节点上的 dfs.hosts 中追加上新增节点的 hostname,
  6. 在其他节点上执行刷新操作:hdfs dfsadmin -refreshNodes
  7. 在 NameNode 节点上,更改 slaves 文件,将要上线的数据节点 hostname 追加到 slaves 文件中
  8. 启动 DataNode 节点
  9. 查看 NameNode 的监控页面看是否有新增加的节点


2、节点下线操作

  1. 修改/conf/hdfs-site.xml 文件
  2. 确定需要下线的机器,dfs.osts.exclude 文件中配置好需要下架的机器,这个是阻止下架的机器去连接 NameNode。
  3. 配置完成之后进行配置的刷新操作./bin/hadoop dfsadmin -refreshNodes,这个操作的作用是在后台进行 block 块的移动。
  4. 当执行三的命令完成之后,需要下架的机器就可以关闭了,可以查看现在集群上连接的节点,正在执行 Decommission,会显示:Decommission Status : Decommission in progress 执行完毕后,会显示: Decommission Status : Decommissioned
  5. 机器下线完毕,将他们从excludes 文件中移除。


五、Namenode挂了怎么办

方法一:将SecondaryNameNode中数据拷贝到namenode存储数据的目录;

方法二:使用-importCheckpoint选项启动namenode守护进程,从而将SecondaryNameNode中数据拷贝到namenode目录中。


六、详细介绍Namenode HA

 HA(High Available), 高可用,是保证业务连续性的有效解决方案,一般有两个或两个以上的节点,分为 活动节点 ( Active )及 备用节点 ( Standby) )。用于实现业务的不中断或短暂中断

NN 是 HDFS 集群的单点故障点.在 HA 具体实现方法不同情况下,HA 框架的流程是一致的, 不一致的就是如何存储、管理、同步 edits 编辑日志文件。

QJM/Qurom Journal Manager,基本原理就是用 2N+1 台 JournalNode 存储 EditLog,每次写数据操作有>=N+1 返回成功时即认为该次写成功,数据不会丢失了

在 HA 模式下,datanode 需要确保同一时间有且只有一个 NN 能命令 DN。

FailoverController 主要包括三个组件:

HealthMonitor: 监控 NameNode 是否处于 unavailable 或 unhealthy 状态。当前通过RPC 调用 NN 相应的方法完成。

ActiveStandbyElector: 监控 NN 在 ZK 中的状态。

ZKFailoverController: 订阅 HealthMonitor 和 ActiveStandbyElector 的事件,并管理 NN 的状态,另外 zkfc还负责解决 fencing(也就是脑裂问题)。

ZKFailoverController 主要职责:

健康监测:周期性的向它监控的 NN 发送健康探测命令,从而来确定某个 NameNode是否处于健康状态,如果机器宕机,心跳失败,那么 zkfc 就会标记它处于一个不健康的状态

会话管理:如果 NN 是健康的,zkfc 就会在 zookeeper 中保持一个打开的会话,如果 NameNode 同时还是Active 状态的,那么 zkfc 还会在 Zookeeper 中占有一个类型为短暂类型的 znode,当这个 NN 挂掉时,这个znode 将会被删除,然后备用的NN 将会得到这把锁,升级为主 NN,同时标记状态为 Active

当宕机的 NN 新启动时,它会再次注册 zookeper,发现已经有 znode 锁了,便会自动变为 Standby 状态, 如此往复循环,保证高可靠,需要注意,目前仅仅支持最多配置 2 个 NN

master 选举:通过在 zookeeper 中维持一个短暂类型的 znode,来实现抢占式的锁机制,从而判断那个NameNode 为 Active 状态

七、详细介绍Yarn HA


Hadoop 2.4.0版本开始,Yarn 实现了 ResourceManager HA

由于资源使用情况和 NodeManager 信息都可以通过 NodeManager 的心跳机制重新构建出来,因此只需要对 ApplicationMaster 相关的信息进行持久化存储即可。

在一个典型的 HA 集群中,两台独立的机器被配置成 ResourceManger。在任意时间,有且只允许一个活动的 ResourceManger,另外一个备用。切换分为两种方式:

手动切换:在自动恢复不可用时,管理员可用手动切换状态,或是从 Active 到 Standby,或是从 Standby 到 Active。

自动切换:基于 Zookeeper,但是区别于 HDFS 的 HA,2 个节点间无需配置额外的 ZFKC守护进程来同步数据。


八、单点故障与”脑裂” 


九、Client的事务性操作对HA提供了支持


十、Hadoop的namenode宕机怎么解决

先分析宕机后的损失,宕机后直接导致client无法访问,内存中的元数据丢失,但是硬盘中的元数据应该还存在, 如果只是节点挂了,重启即可,如果是机器挂了,重启机器后看节点是否能重启,不能重启就要找到原因修复了。 

但是最终的解决方案应该是在设计集群的初期就考虑到这个问题,做namenode的HA。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。