推荐阅读文章列表：大数据开发面试笔记V4.0 || 面试聊数仓第一季 || 小白大数据学习路线

一、前言

快手海量hc！！！快手海量hc！！！快手海量hc！！！一点不夸张，业务发展迅猛，大量招人

二、高频面试题总结

1. 当数据量很大的时候，count(distinct uid)计算失败怎么办

两种解决方案：

1. 采用group by
2. 将uid转换为bitmap存储，然后再求总数，不仅计算优化，对存储也优化（***）

2. ClickHouse为什么快

• 数据是基于列式存储的，这样对于列的聚合统计更加有优势
• 多样化的表引擎，可以根据不同的需求选取不同的表引擎，比如replacingmergetree，summingmergetree

3. 小文件过多对Namenode有什么影响

存储大量的小文件，会占用namenode大量的内存来存储元数据信息

4. Hadoop和Hive的关系

hive就是MapReduce的一个客户端工具

5. Zookeeper在HBase的作用是什么

zookeeper主要是用来保证master的高可用

6. Flink checkpoint

1. flink应用在启动的时候，flink的JobManager创建CheckpointCoordinator
2. CheckpointCoordinator(检查点协调器) 周期性的向该流应用的所有source算子发送 barrier(屏障)。
3. 当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储（hdfs）中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理
4. 下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。
5. 每个算子按照 上面这个操作 不断制作快照并向下游广播，直到最后barrier传递到sink算子，快照制作完成。
6. 当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败。

7. Flink watermark

• 我先说一下watermark是什么，它就是一种特殊的时间戳，作用就是为了让事件时间慢一点，等迟到的数据都到了，才触发窗口计算。
• 我举个例子说一下为什么会出现watermark？比如现在开了一个5秒的窗口，但是2秒的数据在5秒数据之后到来，那么5秒的数据来了，是否要关闭窗口呢？可想而知，关了的话，2秒的数据就丢失了，如果不关的话，我们应该等多久呢？所以需要有一个机制来保证一个特定的时间后，关闭窗口，这个机制就是watermark

8. HDFS读写流程

• 写流程：hadoop fs -put a.txt /user/sl/
• 首先客户端会向namenode进行请求，然后namenode会检查该文件是否已经存在，如果不存在，就会允许客户端上传文件；客户端再次向namenode请求第一个block上传到哪几个datanode节点上，假设namenode返回了三个datanode节点；那么客户端就会向datanode1请求上传数据，然后datanode1会继续调用datanode2，datanode2会继续调用datanode3，那么这个通信管道就建立起来了，紧接着dn3，dn2，dn1逐级应答客户端；然后客户端就会向datanode1上传第一个block，以packet为单位（默认64k），datanode1收到后就会传给datanode2，dn2传给dn3当第一个block传输完成之后，客户端再次请求namenode上传第二个block。【写的时候，是串行的写入 数据块】

9. Spark和MR的区别

1. MapReduce需要将计算的中间结果写入磁盘，然后还要读取磁盘，从而导致了；而Spark不需要将计算的中间结果写入磁盘，这得益于Spark的RDD弹性分布式数据集和DAG有向无环图，中间结果能够以RDD的形式存放在内存中，这样大大减少了磁盘IO。（假设有多个转换操作，那么spark是不需要将第一个job的结果写入磁盘，然后再读入磁盘进行第二个job的，它是直接将结果缓存在内存中）
2. MapReduce在shuffle时需要花费大量时间排序，而spark在shuffle时如果选择基于hash的计算引擎，是不需要排序的，这样就会节省大量时间。
3. MapReduce是多进程模型，每个task会运行在一个独立的JVM进程中，每次启动都需要重新申请资源，消耗了大量的时间；而Spark是多线程模型，每个executor会单独运行在一个JVM进程中，每个task则是运行在executor中的一个线程。

10. MR shuffle的原理

1. map端shuffle：将map后的<k,v>写入环形缓冲区【默认100m】，一半写元数据信息（key的起始位置，value的起始位置，value的长度，partition号），一半写<k,v>数据，等到达80%的时候，就要进行spill溢写操作，溢写之前需要对key按照【分区算法默认是，分区号是根据key的hashcode对reduce task个数取模得到的。这时候有一个优化方法可选，combiner合并，就是预聚合的操作，将有相同Key 的Value 合并起来, 减少溢写到磁盘的数据量，只能用来累加、最大值使用，不能在求平均值的时候使用】；然后到文件中，并且进行（多个溢写文件）；
2. reduce端shuffle：reduce会同一分区的各个maptask的结果到内存中，如果放不下，就会溢写到磁盘上；然后对内存和磁盘上的数据进行（这样就可以满足将key相同的数据聚在一起）； 【Merge有3种形式，分别是内存到内存，内存到磁盘，磁盘到磁盘。默认情况下第一种形式不启用，第二种Merge方式一直在运行（spill阶段）直到结束，然后启用第三种磁盘到磁盘的Merge方式生成最终的文件。】

11. HQL转换为MR的过程

1. 首先客户端提交SQL以后，Hive利用Antlr框架对HQL完成词法语法解析，将HQL转换成抽象语法树
2. 然后遍历AST，将其转换成queryblock ，可以理解为最小的查询执行单元，比如where
3. 然后遍历查询块，将其转换为操作树，也就是逻辑执行计划
4. 然后使用优化器对操作树进行逻辑优化，源码中会遍历所有的优化方式，比如mapjoin，谓词下推等，来达到减少MapReduce Job，减少shuffle数据量的目的
5. 最后通过执行器将逻辑执行计划转换为物理执行计划（MR到这就结束了）（Tez和Spark还需要 使用物理优化器对任务树进行物理优化），提交到hadoop集群运行

12. 数据仓库分层的好处

1. 第一个是将复杂的需求简单化；我们通过将复杂的问题分解为多个步骤来完成，每一层只处理单一的步骤，比较容易和理解
2. 第二个是提高数据的复用性；比如在已经得到最终结果之后，又需要中间层的一些数据，我可以直接查询中间层的数据，不必重新进行计算
3. 补充说一下：我觉得数据仓库就是一种以空间换取时间的架构！