大数据基础面试题五：Spark Core & SQL & Streaming

朴灿烈づ我的快乐病毒、 2022-11-05 09:57 5阅读 0赞

# 大数据基础面试题五：Spark Core & SQL & Streaming #

### 目录 ###

*  大数据基础面试题五：Spark Core & SQL & Streaming
 *   *  十一、 Spark Core & SQL
     *   *  11.1 Spark解决什么问题
         *  11.2 Spark为什么会有自己的资源调度器
         *  11.3 Spark运行模式
         *  11.4 Spark常用端口号
         *  11.5 简述Spark的架构与作业提交流程（画图讲解，注明各个部分的作用）（重点）
         *  11.6 Spark任务使用什么进行提交，JavaEE界面还是脚本
         *  11.7 Spark提交作业参数（重点）
         *  11.8 RDD五大属性
         *  11.9 Spark的transformation算子（不少于8个）（重点）
         *  11.10 Spark的action算子（不少于6个）（重点）
         *  11.11 map和mapPartitions区别
         *  11.12 Repartition和Coalesce区别
         *  11.13 reduceByKey与groupByKey的区别
         *  11.14 reduceByKey、foldByKey、aggregateByKey、combineByKey区别
         *  11.15 Kryo序列化
         *  11.16 Spark中的血缘（笔试重点）
         *  11.17 Spark任务的划分
         *  11.18 cache缓存级别
         *  11.19 释放缓存和缓存
         *  11.20 缓存和检查点区别
         *  11.21 Spark分区
         *  11.22 Spark累加器
         *  11.23 Spark广播变量
         *  11.24 SparkSQL中RDD、DataFrame、DataSet三者的转换 （笔试重点）
         *  11.25 请列举会引起Shuffle过程的Spark算子，并简述功能。
         *  11.26 当Spark涉及到数据库的操作时，如何减少Spark运行中的数据库连接数？
         *  11.27 如何使用Spark实现TopN的获取（描述思路或使用伪代码）（重点）
         *  11.28 京东：调优之前与调优之后性能的详细对比（例如调整map个数，map个数之前多少、之后多少，有什么提升）
         *  11.29 Spark Shuffle默认并行度
         *  11.30 控制Spark reduce缓存 调优shuffle
         *  11.31 Spark内核源码（重点）
     *  十二、Spark Streaming
     *   *  12.1 Spark Streaming第一次运行不丢失数据
         *  12.2 Spark Streaming精准一次消费
         *  12.3 Spark Streaming控制每秒消费数据的速度
         *  12.4 Spark Streaming背压机制
         *  12.5 Spark Streaming 一个stage耗时
         *  12.6 Spark Streaming 优雅关闭
         *  12.7 Spark Streaming 默认分区个数
         *  12.8 SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？
         *  12.9 简述SparkStreaming窗口函数的原理（重点）

## 十一、 Spark Core & SQL ##

### 11.1 Spark解决什么问题 ###

回顾：Hadoop主要解决，海量数据的存储和海量数据的分析计算。

Spark主要解决海量数据的分析计算。

### 11.2 Spark为什么会有自己的资源调度器 ###

Hadoop的Yarn框架比Spark框架诞生的晚，所以Spark自己也设计了一套资源调度框架。

### 11.3 Spark运行模式 ###

1）Local：运行在一台机器上。 测试用。  
2）Standalone：是Spark自身的一个调度系统。 对集群性能要求非常高时用。国内很少使用。  
3）Yarn：采用Hadoop的资源调度器。 国内大量使用。  
4）Mesos：国内很少使用。

### 11.4 Spark常用端口号 ###

1）4040 spark-shell任务端口  
2）7077 内部通讯端口。 类比Hadoop的8020/9000  
3）8080 查看任务执行情况端口。 类比Hadoop的8088  
4）18080 历史服务器。类比Hadoop的19888  
注意：由于Spark只负责计算，所有并没有Hadoop中存储数据的端口50070

### 11.5 简述Spark的架构与作业提交流程（画图讲解，注明各个部分的作用）（重点） ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70]

