大数据面试题大杂烩

大数据面试题大杂烩

什么是zookeeper

ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。

zookeeper特性

1. 顺序一致性
   从同一个客户端发起的请求，最终将会严格按照其发送顺序进入ZooKeeper中
2. 原子性
   有请求的响应结果在整个分布式集群环境中具备原子性，即要么整个集群中所有机器都成功的处理了某个请求，要么就都没有处理
3. 单一性
   无论客户端连接到ZooKeeper集群中哪个服务器，每个客户端所看到的服务端模型都是一致的，不可能出现两种不同的数据状态，因为ZooKeeper集群中每台服务器之间会进行数据同步
4. 可靠性
   一旦服务端数据的状态发送了变化，就会立即存储起来，除非此时有另一个请求对其进行了变更，否则数据一定是可靠的
5. 实时性
   当某个请求被成功处理后，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能从服务端上读取到最新的数据状态

zookeeper宕机怎么处理

Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。
如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；
如果是一个Leader宕机，Zookeeper会选举出新的Leader。
ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
所以
3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)
2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)
一般zk使用单数节点，因为单数双数节点效果一样，单数节省资源。

zookeeper的监控工具taokeeper

基于zookeeper的监控管理工具taokeeper，由淘宝团队开源的zk管理中间件

hadoop版本

一般用CDH的，版本选择在5.6.0以后的
hadoop-2.6.0-cdh5.6.0,下载地址https://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.6.0.tar.gz

hadoop2.x，与1.x的区别

Hadoop2相比较于Hadoop1.x来说，HDFS的架构与MapReduce的都有较大的变化，且速度上和可用性上都有了很大的提高，Hadoop2中有两个重要的变更：

1. HDFS的NameNodes可以以集群的方式布署，增强了NameNodes的水平扩展能力和可用性；

2. MapReduce将JobTracker中的资源管理及任务生命周期管理（包括定时触发及监控），拆分成两个独立的组件，并更名为YARN（Yet Another Resource Negotiator）。

yarn的作用以及调度策略

Hadoop YARN ：这是作业调度和集群资源管理的框架。
调度策略：

1. FIFO Scheduler，先进先出队列，先给队列最头上的分配资源，以此类推。是最容易理解的调度器，不需要任何配置，但是他不适用共享集群，大的应用可能会造成阻塞，在共享集群中更适合用另外两种调度策略。
2. Capacity Scheduler，容量调度器，类似多个队列的先进先出，有一个专门的队列用来运行小任务，但是这个队列会先占用一定的集群资源，这就导致打任务执行时间会比FIFO的慢一些。
3. Fair Scheduler，公平调度器，不需要预先占用一定的资源，调度器会为所有运行的job动态的调整资源，当第一个任务进来时，使用系统的所有资源，当第二个任务进来时，公平的将资源分为两部分，两个任务同时进行，需要注意的是，第二个任务进来后资源的分配有一定的延迟，因为需要等待第一个任务将部分资源释放出来。

• 三者对比：
• FIFO：耗时长的任务会一直占用队列，后边的任务一直会处于等待状态，资源利用率不高，不适用与共享集群。
• 容量调度器：数据多用户可共享的FIFO
• 公平调度器：试图为每个任务均匀分配资源

namenode高可用如何实现

在hadoop2.x中，HDFS的namenode和Yarn的rm的单点问题都得到了解决，都可以应用到集群环境上，nn比rm的高可用实现更复杂，因为nn对数据存储和数据一致性的要求比较高。
active namenode和standby namenode，两台namenode形成互备，一台处于active，为主namenode，另一台standby是备用，只有主节点才能对外提供读写服务，主备之间控制交给zookeeper处理，zk会实时监测主节点的健康状态。
共享存储系统是nn高可用最为关键的部分，共享存储系统存储了主节点运行过程中产生的hdfs元数据，利用该系统同步到备用节点。

namenode如何实现故障转移

故障转移的操作也是利用zookeeper进行的，添加失效备缓监视器（ZKFC）131和132

1. 通过配置文件实现故障转移
2. 自动故障转移服务启动

