hadoop知识点汇总

1.HDFS读写流程

参见此篇博客

2.namenode的启动过程
第一次启动:需要格式化nameNode ,创建fsimage,edits，只需要加载fsiamge。
如果不是第一次启动：
　(1)加载镜像文件，还原了checkpoint时间节点前的元数据（包含目录结构，文件大小，块的大小，块的id等等信息），不包含块的存储位置
　(2)加载edits文件，还原了checkpoint时间节点到集群停止的元数据，不包含块的存储位置。（至此namenode还原的元数据唯一缺失的就是块的存储位置）
　(3)blockreport阶段，datanode启动，向namendoe汇报自己所管理的块及块的id，namenode根据块的ID还原块的存储位置
　(4)在blockreport结束后，集群会判断，datanode的启动数量（可设置，默认为0），丢失的块的占比（可设置，默认0.999f）
是否满足退出安装模式的条件，如果满足，30秒后退出安全模式。在安全模式下namenode会删除多余的块
（副本数为3，结果实际存储4个。ps:这种情况发生在datanode宕机，集群把宕机的datanode管理的块进行了复制，而宕机的datanode又重新启动了）
还会复制低于副本数的块。

3.HDFS不适合存储小文件，如果生成场景中还必须将这些小文件进行存储（比如，每天产生的日志，数据量很小，但是必须存储）
HDFS天生就是为存储大文件而生的，一个块的元数据大小大概在150byte左右，存储一个小文件就要占用150byte的内存，如果存储大量的小文件
很快就将内存耗尽，而整个集群存储的数据量很小，失去了HDFS的意义
可以将数据合并上传，或者将文件append形式追加在HDFS文件末尾。或者在inputFormat阶段合并成一个map。

4.什么情况下会进入安全模式，安全模式的解决办法
块的数量低于阀值，datanode启动数量不够都会进入安全模式
(1)调低阀值

hdfs-site.xml中
<name>dfs.namenode.safemode.threshold-pct</name>
<value>0.999f</value>

(2)强制离开
hdfs dfsadmin -safemode leave
(3)重新格式化集群
(4)修复损坏的块文件

5.说一下HDFS的可靠性策略
1）文件完整性
　在文件建立时，每个数据块都产生校验和，校验和会保存在.meta文件内；
　客户端获取数据时可以检查校验和是否相同，从而发现数据块是否损坏；
　如果正在读取的数据块损坏，则可以继续读取其它副本。NameNode标记该块已经损坏，然后复制block达到预期设置的文件备份数；
　DataNode 在其文件创建后三周验证其checksum。
2）网络或者机器失效
　(1)副本冗余
　(2)机架感知策略（副本放置策略）
　(3)心跳机制策略
3）namenode挂掉
　(1)主备切换（高可用）
　(2)镜像文件和操作日志磁盘存储
　(3)镜像文件和操作日志可以存储多份，多磁盘存储
4）其他机制
　(1)快照（和虚拟机快照意义相同，保存了系统某一时刻的影像，可以还原到该时刻）
　(2)回收站机制
　(3)安全模式

6.HDFS的优缺点
HDFS优点
　(1)高容错性：数据自动保存多个副本，副本丢失后，会自动恢复。
　(2)适合批处理：移动计算而非数据、数据位置暴露给计算框架。
　(3)适合大数据处理：GB、TB、甚至PB级数据、百万规模以上的文件数量，1000以上节点规模。
　(4)流式文件访问：一次性写入，多次读取；保证数据一致性。
　(5)可构建在廉价机器上：通过多副本提高可靠性，提供了容错和恢复机制。
HDFS缺点
　(1)低延迟数据访问：比如毫秒级、低延迟与高吞吐率。
　(2)小文件存取：占用NameNode大量内存，寻道时间超过读取时间。
　(3)并发写入、文件随机修改：一个文件只能有一个写者，仅支持append

7.datanode宕机后，集群能否立即将宕机的datanode下线，datanode下线后，集群将进行什么工作。
不能，10分30秒
将复制下线的datanode 管理的块

8.HDFS的设计思想
1)大文件拆成块，分在多台机器上存储（解决处理数据时的IO瓶颈）
2)块均匀分布（解决负载均衡问题）

9.namenode的工作职责，datanode的工作职责
namenode的工作职责
　(1)维护目录结构
　(2)管理元数据
　(3)响应客户端请求
datanode的工作职责
　(1)负责块的存储
　(2)定期向namenode报告块的存储情况

10.将一个集群重新格式化namenode后，使用start-dfs.sh启动集群，datanode能启动起来么？为什么？
不能，namendoe重新格式化后，集群改变了，而datanode还保存着原来的集群。
(如果要想启动,需要把log日志都删了,tmp文件夹里的临时日志也要删了)

11.MR的shuffle流程
参见此篇博客

12.job提交流程
参见此篇博客

13.如何控制MapTask数量，如何控制ReduceTask数量
分片机制如下，一个分片对应一个map，可调整客户端的块大小，minSize，maxSize改变map数量
minSize默认值是1，maxSize默认是long的最大值

protected long computeSplitSize(long blockSize, long minSize,
                                  long maxSize) {
    return Math.max(minSize, Math.min(maxSize, blockSize));
  }

ReduceTask数量是我们通过程序设置的，具体数量根据数据map任务的个数，以及实际集群的情况等综合因素设置（根据业务场景）

14.现块的大小为128M,现在有一文件大小为260M，进行spilt的时候，会被分成几片
2片，1.1的冗余

15.列举MR中可干预的组件（详细说明各组件的原理，ps：combiner）
　inputFormat
　combiner：相当于在map端（每个maptask生成的文件）做了一次reduce
　partition：分区，默认根据key的hash值%reduce的数量，自定义分区是继承Partitioner类，重写getPartition（）分区方法。自定义分区可以有效的解决数据倾斜的问题
　group：分组，继承WritableComparator类，重写compare()方法，自定义分组（就是定义reduce输入的数据分组规则）
　sort：排序，继承WritableComparator类，重写compare()方法，根据自定义的排序方法，将reduce的输出结果进行排序
　分片：可调整客户端的blocksize，minSize，maxSize
　outputFormat

16.两个类TextInputFormat和KeyValueInputFormat的区别是什么？

17.分片与分块的区别？
分片是逻辑概念，分片有冗余
分块是物理概念，是将数据拆分，无冗余

18.AppMaster是属于yarn的进程还是属于MR的进程，AppMaster的生命周期，AppMaster的工作内容（待补充）
AppMaster属于MR的进程

19.resourceManager的工作职责
资源调度
资源监视
application提交

20.NodeManager的工作职责
主要是节点上的资源管理，启动Container运行task计算，上报资源、container情况给RM和任务处理情况给AM。

21.zookeeper的应用场景
统一的命名空间
共享配置
分布式锁
解决单点故障

22.阐述zookeeper分布式锁的实现原理
在zk上创建永久节点server，所有要访问资源的客户端在永久节点server下注册临时有序节点，并且监听自己前一个节点。
序列号最小的获得锁可以访问资源，访问结束，断开连接，注册的临时节点被删除，他的下一个节点通过监听能够知道，
此时节点序列号变为最小，获取到了锁，可以访问资源。