大数据面试葵花宝典之Spark进阶

大数据面试---------Spark进阶（记得收藏，防丢失）

一、Spark的几种部署模式，每种模式的特点？

答：本地模式：

Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地模式分为三类：

1.local:只启动一个executor（执行）

2.local[x]:启动x个executor

3.local[*]:启动跟cpu数目相同的executor

standalone模式：

分布式部署集群，自带完整的服务，资源管理和任务监控是Spark自己监控，这个模式也是其他模式的基础

Spark on yarn模式：

分布式部署集群，资源和任务监控交给yarn管理，但是目前仅支持粗粒度资源分配方式，包含cluster和client运行模式，cluster适合生产，driver运行在集群子节点，具有容错功能，client适合调试，dirver运行在客户端

Spark On Mesos模式：

由于Spark开发之初支持Mesos（通用的集群管理器），Spark运行在Mesos上会比运行在Yarn上更加灵活，用户可选择两种调度模式运行自己的应用程序：

1.粗粒度模式：每个应用程序的运行环境由Dirver和若干个Executor组成。应用程序的各个任务正式运行之前，需要将运行环境的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序结束后，也会回收这些资源

2.细粒度模式：鉴于粗粒度模式会造成大量资源浪费，这种模式类似于现在的云计算，思想是按需分配的。

二、Spark为什么比MapReduce快？

答：1、基于内存计算，减少低效的磁盘交互；

       2、高效的调度算法，基于DAG（有效无环图）；

       3、容错机制Linage，精华部分就是DAG和Lingae；

三、Spark的优化怎么做？

答：Spark调优比较复杂，大体三个方面（望读者理解）：

1、平台层面的调优：防止不必要的jar包分发，提高数据的本地性，选择高效的存储格式如parquet

2、应用程序层面的调优：过滤操作符的优化降低过多的小任务，降低单条记录的资源开销，处理数据倾斜，复用RDD进行缓存，作业并行化执行等

3、JVM层面的调优：设置合适的资源量，设置合理的JVM，启用高效的序列化方法如kyro，增大offhead内存等

四、数据本地性在哪个环节确定的？

答：具体的task运行在哪个机器上，DAG划分stage的时候确定

五、RDD的弹性表现在哪几点？

答：作者总结出3点，读者如果有多种望私信，感谢理解

1、存储的弹性：内存与磁盘的自动切换

Spark优先把数据放到内存中，如果内存放不下，就会放到磁盘里面，程序进行自动的存储切换

2、容错的弹性：数据丢失可以自动恢复

在RDD进行转换和动作的时候，会形成RDD的Lineage依赖链，当某一个RDD失效的时候，可以通过重新计算上游的RDD来重新生成丢失的RDD数据

3、分片的弹性：可根据需要重新分片

可以根据业务的特征，动态调整数据分片的个数，提升整体的应用执行效率

六、RDD有哪些缺陷？

答：1、不支持细粒度的写和更新操作（如爬虫），spark写数据是粗粒度，就是批量写入数据，为了提高效率，但是读数据时细粒度也就是说可以一条条的读

2、不支持增量迭代计算，Flink支持

七、Spark为什么要持久化，一般什么场景下要进行persist操作？

答：1、持久化？

Spark所有复杂一点的算法都会有persist身影，spark默认数据放在内存，spark很多内容都是放在内存中，非常适合高速迭代，1000个步骤只有第一个输入数据，中间不产生临时数据，但分布式系统风险很高，所以容易出错，就要容错，rdd出错或者分片可以根据血统算出来，如果没有对夫rdd进行persist或者cache的话，就要重头做。

2、使用persist的场景：

1）某个步骤计算非常耗时，需要进行persist持久化

2）计算链条非常长，重新恢复要算很多步骤，很好使，persist

3）shuffle之后要persist，shuffle要进行网络传输，风险很大，数据丢失重来，恢复代价很大

4）shuffle之前进行persist，框架默认将数据持久化到磁盘，这个框架自动做

八、介绍一下Join操作优化经验？

答：此操作面试官经常问到，因为涉及到数据倾斜问题，望读者拿个小本本记下来

join其实常见的就分为两类：map-side join和reduce-side join。当大表和小表join时，用map-side join能显著提高效率，将多份数据进行关联是数据处理过程中非常普遍的方法，不过在分布式计算系统中，这个问题往往会变得非常麻烦，因为框架提供的join操作一般会将所以数据根据key发送到所有的reduce分区中去，也就是shuffle的过程，造成大量的网络以及磁盘的IO消耗，运行效率极其低下，这个过程被称为reduce-side-join。

如果其中有张表较小的话，我们则可以实现在map端实现数据关联，跳过大量数据进行shuffle的过程，运行时间得到大量缩短，根据不同数据可能会有几倍到数十倍的性能提升。