### 11.6 Spark任务使用什么进行提交，JavaEE界面还是脚本 ###

Shell脚本。

### 11.7 Spark提交作业参数（重点） ###

参考答案：  
https://blog.csdn.net/gamer\_gyt/article/details/79135118

1）在提交任务时的几个重要参数  
executor-cores —— 每个executor使用的内核数，默认为1，官方建议2-5个，我们企业是4个  
num-executors —— 启动executors的数量，默认为2  
executor-memory —— executor内存大小，默认1G  
driver-cores —— driver使用内核数，默认为1  
driver-memory —— driver内存大小，默认512M

2）边给一个提交任务的样式  
spark-submit  
–master local\[5\]  
–driver-cores 2  
–driver-memory 8g  
–executor-cores 4  
–num-executors 10  
–executor-memory 8g  
–class PackageName.ClassName XXXX.jar  
–name “Spark Job Name”  
InputPath  
OutputPath

### 11.8 RDD五大属性 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 1]

### 11.9 Spark的transformation算子（不少于8个）（重点） ###

1）单Value  
（1）map  
（2）mapPartitions  
（3）mapPartitionsWithIndex  
（4）flatMap  
（5）glom  
（6）groupBy  
（7）filter  
（8）sample  
（9）distinct  
（10）coalesce  
（11）repartition  
（12）sortBy  
（13）pipe  
2）双vlaue  
（1）intersection  
（2）union  
（3）subtract  
（4）zip  
3）Key-Value  
（1）partitionBy  
（2）reduceByKey  
（3）groupByKey  
（4）aggregateByKey  
（5）foldByKey  
（6）combineByKey  
（7）sortByKey  
（8）mapValues  
（9）join  
（10）cogroup

### 11.10 Spark的action算子（不少于6个）（重点） ###

（1）reduce：  
（2）collect:  
（3）count  
（4）first：  
（5）take：  
（6）takeOrdered  
（7）aggregate：  
（8）fold  
（9）countByKey：  
（10）save  
（11）foreach：

### 11.11 map和mapPartitions区别 ###

1）map：每次处理一条数据
    2）mapPartitions：每次处理一个分区数据

### 11.12 Repartition和Coalesce区别 ###

1）关系：  
两者都是用来改变RDD的partition数量的，repartition底层调用的就是coalesce方法：coalesce(numPartitions, shuffle = true)

2）区别：  
repartition一定会发生shuffle，coalesce根据传入的参数来判断是否发生shuffle  
一般情况下增大rdd的partition数量使用repartition，减少partition数量时使用coalesce

### 11.13 reduceByKey与groupByKey的区别 ###

reduceByKey：具有预聚合操作  
groupByKey：没有预聚合  
在不影响业务逻辑的前提下，优先采用reduceByKey。

### 11.14 reduceByKey、foldByKey、aggregateByKey、combineByKey区别 ###

ReduceByKey 没有初始值 分区内和分区间逻辑相同  
foldByKey 有初始值 分区内和分区间逻辑可以相同  
aggregateByKey 有初始值 分区内和分区间逻辑可以不同  
combineByKey 初始可以变化结构 分区内和分区间逻辑不同

### 11.15 Kryo序列化 ###

Kryo序列化比Java序列化更快更紧凑，但Spark默认的序列化是Java序列化并不是Spark序列化，因为Spark并不支持所有序列化类型，而且每次使用都必须进行注册。注册只针对于RDD。在DataFrames和DataSet当中自动实现了Kryo序列化。

### 11.16 Spark中的血缘（笔试重点） ###

宽依赖和窄依赖。有Shuffle的是宽依赖。

### 11.17 Spark任务的划分 ###

（1）Application：初始化一个SparkContext即生成一个Application；  
（2）Job：一个Action算子就会生成一个Job；  
（3）Stage：Stage等于宽依赖的个数加1；  
（4）Task：一个Stage阶段中，最后一个RDD的分区个数就是Task的个数。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 2]

