hadoop整理 --按照题目顺序-面试题目汇总

1.https://www.cnblogs.com/sunddenly/p/3977011.html

1.hadoop面试题及答案

添加链接描述

2. Hadoop、Hive、HBase的区别

YARN架构概述
　　Yarn是管理内存调度和cpu资源分配的。
　　*NodeManager(NM)：常驻进程，类似于团队里面的码农，主要作用如下：
　　　　1）管理单个节点的资源。(看禅道，完成自己每天的工作安排)
　　　　2）处理来自ResourceManager的命令。(完成技术经理分配的任务)
　　　　3）处理来自ApplicationMaster的命令。(完成项目组长分配的任务)
　　*ApplicationMaster(AM)：是ResourceManager临时启用的一个节点，不是常驻进程，类似于一个技术小组长：
　　　　1）负责数据的切分，任务的监控与容错。（管理组内同事工作）
　　　　2）为应用程序申请资源分配给内部任务。（向领导为小组申请资源：人力、时间什么的）
　　*ResourceManager(RM) ：常驻进程，一个集群只有一个，用来管理集群调度情况的，就像一个部门的技术经理一样，其作用如下：
　　　　1）处理客户端请求，进行资源分配与调度。(对接产品需求，分给手下的人)
　　　　2）监控nodeManager（管理团队成员每天的工作）
　　　　3）启动或监控applicationMaster（可能项目太小不想亲自动手，临时任命一个小组长）
　　*Container：非常驻进程，它是yarn中的资源抽象，他封装了某个节点上的多维度资源，入内存，CPU，磁盘网络等。Am就运行在这里面，Nm通过打开关闭Container开完成资源的调度。

3.hadoop小文件问题

https://cloud.tencent.com/developer/article/1482598
https://www.cnblogs.com/ballwql/p/8944025.html

4.mapreduce的shuffle过程，map端的并行度

5.为什么一定要有shuffle过程

6.mapreduce分桶的作用

7.spark,hadoop的区别

8.hadoop没被淘汰的原因

11.hdfs与hbase有啥关系

12.hdfs默认副本数是几个？为什么

13.架构设计：每天上百亿级别数据，数据来了之后如何进行架构设计，以完成数据分析，数据检索功能

14.50个红球，50个蓝球，怎么放入两个袋子，让拿到红球的概率最大

一个放一个红球，另一个放49个红球和所有的蓝球

15.Hadoop的block大小调大了会造成什么影响？调大好还是调小好一点？为什么？

15.1 概述

hadoop集群中文件的存储都是以块的形式存储在hdfs中。

15.2 默认值

从2.7.3版本开始block size的默认大小为128M，之前版本的默认值是64M.

15.3 如何修改block块的大小？

可以通过修改hdfs-site.xml文件中的dfs.blocksize对应的值。
注意：在修改HDFS的数据块大小时，首先停掉集群hadoop的运行进程，修改完毕后重新启动。

15.4 block块大小设置规则

在实际应用中，hdfs block块的大小设置为多少合适呢？为什么有的是64M，有的是128M、256M、512呢？
首先我们先来了解几个概念：
1）寻址时间：HDFS中找到目标文件block块所花费的时间。
2）原理：文件块越大，寻址时间越短，但磁盘传输时间越长；文件块越小，寻址时间越长，但磁盘传输时间越短。

15.5 block不能设置过大，也不要能设置过小

1）如果块设置过大，
一方面从磁盘传输数据的时间会明显大于寻址时间，导致程序在处理这块数据时，变得非常慢；
另一方面，MapReduce中的map任务通常一次只处理一个块中的数据，如果块过大运行速度也会很慢。
2）如果设置过小，
一方面存放大量小文件会占用NameNode中大量内存来存储元数据，而NameNode的内存是有限的，不可取；
另一方面块过小，寻址时间增长，导致程序一直在找block的开始位置。
因此，块适当设置大一些，减少寻址时间，那么传输一个有多个块组成的文件的时间主要取决于磁盘的传输速度。

15.6 多大合适呢？

1）HDFS中平均寻址时间大概为10ms；
2）经过前任的大量测试发现，寻址时间为传输时间的1%时，为最佳状态，所以最佳传输时间为：
　　　　　　　　　　　　10ms/0.01=1000s=1s
3）目前磁盘的传输速度普遍为100MB/s，最佳block大小计算：
　　　　　　　　　　　　100MB/s*1s=100MB
所以我们设置block大小为128MB.
4）实际中，磁盘传输速率为200MB/s时，一般设定block大小为256MB;磁盘传输速率为400MB/s时，一般设定block大小为512MB.
转载自

16.Hadoop常见的数据压缩算法

对比项/压缩算法	Gzip压缩	lzo压缩	snappy压缩	bzip2压缩
压缩率	较高（第2）	合理（比Gzip低）	合理（比Gzip低）	最高（第1）
压缩/解压速度	较快	较快	较快	最慢，且不支持native
Hadoop是否支持	支持	不支持	不支持	支持
是否支持split	不支持	支持	不支持	支持
适用场景	每个文件压缩后130M以内，一个bolck块大小	大文件，压缩后超200M，越大优化效果越明显	当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。	高压缩率，但不要求压缩/解压效率时

16.1 Gzip压缩

1. 优点：
   压缩率比较高，而且压缩/解压速度也比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；大部分linux系统都自带gzip命令，使用方便。
2. 缺点：
   不支持split。
