大数据面试题整理(1)

大数据面试题整理

1. HDFS写文件流程

(1) 客户端向namenode发送写文件请求

(2) Namenode检查文件是否已经存在, 检查客户端是否有写的权限. 若通过检查, 给客户端返回可以写入的通知

(3) 当客户端获取到可以写入的通知后, 开始对文件按照128M一个block块进行切割

(4) 客户端拿着第一个block再次请求namenode, 让namenode为这个block分配datanode地址列表

(5) Namenode根据datanode的块信息, 机架感知原理, 网络拓扑关系, 和副本信息来挑选出最合适的datanode, 将这些datanode地址按照由近到远的顺序放置到列表中返回给客户端

(6) 客户端根据列表中的第一个地址连接指定的datanode, 由这个datanode连接下一个, 以此类推, 由此形成一个pipeline管道, 同时反向还会形成一条ack的校验管道

(7) 客户端开始写入, 数据以数据包的形式进行传输, 一个数据包为64kb, 当第一个datanode接收到后, 接着传输给下一个, 以此类推, 每一个datanode接收到数据后都要在ack校验通道进行记录

(8) 第一个datanode将ack校验信息收集起来, 统一发给客户端, 由客户端校验此数据包是否全部被接受到了

(9) 客户端一次次传输, 一次次进行校验, 直到第一个block传输完成, 接下来拿着第二个block再次请求namenode, 获取datanode地址, 进而重复执行以上传输步骤,

直至将所有的block传输完成.

2. HDFS读文件流程

(1) 客户端向namenode发送读取数据请求

(2) 客户端判断即将要被读取的文件是否存在以及当前操作用户是否有读的权限, 如果通过校验, namenode会根据block信息, 网络拓扑关系,机架感知原理,副本信息,本地原则返回这个文件部分或全部的block地址

(3) 客户端拿到block部分或者全部地址后, 采取并行读取策略, 将block数据全部读取到客户端

(4) 如果namenode之前返回部分的block地址, 此时客户端接着再次请求namenode,

获取下一批block地址, 将block数据再读取到客户端, 直到将所有的block全部读取到客户端

(5) 客户端将读取到的block数据按照顺序, 依次拼接形成最终的文件返回给用户

3. Yarn的运行原理

(1) 客户端向RM提交任务(MR, Spark….)

(2) RM向NM中分配一个container, 并在该container中启动AppMaster

Container: 资源信息容器

节点信息, 内存信息, CPU信息, 运行AppMaster

(3) APP启动后和RM保持心跳机制, 用于报告当前已经启动了, 并且通过心跳来传递相关信息

(4) 根据RM给定的任务信息, 对任务进行分配, 主要会分配出要启动多少个map和多少个reduce, 以及每个map和每个reduce需要是用多大的资源空间, 然后将资源申请相关信息发送给RM

(5) RM接收到资源申请信息后, 将其交给内部资源调度器, 由资源调度器根据相关的资源调度方案, 进行资源分配即可,如果当下没有资源, 在此处等待

(6) APP基于心跳机制, 不断询问RM资源是否已经准备好了, 如果发现已经准备好了,

然后直接将资源信息获取

(7) 根据资源信息说明, 到指定NM上启动container资源容器, 开始运行相关任务

(8) NM接收到启动信息后, 开始启动执行, 此时会和APP以及MR保持心跳连接

将任务运行相关信息通过心跳机制告知AppMaster

将资源使用情况通过心跳机制告知RM

(9) 当NM运行完成后, 会通知APP并将资源使用完成情况通知给RM

(10) APP告知RM任务已经运行完成了, RM回收资源, 通知APP进行自毁即可

4. Hive的运行原理

(1) 用户通过一些交互接口或者JDBC进行SQL语句书写

(2) 任务提交给Driver

(3) SQL Parser解析器将HQL转换为抽象语法树AST

(4) Physical Plan编译器将抽象语法树转化成查询块, 将查询块转化为逻辑的查询计划,

重写逻辑查询计划

(5) Query Optimizer优化器对逻辑执行计划进行优化

(6) Execution执行器将逻辑执行计划转化成物理执行计划(MapReduce)

(7) 取得并返回执行结果

5. Namenode中磁盘存储元数据的方式(fsimage和edits)

(1) 首先将元数据存储到磁盘的edits文件中

(2) 然后将数据存储在内存中

(3) Edits文件达到一定阈值后, 就会开启一个新的edits文件

(4) 将已经达到阈值的edits文件和fsimage文件进行合并, fsimage文件保存一份较为完整的元数据信息

(5) 只要当namenode刚刚启动的时候, 就会加载fsimage和edits文件并将其加载到内存中

6. MR中shuffle的运行原理

(1) mapTask收集我们的map()方法输出的kv键值对, 放到内存缓冲区中

(2) 从内存缓冲区不断地溢出到本地磁盘文件, 可能会溢出多个文件

(3) 多个溢出文件被合并成大的溢出文件

(4) 在溢出过程中,及合并过程中,都要调用partitioner进行分区和针对key进行排序

(5) ReduceTask会根据自己的分区号, 去各个MapTask上取相应的分区结果数据

