“无意中发现了一个巨牛的人工智能教程，忍不住分享一下给大家。教程不仅是零基础，通俗易懂，而且非常风趣幽默，像看小说一样！觉得太牛了，所以分享给大家。点这里可以跳转到教程。”。
HDFS面试题目录
1. HDFS 中的block 默认保存几份？
2. HDFS 默认BlockSize
3. Client 端上传文件的时候下列哪项正确
4. 下面哪个程序负责HDFS 数据存储？
5. 关于SecondaryNameNode 哪项是正确的？
6. 下列哪个程序通常与NameNode 在一个节点启动？
7. 文件大小默认为64M，改为128M 有啥影响？
8. HDFS 的存储机制（☆☆☆☆☆）
9.secondary namenode 工作机制（☆☆☆☆☆）
10. NameNode 与SecondaryNameNode 的区别与联系？
11. hadoop 节点动态上线下线怎么操作?
12. HDFS 整体架构介绍
13. namenode 内存包含哪些，具体如何分配
14. HAnamenode 是如何工作的? （☆☆☆☆☆）
15. namenode ha 高可用源码实现方式
16. hadoop2.x Federation
17. HDFS Federation 的原理结构
18. HDFS Federation 方案的优势
19. hadoop 的块大小，从哪个版本开始是128M
20. HDFS文件上传原理说明
1. HDFS 中的block 默认保存几份？（A）
A.3 份
B.2 份
C.1 份
D.不确定
2. HDFS 默认BlockSize 是（C）
A. 2MB
B. 4MB（2.7.2 版本，本地模式）
C. 8MB（2.7.2 版本，分布式模式）
3. Client 端上传文件的时候下列哪项正确？（BC）
A. 数据经过NameNode 传递DataNode
B. Client 端将文件切分为Block，依次上传
C. Client 只上传数据到一台DataNode，然后由NameNode 负责Block 复制工作
4. 下面哪个程序负责HDFS 数据存储？（C）
A.NameNode
B.JobTracker
C.DataNode
D.SecondaryNameNode
E.tasktracker
5. 关于SecondaryNameNode 哪项是正确的？（C）
A. 它是NameNode 的热备
B. 它对内存没有要求
C. 他的目的使帮助NameNode 合并编辑日志，减少NameNode 启动时间
D. SecondaryNameNode 应与NameNode 部署到一个节点
6. 下列哪个程序通常与NameNode 在一个节点启动？（D）
A.SecondaryNameNode
B.DataNode
C.TaskTracker ·
D.JobTracker
hadoop 的集群是基于master/slave 模式，namenode 和jobtracker 属于master，datanode 和
tasktracker 属于slave，master 只有一个，而slave 有多个。
SecondaryNameNode 内存需求和NameNode 在一个数量级上， 所以通常secondary
NameNode（运行在单独的物理机器上）和NameNode 运行在不同的机器上。
JobTracker 对应于NameNode,TaskTracker 对应于DataNode。
DataNode 和NameNode 是针对数据存放来而言的。JobTracker 和TaskTracker 是对于MapReduce 执行而言的。
mapreduce 中几个主要概念，mapreduce 整体上可以分为这么几条执行线索：
jobclient，JobTracker 与TaskTracker。
1） JobClient 会在用户端通过JobClient 类将已经配置参数打包成jar 文件的应用存储到hdfs，并
把路径提交到Jobtracker,然后由JobTracker 创建每一个Task（即MapTask 和
ReduceTask）并将它们分发到各个TaskTracker 服务中去执行。
2） JobTracker 是一master 服务，软件启动之后JobTracker 接收Job，负责调度Job 的每一个子
任务。task 运行于TaskTracker 上，并监控它们，如果发现有失败的task 就重新运行它。一般情况
应该把JobTracker 部署在单独的机器上。
3） TaskTracker 是运行在多个节点上的slaver 服务。TaskTracker 主动与JobTracker
通信，接收作业，并负责直接执行每一个任务。TaskTracker 都需要运行在HDFS 的DataNode 上。
7. 文件大小默认为64M，改为128M 有啥影响？
增加文件块大小，需要增加磁盘的传输速率。
8. 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 为单位接收，先在本地缓存，然后写入目标文件。
9.secondary namenode 工作机制（☆☆☆☆☆）
1） 第一阶段：namenode 启动
（1） 第一次启动namenode 格式化后，创建fsimage 和edits 文件。如果不是第一次启动，直接
加载编辑日志和镜像文件到内存。
（2） 客户端对元数据进行增删改的请求
（3） namenode 记录操作日志，更新滚动日志。
（4） namenode 在内存中对数据进行增删改查
2） 第二阶段：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
10. NameNode 与SecondaryNameNode 的区别与联系？（☆☆☆)
1） 机制流程同上；
2） 区别
（1） NameNode 负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。
（2） SecondaryNameNode 主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。
3） 联系：
（1） SecondaryNameNode 中保存了一份和namenode 一致的镜像文件（fsimage）和编辑日志（edits）。
（2） 在主namenode 发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
11. hadoop 节点动态上线下线怎么操作?
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 文件中移除。
12. HDFS 整体架构介绍
13. namenode 内存包含哪些，具体如何分配
NameNode 整个内存结构大致可以分成四大部分： Namespace 、BlocksMap 、NetworkTopology 及其它，图2 为各数据结构内存逻辑分布图示。
1） Namespace：维护整个文件系统的目录树结构及目录树上的状态变化；
2） BlockManager：维护整个文件系统中与数据块相关的信息及数据块的状态变化；
3） NetworkTopology：维护机架拓扑及DataNode 信息，机架感知的基础；
4） 其它：
LeaseManager： 读写的互斥同步就是靠Lease 实现，支持HDFS 的Write-Once-Read-Many的核心数据结构；
CacheManager： Hadoop 2.3.0 引入的集中式缓存新特性，支持集中式缓存的管理，实现memory-locality 提升读性能；
SnapshotManager： Hadoop 2.1.0 引入的Snapshot 新特性，用于数据备份、回滚，以防止因用户误操作导致集群出现数据问题；
DelegationTokenSecretManager： 管理HDFS 的安全访问； 另外还有临时数据信息、统计信息metrics等等。
NameNode : 常驻内存主要被Namespace 和BlockManager 使用，二者使用占比分别接近50%。其它部分内存开销较小且相对固定，与Namespace 和BlockManager 相比基本可以忽略。
14. HAnamenode 是如何工作的? （☆☆☆☆☆）
ZKFailoverController 主要职责
1） 健康监测：周期性的向它监控的NN 发送健康探测命令，从而来确定某个NameNode 是否处于健康状态，如果机器宕机，心跳失败，那么zkfc 就会标记它处于一个不健康的状态。
2） 会话管理：如果NN 是健康的，zkfc 就会在zookeeper 中保持一个打开的会话，如果NameNode同时还是Active 状态的，那么zkfc 还会在Zookeeper 中占有一个类型为短暂类型的znode，当这个NN 挂掉时，这个znode 将会被删除，然后备用的NN，将会得到这把锁， 升级为主NN，同时标记状态为Active。
3） 当宕机的NN 新启动时，它会再次注册zookeper，发现已经有znode 锁了，便会自动变为Standby 状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置2 个NN。
4） master 选举：如上所述，通过在zookeeper 中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode 为Active 状态
15. namenode ha 高可用源码实现方式
1） HealthMonitor 初始化完成后通过内部线程调用NameNode 的RPC 接口对其进行健康检查
2） 如果检查到NameNode 状态异常,会回调ZKFailoverContorller 注册的回调函数进行相应的处理
3） 如果ZKFailoverController 发现集群需要进行主备选举， 会使用ActiveStanbyElector 和zookeeper 集群通信完成主备切换
4） ActiveStanbyElector 在完成主备切换后，回调ZKFailoverController 注册的方法使NameNode 变成active 或者stanby 状态
16. hadoop2.x Federation
单Active NN 的架构使得HDFS 在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN 进程使用的内存可能会达到上百G，NN 成为了性能的瓶颈常用的估算公式为1G 对应1 百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)为了解决这个问题,Hadoop 2.x 提供了HDFS Federation, 示意图如下：
多个NN 共用一个集群里的存储资源，每个NN 都可以单独对外提供服务每个NN 都会定义一个存储池，有单独的id，每个DN 都为所有存储池提供存储。DN 会按照存储池id 向其对应的NN 汇报块信息，同时，DN 会向所有NN 汇报本地存储可用资源情况。如果需要在客户端方便的访问若干个NN 上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN 上必须存在相应的目录。
17. HDFS Federation 的原理结构
HDFS Federation 意味着在集群中将会有多个namenode/namespace,这样的方式有什么好处呢?
多namespace 的方式可以直接减轻单一NameNode 的压力。一个典型的例子就是上面提到的NameNode 内存过高问题,我们完全可以将上面部分大的文件目录
移到另外一个NameNode 上做管理.更重要的一点在于，这些NameNode 是共享集群中所有的DataNode 的，它们还是在同一个集群内的。HDFS Federation 原理结构图如下:
我们可以拿这种图与上一小节的图做对比，我们可以得出这样一个结论:
HDFS Federation 是解决NameNode 单点问题的水平横向扩展方案。
这时候在DataNode 上就不仅仅存储一个Block Pool 下的数据了，而是多个(大家可以在DataNode的datadir 所在目录里面查看BP-xx.xx.xx.xx 打头的目录)。
在HDFS Federation 的情况下，只有元数据的管理与存放被分隔开了，但真实数据的存储还是共用的，这与viewFs 还是不一样的。之前看别的文章在讲述HDFS Federation 的时候直接拿viewFs 来讲，个人觉得二者还是有些许的不同的，用一句话概况应该这么说。HDFS 的viewFs 是namespace 完全独立( 私人化)的Federation 方案， 可以这么说， viewFs 是Federation 的一个简单实现方案。因为它们不仅仅是namespace 独立，而且真实数据的存放也是独立的,也就是多个完全独立的集群。在这点上我们还是有必要做一下区分，否则让人以为HDFS Federation 就是viewFs。
18. HDFS Federation 方案的优势
第一点,命名空间的扩展。因为随着集群使用时间的加长，HDFS 上存放的数据也将会越来越多。这个时候如果还是将所有的数据都往一个NameNode 上存放,这个文件系统会显得非常的庞大。这时候我们可以进行横向扩展，把一些大的目录分离出去.使得每个NameNode 下的数据看起来更加的精简。
第二点,性能的提升.这个也很好理解。当NameNode 所持有的数据量达到了一个非常大规模的量级的时候(比如超过1 亿个文件)，这个时候NameNode 的处理效率可能就会有影响，它可能比较容易的会陷入一个繁忙的状态。而整个集群将会受限于一个单点NameNode 的处理效率,从而影响集群整体的吞吐量。这个时候多NameNode 机制显然可以减轻很多这部分的压力。
第三点,资源的隔离。 这一点考虑的就比较深了。通过多个命名空间，我们可以将关键数据文件目录移到不同的NameNode 上，以此不让这些关键数据的读写操作受到其他普通文件读写操作的影响。也就是说这些NameNode 将会只处理特定的关键的任务所发来的请求， 而屏蔽了其他普通任务的文件读写请求，以此做到了资源的隔离。千万不要小看这一点，当你发现NameNode 正在处理某个不良任务的大规模的请求操作导致响应速度极慢时，你一定会非常的懊恼。
19. hadoop 的块大小，从哪个版本开始是128M
Hadoop1.x 都是64M，hadoop2.x 开始都是128M。
20. HDFS文件上传原理说明
- 客户端要上传文件到HDFS中 , 携带自定义的配置参数(副本的个数,物理切块…)请求namenode节点上传数据
- namenode接收到客户端的上传请求会校验权限和检查datanode节点的存储能力,如果正常返回OK
- 客户端根据自己物理块的大小,请求上传第一块数据,namenode就会返回3个副本存储在的3个主机名
- 客户端和返回的3台主机建立连接通道
- 客户端选择一台最近的机器开始上传数据 , 数据以数据包的形式在网络之间传输
- datanode是正正存储数据的节点, 接收客户端的上传数据请求 ,然后将数据存储在指定配置的目录下
- 同时将数据一次发送到通道的另外两台节点机器
- 注意: 只要上图中的lx1 的数据存储成功这次上传就是成功, namenode更新元数据信息 如果通道中的lx2或者lx3中的数据没有同成功, 后续的namenode会创建同步任务放在队列汇总等待节点领取任务复制数据,维护副本个数