3. 应用场景：
   当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用gzip压缩格式。譬如说一天或者一个小时的日志压缩成一个gzip文件，运行mapreduce程序的时候通过多个gzip文件达到并发。hive程序，streaming程序，和java写的mapreduce程序完全和文本处理一样，压缩之后原来的程序不需要做任何修改。

16.2 lzo压缩

1. 优点：
   压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；可以在linux系统下安装lzop命令，使用方便。
   缺点：
   压缩率比gzip要低一些；hadoop本身不支持，需要安装；在应用中对lzo格式的文件需要做一些特殊处理（为了支持split需要建索引，还需要指定inputformat为lzo格式）。
   应用场景：
   一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越越明显。

16.3 snappy压缩

1. 优点：
   高速压缩速度和合理的压缩率。
2. 缺点：
   不支持split；压缩率比gzip要低；hadoop本身不支持，需要安装；
3. 应用场景：
   当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。

16.4 bzip2压缩

1. 优点：
   支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便。
2. 缺点：
   压缩/解压速度慢；不支持native。
3. 应用场景：
   适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；或者输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程序（即应用程序不需要修改）的情况。

16.5 如何选择压缩格式？

Hadoop应用处理的数据集非常大，因此需要借助于压缩。使用哪种压缩格式与待处理的文件的大小、格式和所使用的工具相关。下面我们给出了一些建议，大致是按照效率从高到低排序的。
1）使用容器文件格式，例如顺序文件、RCFile或者Avro 数据文件，所有这些文件格式同时支持压缩和切分。通常最好与一个快速压缩工具联合使用，例如LZO，LZ4或者 Snappy。
2）使用支持切分的压缩格式，例如bzip2(尽管bzip2 非常慢)，或者使用通过索引实现切分的压缩格式，例如LZO。
3）在应用中将文件切分成块，并使用任意一种压缩格式为每个数据块建立压缩文件(不论它是否支持切分)。这种情况下，需要合理选择数据块的大小，以确保压缩后数据块的大小近似与HDFS块的大小。
4）存储未经压缩的文件。
对大文件来说，不要使用不支持切分整个文件的压缩格式，因为会失去数据的本地特性，进而造成MapReduce应用效率低下。
转载自

17 采用压缩的位置

压缩可以在MapReduce作用的任意阶段启用。
1）输入压缩：
在有大量数据并计划重复处理的情况下，应该考虑对输入进行压缩。然而，你无须显示指定使用的编解码方式。Hadoop自动检查文件扩展名，如果扩展名能够匹配，就会用恰当的编解码方式对文件进行压缩和解压。否则，Hadoop就不会使用任何编解码器。
2）压缩mapper输出：
当map任务输出的中间数据量很大时，应考虑在此阶段采用压缩技术。这能显著改善内部数据Shuffle过程，而Shuffle过程在Hadoop处理过程中是资源消耗最多的环节。如果发现数据量大造成网络传输缓慢，应该考虑使用压缩技术。可用于压缩mapper输出的快速编解码器包括LZO或者Snappy。
注：LZO是供Hadoop压缩数据用的通用压缩编解码器。其设计目标是达到与硬盘读取速度相当的压缩速度，因此速度是优先考虑的因素，而不是压缩率。与gzip编解码器相比，它的压缩速度是gzip的5倍，而解压速度是gzip的2倍。同一个文件用LZO压缩后比用gzip压缩后大50%，但比压缩前小25%~50%。这对改善性能非常有利，map阶段完成时间快4倍。
3）压缩reducer输出：
在此阶段启用压缩技术能够减少要存储的数据量，因此降低所需的磁盘空间。当mapreduce作业形成作业链条时，因为第二个作业的输入也已压缩，所以启用压缩同样有效。
转载自

18.Hadoop之——HDFS容错

转载请注明出处：转载链接
HDFS的容错能力大概可以分为两个方面：文件系统的容错性以及Hadoop本身的容错能力。

18.1 文件系统的容错性

1. 心跳机制,在Namenode和Datanode之间维持心跳检测，
   当由于网络故障之类的原因，导致Datanode发出的心跳包没有被Namenode正常收到的时候，Namenode就不会将任何新的IO操作派发给那个Datanode，该Datanode上的数据被认为是无效的，因此Namenode会检测是否有文件block的副本数目小于设置值，如果小于就自动开始复制新的副本并分发到其他Datanode节点。
2. 检测文件block的完整性，HDFS会记录每个新创建的文件的所有block的校验和。当以后检索这些文件的时候，从某个节点获取block，会首先确认校验和是否一致，如果不一致，会从其他Datanode节点上获取该block的副本。
   集群的负载均衡，由于节点的失效或者增加，可能导致数据分布的不均匀，当某个Datanode节点的空闲空间大于一个临界值的时候，HDFS会自动从其他Datanode迁移数据过来。
3. Namenode上的fsimage和edits日志文件是HDFS的核心数据结构，如果这些文件损坏了，HDFS将失效。因而，Namenode可以配置成支持维护多个FsImage和Editlog的拷贝。任何对FsImage或者Editlog的修改，都将同步到它们的副本上。它总是选取最近的一致的FsImage和Editlog使用。Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。
4. 文件的删除，删除并不是马上从Namenode移出namespace，而是放在/trash目录随时可恢复，直到超过设置时间才被正式移除。

18.2 Hadoop本身的容错性

Hadoop支持升级和回滚，当升级Hadoop软件时出现bug或者不兼容现象，可以通过回滚恢复到老的Hadoop版本。