namenode元数据的管理机制

存储元数据的三种形式：

1. 内存元数据（NameSystem）
2. 磁盘元数据镜像文件
3. 数据操作日志文件（可以通过日志运算出元数据）

namenode高可用相关文档

https://blog.csdn.net/behandthetime/article/details/53256801

secondarynamenode冷备

1. 学者会见名思义的认为secondarynamenode是namenode的备份其它的，或者认为它们是一样的。实质上，它是namenode的一个快照，会根据configuration中设置的值来决定多少时间周期性的去获取namenode中的metadata及其它数据。

2. 假使namenode损坏或丢失之后，无法启动hadoop这时就要人工去干预恢复到secondarynamenode中所照快照的状态，这就意味着集群的数据会或多或少的丢失和一些宕机时间，并且将secondarynamenode作为重要的namenode来处理，这就要求，尽量不要将secondarynamede和namenode放在同一台机器上。

如何降低集群副本数量，降低后如何生效

执行命令将某目录下数据副本改为2

hadoop dfs -setrep -w 2 -R /user

执行 hdfs balancer 均衡集群数据

参考资料：

http://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-common/CommandsManual.html

http://hadoop.apache.org/docs/r2.5.2/hadoop-project-dist/hadoop-common/FileSystemShell.html

刚才在hadoop2.6.5版本分布式集群环境试了一下：
修改hdfs-site.xml文件的dfs.replication值后，不重启hadoop集群，上传马上生效。
不重启，对于修改dfs.replication值之前的文件备份数不会变动。
重启后，对于修改dfs.replication值之前的文件备份数也不会变动。
我有两个datanode节点，测试的时候，先设置dfs.replication的值为1，后来改为2。
但是如果是由2变为1的话，hadoop也不会帮你将原先两个备份删掉一份的。

HDFS：机架感知

告诉 Hadoop 集群中哪台机器属于哪个机架。

机架感知需要考虑的情况：
（1）不同节点之间的通信能够尽量发生在同一个机架之内，
而不是跨机架
（2）为了提高容错能力，名称节点会尽可能把数据块的副本
放到多个机架上。

Hadoop 对机架的感知并非是自适应的，亦即，hadoop 集群分辨
某台 slave 机器是属于哪个 rack 并非是智能感知的，而是需要 hadoop
的管理者人为的告知 hadoop 哪台机器属于哪个 rack，这样在 hadoop
的 namenode 启动初始化时，会将这些机器与 rack 的对应信息保存
在内存中，用来作为对接下来所有的 HDFS 的写块操作分配 datanode
列表时（比如 3 个 block 对应三台 datanode）的选择 datanode 策略，
尽量将三个副本分布到不同的 rack。

集群都出现过哪些异常，如何解决的

做过哪些mr调优

1. 设置combiner，在map端提前进行了一次reduce处理，用于减少mapTask中间输出结果，从而减少各个reduceTask远程拷贝数据量
2. 选择合适的writable。
3. 增加输入文件的副本数，假设有多个datanode节点，hdfs默认是3个，我们可以设置贺datanode节点数量一致的副本数，就可以省去网络传输，但是副本数超过5个对集群的压力就已经很大了，所以还需要合理的分配。
4. 输入海量小文件的时候，使用CombineInputFormat自定义分片策略对小文件进行合并，减少maptask数量，减少map的时间，另外maptask的数量和下边的参数也有关系：

mapred.min.split.size：Input Split的最小值 默认值1
mapred.max.split.size：Input Split的最大值
dfs.block.size：HDFS 中一个block大小，默认值128MB

当mapred.min.split.size小于dfs.block.size的时候，一个block会被分为多个分片，也就是对应多个map task
当mapred.min.split.size大于dfs.block.size的时候，一个分片可能对应多个block，也就是一个map task读取多个block数据

集群的网络、IO等性能很好的时候，建议调高dfs.block.size
根据数据源的特性，主要调整mapred.min.split.size来控制map task的数量

https://blog.csdn.net/zengxiaosen/article/details/72792434
https://blog.csdn.net/ewencris/article/details/84945196