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>

<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

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。在大多数状况下，块压缩是最好的抉择，因为它将压缩几个记录为一个块，而不是一个记录压缩一个块

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

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