1.2HDFS（☆☆☆）
1.2.1 HDFS 中的 block 默认保存几份？（A）
A.3 份
B.2 份
C.1 份
D.不确定
1.2.2HDFS 默认 BlockSize 是（C）
A.32MB
B.64MB（2.7.2版本，本地模式）
C.128MB（2.7.2版本，分布式模式）
1.2.3 Client 端上传文件的时候下列哪项正确？（BC）
A.数据经过NameNode传递DataNode
B.Client端将文件切分为Block，依次上传
C.Client只上传数据到一台DataNode，然后由NameNode负责Block复制工作
1.2.4 下面哪个程序负责 HDFS 数据存储？（C）
A.NameNode
B.JobTracker
C.DataNode
D.SecondaryNameNode
E.tasktracker
1.2.5 关于SecondaryNameNode 哪项是正确的？（C）
A.它是NameNode的热备
B.它对内存没有要求
C.他的目的使帮助NameNode合并编辑日志，减少NameNode 启动时间
D.SecondaryNameNode应与NameNode 部署到一个节点
1.2.6 （X）下列哪个程序通常与 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上。 |
1.2.7 文件大小默认为 64M，改为 128M 有啥影响？
增加文件块大小，需要增加磁盘的传输速率。
1.2.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为单位接收，先在本地缓存，然后写入目标文件。
1.2.9 secondarynamenode工作机制（☆☆☆☆☆）
1）第一阶段：namenode启动
（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（2）客户端对元数据进行增删改的请求
（3）namenode记录操作日志，更新滚动日志。
（4）namenode在内存中对数据进行增删改查
2）第二阶段：Secondary NameNode工作
（1）SecondaryNameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。
（2）SecondaryNameNode请求执行checkpoint。
（3）namenode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）SecondaryNameNode加载编辑日志和镜像文件到内存，并合并。
（6）生成新的镜像文件fsimage.chkpoint
（7）拷贝fsimage.chkpoint到namenode
（8）namenode将fsimage.chkpoint重新命名成fsimage
1.2.10 NameNode与SecondaryNameNode 的区别与联系？（☆☆☆☆☆）
1）机制流程同上；
2）区别
（1）NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。
（2）SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。
3）联系：
（1）SecondaryNameNode中保存了一份和namenode一致的镜像文件（fsimage）和编辑日志（edits）。
（2）在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据。
1.2.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 文件中移除。
1.2.12 hdfs整体架构介绍
1.2.13 （X）namenode内存包含哪些，具体如何分配
NameNode整个内存结构大致可以分成四大部分：Namespace、BlocksMap、NetworkTopology及其它，图2为各数据结构内存逻辑分布图示。
图2 NameNode内存全景图
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相比基本可以忽略。
详见：http://blog.csdn.net/guohecang/article/details/52356748
1.2.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状态
1.2.15namenode ha高可用源码实现方式
1）HealthMonitor初始化完成后通过内部线程调用NameNode的RPC接口对其进行健康检查
2）如果检查到NameNode状态异常,会回调ZKFailoverContorller注册的回调函数进行相应的处理
3）如果ZKFailoverController发现集群需要进行主备选举，会使用ActiveStanbyElector和zookeeper集群通信完成主备切换
4）ActiveStanbyElector在完成主备切换后，回调ZKFailoverController注册的方法使NameNode变成active或者stanby状态
1.2.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上必须存在相应的目录。
1.2.17 HDFSFederation的原理结构
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还是不一样的。之前看别的文章在讲述HDFSFederation的时候直接拿viewFs来讲，个人觉得二者还是有些许的不同的，用一句话概况应该这么说。
HDFS的viewFs是namespace完全独立(私人化)的Federation方案，可以这么说，viewFs是Federation的一个简单实现方案。
因为它们不仅仅是namespace独立，而且真实数据的存放也是独立的,也就是多个完全独立的集群。在这点上我们还是有必要做一下区分，否则让人以为HDFSFederation就是viewFs。
1.2.18 HDFSFederation方案的优势
第一点,命名空间的扩展。因为随着集群使用时间的加长，HDFS上存放的数据也将会越来越多。这个时候如果还是将所有的数据都往一个NameNode上存放,这个文件系统会显得非常的庞大。这时候我们可以进行横向扩展，把一些大的目录分离出去.使得每个NameNode下的数据看起来更加的精简。
第二点,性能的提升.这个也很好理解。当NameNode所持有的数据量达到了一个非常大规模的量级的时候(比如超过1亿个文件)，这个时候NameNode的处理效率可能就会有影响，它可能比较容易的会陷入一个繁忙的状态。而整个集群将会受限于一个单点NameNode的处理效率,从而影响集群整体的吞吐量。这个时候多NameNode机制显然可以减轻很多这部分的压力。
第三点,资源的隔离。这一点考虑的就比较深了。通过多个命名空间，我们可以将关键数据文件目录移到不同的NameNode上，以此不让这些关键数据的读写操作受到其他普通文件读写操作的影响。也就是说这些NameNode将会只处理特定的关键的任务所发来的请求，而屏蔽了其他普通任务的文件读写请求，以此做到了资源的隔离。千万不要小看这一点，当你发现NameNode正在处理某个不良任务的大规模的请求操作导致响应速度极慢时，你一定会非常的懊恼。
1.2.19 hadoop的块大小，从哪个版本开始是128M
Hadoop1.x都是64M，hadoop2.x开始都是128M。