### 11.18 cache缓存级别 ###

DataFrame的cache默认采用 MEMORY\_AND\_DISK  
RDD 的cache默认方式采用MEMORY\_ONLY

### 11.19 释放缓存和缓存 ###

缓存：(1)dataFrame.cache (2)sparkSession.catalog.cacheTable(“tableName”)  
释放缓存：(1)dataFrame.unpersist (2)sparkSession.catalog.uncacheTable(“tableName”)

### 11.20 缓存和检查点区别 ###

1）Cache缓存只是将数据保存起来，不切断血缘依赖。Checkpoint检查点切断血缘依赖。  
2）Cache缓存的数据通常存储在磁盘、内存等地方，可靠性低。Checkpoint的数据通常存储在HDFS等容错、高可用的文件系统，可靠性高。  
3）建议对checkpoint()的RDD使用Cache缓存，这样checkpoint的job只需从Cache缓存中读取数据即可，否则需要再从头计算一次RDD。

### 11.21 Spark分区 ###

1）默认采用Hash分区  
缺点：可能导致每个分区中数据量的不均匀，极端情况下会导致某些分区拥有RDD的全部数据。

2）Ranger分区：  
要求RDD中的KEY类型必须可以排序。

3）自定义分区  
根据需求，自定义分区。

### 11.22 Spark累加器 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 3]

### 11.23 Spark广播变量 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 4]

### 11.24 SparkSQL中RDD、DataFrame、DataSet三者的转换 （笔试重点） ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 5]

### 11.25 请列举会引起Shuffle过程的Spark算子，并简述功能。 ###

reduceBykey：  
groupByKey：  
…ByKey:

### 11.26 当Spark涉及到数据库的操作时，如何减少Spark运行中的数据库连接数？ ###

使用foreachPartition代替foreach，在foreachPartition内获取数据库的连接。

### 11.27 如何使用Spark实现TopN的获取（描述思路或使用伪代码）（重点） ###

方法1：

（1）按照key对数据进行聚合（groupByKey）  
（2）将value转换为数组，利用scala的sortBy或者sortWith进行排序（mapValues）数据量太大，会OOM。

方法2：

（1）取出所有的key  
（2）对key进行迭代，每次取出一个key利用spark的排序算子进行排序

方法3：

（1）自定义分区器，按照key进行分区，使不同的key进到不同的分区  
（2）对每个分区运用spark的排序算子进行排序

### 11.28 京东：调优之前与调优之后性能的详细对比（例如调整map个数，map个数之前多少、之后多少，有什么提升） ###

这里举个例子。比如我们有几百个文件，会有几百个map出现，读取之后进行join操作，会非常的慢。这个时候我们可以进行coalesce操作，比如240个map，我们合成60个map，也就是窄依赖。这样再shuffle，过程产生的文件数会大大减少。提高join的时间性能。

### 11.29 Spark Shuffle默认并行度 ###

参数spark.sql.shuffle.partitions 决定 默认并行度200

### 11.30 控制Spark reduce缓存 调优shuffle ###

spark.reducer.maxSizeInFilght 此参数为reduce task能够拉取多少数据量的一个参数默认48MB，当集群资源足够时，增大此参数可减少reduce拉取数据量的次数，从而达到优化shuffle的效果，一般调大为96MB,，资源够大可继续往上调。

spark.shuffle.file.buffer 此参数为每个shuffle文件输出流的内存缓冲区大小，调大此参数可以减少在创建shuffle文件时进行磁盘搜索和系统调用的次数，默认参数为32k 一般调大为64k。

### 11.31 Spark内核源码（重点） ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 6]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 7]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 8]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 10]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 11]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 12]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 13]

## 十二、Spark Streaming ##

### 12.1 Spark Streaming第一次运行不丢失数据 ###

kafka参数 auto.offset.reset 参数设置成earliest 从最初始偏移量开始消费数据

### 12.2 Spark Streaming精准一次消费 ###

1.手动维护偏移量

