关于HDFS应知应会的N个问题 | 技术点

1. Namenode的安全模式 ？

安全模式是Namenode的一种状态（Namenode主要有active/standby/safemode三种模式）。

 

2. 哪些状况下，Namenode会进入安全模式 ？

a. Namenode发现集群中的block丢失率达到必定比例时（默认0.01%），Namenode就会进入安全模式，在安全模式下，客户端不能对任何数据进行操做，只能查看元数据信息

b. 在hdfs集群正常冷启动时，Namenode也会在safemode状态下维持至关长的一段时间，此时你不须要去理会，等待它自动退出安全模式便可

 

3. 为何，在HDFS集群冷启动时，Namenode会在安全模式下维持至关长的一段时间 ？

Namenode的内存元数据中，包含文件路径、副本数、blockid，及每个block所在Datanode的信息，而fsimage中，不包含block所在的Datanode信息。那么，当Namenode冷启动时，此时内存中的元数据只能从fsimage中加载而来，从而就没有block所在的Datanode信息 ——> 就会致使Namenode认为全部的block都已经丢失 ——> 进入安全模式 ——> 所在的Datanode信息启动后，会按期向Namenode汇报自身所持有的block信息 ——> 随着Datanode陆续启动，从而陆续汇报block信息，Namenode就会将内存元数据中的block所在Datanode信息补全更新 ——> 找到了全部block的位置，从而自动退出安全模式

 

4. 如何退出安全模式 ？

1）找到问题所在，进行修复（好比修复宕机的所在Datanode信息补全更新）

2）能够手动强行退出安全模式：hdfs namenode --safemode leave 【不推荐，毕竟没有真正解决问题】

 

5. Namenode服务器的磁盘故障致使namenode宕机，如何挽救集群及数据 ？

1）HA机制：高可用hadoop2.0
2）配置hdfs-site.xml指定而后重启Namenode运行时数据存放多个磁盘位置
3）而后重启Namenode和SecondaryNamenode的工做目录存储结构彻底相同，固然后重启Namenode故障退出须要从新恢复时，能够从SecondaryNamenode的工做目录存储结构彻底相同，当的工做目录中的namesecondary文件夹及其中文件拷贝到而后重启Namenode所在节点工做目录中(但只能恢复大部分数据SecondaryNamenode最后一次合并以后的更新操做的元数据将会丢失)，将namesecondary重命名为name而后重启Namenode

 

6. Namenode是否能够有多个？Namenode跟集群数据存储能力有关系吗？

1）非HA的模式下Namenode只能有一个，HA模式下能够有两个（一主active一备standby），HDFS联邦机制能够有多个Namenode

2）关系不大，存储数据由Datanode完成。可是药尽可能避免存储大量小文件，由于会耗费Namenode内存

 

7. fsimage是否存放了block所在服务器信息 ？

1）在edits中保存着每一个文件的操做详细信息

2）在fsimage中保存着文件的名字、id、分块、大小等信息，可是不保存Datanode 的IP

3）在hdfs启动时处于安全模式，Datanode 向Namenode汇报本身的IP和持有的block信息

安全模式结束，文件块和Datanode 的IP关联上

验证过程： 1) 启动Namenode，离开safemode，cat某个文件，看log，没有显示文件关联的Datanode 2) 启动Datanode，cat文件，内容显示 3) 中止Datanode ，cat文件，看log，看不到文件，但显示了文件块关联的Datanode

 

8. Datanode动态上下线？

在实际生产环境中，在hdfs-site.xml文件中还会配置以下两个参数：

dfs.hosts：白名单；dfs.hosts.exclude：黑名单

<property> <name>dfs.hosts</name> #完整的文件路径：列出了容许连入NameNode的datanode清单（IP或者机器名） <value>$HADOOP_HOME/conf/hdfs_include</value> </property> <property> <name>dfs.hosts.exclude</name> #文件完整路径：列出了禁止连入NameNode的datanode清单（IP或者机器名） <value>$HADOOP_HOME/conf/hdfs_exclude</value> </property>

1) 上线datanode

a) 保证上线的datanode的ip配置在白名单而且不出如今黑名单中

b) 配置成功上线的datanode后，经过命令hadoop-daemon.sh datanode start启动

c) 刷新节点状态：/bin/hadoop dfsadmin -refreshNodes(这个命令能够动态刷新dfs.hosts和dfs.hosts.exclude配置，无需重启NameNode)

d) 手动进行数据均衡：start-balance.sh

 

2) 下线datanode

a) 保证下线的datanode的ip配置在黑名单而且不出如今白名单中

b) 关闭下线的节点

c) 刷新节点状态：/bin/hadoop dfsadmin -refreshNodes

d) 机器下线完毕后，将它们从hdfs_exclude文件中移除

 

9. 关于Datanode的几个问题 ？

1）Datanode在什么状况下不会备份？

在强制关闭或者非正常断电时不会备份

2）3个Datanode中有一个Datanode出现错误会怎样？

这个Datanode的数据会在其余的Datanode上从新作备份

 

10. HDFS HA机制下的脑裂现象以及避免方法 ？
当standby Namenode的ZKFailoverController收到active Namenode端故障通知时，不会当即将本身的状态切换为active，由于此时active Namenode可能处于“假死”状态，若是即刻切换为active状态，有可能形成脑裂现象。
为了防止脑裂，建议写个脚本确保发出故障通知的active Namenode必定被kill掉，具体能够按照如下几个步骤完成kill操做：
1.执行杀掉active Namenode的shell脚本，等待ssh kill返回命令
2.若是响应成功，就把原standby Namenode的状态切换为active；若是响应失败或者超时（能够配置一个超时时间）
3.只要shell脚本的调用返回值为true，则切换本身端的Namenode状态为active

笔者强调：Namenode主备切换、健康状态监控等须要经过ZKFailoverController等组件实现，但最终会借助于zookeeper集群

 

11. HDFS为何不适合存储小文件 ？

通常一个block对应的元数据大小为150byte左右，大量小文件会使内存中的元数据变大致使占用大量Namenode内存、寻址时间长

 

 

12. 大量小文件的处理方式？

1）打成HAR files
命令：hadoop archive -archiveName xxx.har -p /src /dest
查看内容：hadoop fs -lsr har:///dest/xxx.har

该命令底层其实是运行了一个MapReduce任务来将小文件打包成HAR。可是经过HAR来读取一个文件并不会比直接从HDFS中读取文件高效，由于对每个HAR文件的访问都须要进行index文件和文件自己数据的读取。而且虽然HAR文件能够被用来做为MapReduce任务的input，可是并不能将HAR文件中打包的文件看成一个HDFS文件处理

2）编写MR程序，将小文件序列化到一个Sequence File中

将小文件以文件名做为key，以文件内容做为value，编写一个程序将它们序列化到HDFS上的一个Sequence File中，而后来处理这个Sequence File。相对打成HAR文件，具备两个优点：
（1）Sequence File是可拆分的，所以MapReduce能够将它们分红块并独立地对每一个块进行操做
（2）它们同时支持压缩，不像HAR。在大多数状况下，块压缩是最好的选择，由于它将压缩几个记录为一个块，而不是一个记录压缩一个块

笔者强调hdfs小文件问题要结合具体的处理引擎以及业务状况等，好比离线处理下、流式处理下小文件问题如何解决，以后笔者会开单篇详述

13. 查看HDFS集群工做状态命令 ？

hdfs dfsadmin -report：快速定位各个节点状况，如每一个节点的硬盘使用状况

---

关注微信公众号：大数据学习与分享，获取更对技术干货