(6) ReduceTask会取到同一个分区来自不同mapTask的结果文件, reduceTask会将这些文件再进行合并

(7) 合并成大文件后, shuffle过程也就结束了, 后面进入reduceTask的逻辑运算过程

7. Yarn三种调度器及其原理

(1) FIFO Scheduler将所有的application放到队列中, 先按照作业的优先级高低, 再按照到达时间的先后, 为每个app分配资源. 一个app需要的资源被满足了, 如果还剩下了资源并且满足第二个app需要的资源, 那么就为第二个app分配资源. 不适合共享集群, 如果有大的app需要很多资源, 那么其他app就会一直等待.

(2) Capacity Scheduler用于一个集群中运行多个app的情况, 目标是最大化吞吐量和集群利用率. capacity scheduler允许将整个集群的资源分成多个部分, 每个组织使用集中一部分, 即每个组织都有一个专门的队列, 每个组织的队列还可以进一步划分层次结构, 从而允许组织内部的不同用户组使用 (3) Fair Scheduler允许应用在一个集群中公平的共享资源. 默认情况下, fair scheduler的公平调度只基于内存, 也可以配置成基于memory和cpu, 当集群中有一个app提交时, 他独占集群资源, 当有新app提交时, 第一个app会拿出一半的资源给新的app使用, 当短作业完成后, 会将资源还回去, 这样最终每个app就会得到大约相同的资源. fair scheduler可以让短的作业在合理的时间内完成, 而不必一直等待长作业完成.

8. Hadoop数据压缩

(1) 压缩是提高Hadoop运行效率的一种优化策略, 通过对Mapper, Reducer运行过程的数据进行压缩, 以减少磁盘IO, 提高MR程序运行速度

压缩基本原则:

运算密集型的job, 少用压缩

IO密集型的job, 多用压缩

9. MapReduce的优化方法

(1) 数据输入:

① 合并小文件, 在执行MapReduce之前进行小文件合并, 大量的小文件会产生大量的map任务, 增大Map任务的装载次数, 而任务的装载比较耗时, 会导致MR运行较慢.

(2) Map阶段

① 减少溢写次数, 从而减少磁盘IO

② 减少合并次数, 增大merge的文件数目, 减少Merge的次数, 从而缩短MR的处理时间

③ 在Map之后, 不影响业务逻辑的前提下, 先进行combine处理, 减少磁盘IO

(3) Reduce阶段

① 合理设置Map和Reduce数量, 均不能设置太少, 会导致Task等待, 延长处理时间, 太多会导致Map, Reduce竞争资源, 造成处理超时等错误

② 设置Map, Reduce共存, 使Map运行一段时间后, Reduce也开始运行, 减少Reduce的等待时间

③ 规避使用Reduce, 因为Reduce在用于链接数据集的时候会产生大量的网络消耗

(4) IO传输

① 采用数据压缩的方式, 减少网络IO的时间, 安装Snappy和LZO压缩编码器

② 使用SequenceFile二进制文件

(5) 数据倾斜

① Join产生数据倾斜的解决方案

1) 采用mapjoin(小表和大表, 小表要放在前面), bucket-mapjoin(中型表和大表)和SMB join(两个大表)

2) 将那些容易产生倾斜的数据, 从整个MR提取出来, 单独执行一个MR来处理即可

a. 运行时解决

b. 编译时解决

以上两种方案, 在处理后, 都需要使用union all将结果合并在一起. 也可以对这个union all进行优化, 优化目的是为了让union all不再单独执行一个MR

② Group by产生数据倾斜的解决方案 1) Map阶段聚合

2) 执行两个MR(前提是SQL不能出现多次去重)

10. Zookeeper工作机制

Zookeeper是一个分布式协调服务的开源框架, 主要用来解决分布式集群中应用系统的一致性问题.

Zookeeper本质上是一个小文件存储系统, 提供基于类似于文件系统的目录树方式的数据存储, 并且可以对树中的节点进行有效管理, 从而来维护和监控你存储数据的状态变化,

进而达到基于数据的集群管理.

11. Zookeeper特性

(1) 全局一致性: 集群中每个服务器保存一份相同的数据副本, client无论连接到哪个服务器, 展示的数据都是一致的, 这是最重要的特征.

(2) 可靠性: 如果消息被其中一台服务器接受, 那么将被所有的服务器接受

(3) 顺序性:

① 全局有序: 是指如果在一台服务器上消息A在消息B前发布, 则在所有服务器上消息A都将在消息B前被发布

② 偏序: 是指如果一个消息B在消息A后被同一个发送者发布, A必将排在B前面.

(4) 数据更新原子性: 一次数据更新要么成功, 要么失败, 不存在中间状态

(5) 实时性: zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,

或者服务器的失效信息

12. Zookeeper选举机制: 投票数大于半数则胜出的逻辑

假设目前有5台服务器, 每台服务器均没有数据, 它们的编号分别是1,2,3,4,5, 按编号依次启动, 他们选举过程如下:

(1) 服务器1启动, 给自己投票, 然后发投票信息, 由于其它机器还没启动所以它收不到反馈信息, 服务器1的状态一直属于locking(竞选状态)