2.处理完业务数据后，再进行提交偏移量操作  
极端情况下，如在提交偏移量时断网或停电会造成spark程序第二次启动时重复消费问题，所以在涉及到金额或精确性非常高的场景会使用事物保证精准一次消费

### 12.3 Spark Streaming控制每秒消费数据的速度 ###

通过spark.streaming.kafka.maxRatePerPartition参数来设置Spark Streaming从kafka分区每秒拉取的条数

### 12.4 Spark Streaming背压机制 ###

把spark.streaming.backpressure.enabled 参数设置为ture,开启背压机制后Spark Streaming会根据延迟动态去kafka消费数据,上限由spark.streaming.kafka.maxRatePerPartition参数控制，所以两个参数一般会一起使用

### 12.5 Spark Streaming 一个stage耗时 ###

Spark Streaming stage耗时由最慢的task决定,所以数据倾斜时某个task运行慢会导致整个Spark Streaming都运行非常慢。

### 12.6 Spark Streaming 优雅关闭 ###

把spark.streaming.stopGracefullyOnShutdown参数设置成ture,Spark会在JVM关闭时正常关闭StreamingContext,而不是立马关闭

Kill 命令：yarn application -kill 后面跟 applicationid

### 12.7 Spark Streaming 默认分区个数 ###

Spark Streaming默认分区个数与所对接的kafka topic分区个数一致，Spark Streaming里一般不会使用repartition算子增大分区，因为repartition会进行shuffle增加耗时

### 12.8 SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？ ###

**一、基于Receiver的方式**

这种方式使用Receiver来获取数据。Receiver是使用Kafka的高层次Consumer API来实现的。receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的（如果突然数据暴增，大量batch堆积，很容易出现内存溢出的问题），然后Spark Streaming启动的job会去处理那些数据。

然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。

**二、基于Direct的方式**

这种新的不基于Receiver的直接方式，是在Spark 1.3中引入的，从而能够确保更加健壮的机制。替代掉使用Receiver来接收数据后，这种方式会周期性地查询Kafka，来获得每个topic+partition的最新的offset，从而定义每个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。

优点如下：

简化并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对它们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从Kafka中读取数据。所以在Kafka partition和RDD partition之间，有一个一对一的映射关系。  
高性能：如果要保证零数据丢失，在基于receiver的方式中，需要开启WAL机制。这种方式其实效率低下，因为数据实际上被复制了两份，Kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。  
一次且仅一次的事务机制。

**三、对比：**

基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。  
基于direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。  
在实际生产环境中大都用Direct方式

### 12.9 简述SparkStreaming窗口函数的原理（重点） ###

窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。  
图中time1就是SparkStreaming计算批次大小，虚线框以及实线大框就是窗口的大小，必须为批次的整数倍。虚线框到大实线框的距离（相隔多少批次），就是滑动步长。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70]: /images/20221023/f611cd5df95a49d9938fb455a75b8cb9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 1]: /images/20221023/1847b5c5d323484e87004b63639e75e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 2]: /images/20221023/2ec2b83e59564260ad2048251f285b33.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 3]: /images/20221023/9dd0a6dfcd0144c0b5edcebc2838afb9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 4]: /images/20221023/fa8079376aa748b0821226c8497507e5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 5]: /images/20221023/ccee362cc8ba47b78cb1bdb20c11f12a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 6]: /images/20221023/fab66394d8a44863ab075bb8a3676c3a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 7]: /images/20221023/85e8d5b0caa5454ba65b6493912b2895.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 8]: /images/20221023/6aed36ed9aec45e4a6c670f7400e6e1f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 9]: /images/20221023/d729790bb1c748629c1b45822cd00f57.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 10]: /images/20221023/6dd8a01fe5aa4a4d83d8ac8ad693acda.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 11]: /images/20221023/f50fa487dabc4f5e857f429fdfe323bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 12]: /images/20221023/e09ce05ae13343008ffbe7619c052c0d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 13]: /images/20221023/e10f9f6986a4481299156630ee9130fc.png