1.Spark累加器有哪些特点？

1）累加器在全局唯一的，只增不减，记录全局集群的唯一状态
2）在exe中修改它，在driver读取
3）executor级别共享的，广播变量是task级别的共享,两个application不可以共享累加器，但是同一个app不同的job可以共享

2.sparkStreaming 特有的算子

答案解析：reducebykey
带状态 updatestatebykey
窗口 window
转换 transform

3.Spark master HA 主从切换过程不会影响集群已有的作业运行，为什么？

因为程序在运行之前，已经申请过资源了，driver和Executors通讯，不需要和master进行通讯的。

4.spark 1.0和spark 2.0 的区别？

Spark2.x 引入了很多优秀特性，性能上有较大提升，API 更易用。在“编程统一”方面非常惊艳，实现了离线计算和流计算 API 的统一，实现了 Spark sql 和 Hive Sql 操作 API 的统一。Spark 2.x 基本上是基于 Spark 1.x 进行了更多的功能和模块的扩展，及性能的提升。

5.Spark中数据的位置是被谁管理的？

每个数据分片都对应具体物理位置，数据的位置是被blockManager，无论数据是在磁盘，内存还是tacyan，都是由blockManager管理

6.RDD有哪些缺陷？

1）不支持细粒度的写和更新操作（如网络爬虫），spark写数据是粗粒度的所谓粗粒度，就是批量写入数据，为了提高效率。但是读数据是细粒度的也就是说可以一条条的读
2）不支持增量迭代计算，Flink支持

7.RDD宽依赖和窄依赖？

窄依赖指的是每一个父RDD的Partition最多被子RDD的一个Partition使用,窄依赖我们形象的比喻为独生子女

宽依赖指的是多个子RDD的Partition会依赖同一个父RDD的Partition，会引起shuffle,总结：宽依赖我们形象的比喻为超生

8.Spark程序执行，有时候默认为什么会产生很多task，怎么修改默认task执行个数？

1）因为输入数据有很多task，尤其是有很多小文件的时候，有多少个输入block就会有多少个task启动；
2）spark中有partition的概念，每个partition都会对应一个task，task越多，在处理大规模数据的时候，就会越有效率。不过task并不是越多越好，如果平时测试，或者数据量没有那么大，则没有必要task数量太多。
3）参数可以通过spark_home/conf/spark-default.conf配置文件设置:spark.sql.shuffle.partitions 50 spark.default.parallelism 10第一个是针对spark sql的task数量第二个是非spark sql程序设置生效"

9.为什么要进行序列化

序列化可以减少数据的体积，减少存储空间，高效存储和传输数据，不好的是使用的时候要反序列化，非常消耗CPU

10.窄依赖父RDD的partition和子RDD的parition是不是都是一对一的关系？

不一定，除了一对一的窄依赖，还包含一对固定个数的窄依赖（就是对父RDD的依赖的Partition的数量不会随着RDD数量规模的改变而改变），比如join操作的每个partiion仅仅和已知的partition进行join，这个join操作是窄依赖，依赖固定数量的父rdd，因为是确定的partition关系

11.dataframe和Rdd的区别 ？

Rdd的本质是一个分布式的集合，这个集合里面放置的是同一个类型的数据
DataFrame 本质是一个分布式的二维表，表：表信息（表有哪些字段，这些字段什么类型） + 表的数据

12.你觉得spark 可以完全替代hadoop 么?

不可以
Spark只是分布式计算平台，而hadoop已经是分布式计算、存储、管理的生态系统。
与Spark相对应的是Hadoop MapReduce。我认为Spark是可以取代MapReduce的，从而成为Hadoop系统中不可或缺的一部分。
Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的概念。RDD可以cache到内存中，那么每次对RDD数据集的操作之后的结果，都可以存放到内存中，下一个操作可以直接从内存中输入，省去了MapReduce大量的磁盘IO操作。但是，我们也要看到spark的限制：内存。我认为Hadoop虽然费时，但是在OLAP等大规模数据的应用场景，还是受欢迎的。目前Hadoop涵盖了从数据收集、到分布式存储，再到分布式计算的各个领域，在各领域都有自己独特优势。
至于Spark相对于Hadoop的优势，我已经说了，分布式计算仅仅是hadoop的一部分。所以以下比较内容实际上是Spark和MapReduce的对比：
更快
更容易使用
编程的时候没有蛋疼的map+reduce函数，而且配置起来超级方便。除支持JAVA外，支持scala、python、R。特别是scala，简直是太适合写数据分析的程序了，mapreduce用JAVA实在是太蛋疼了。而且RDD自带的函数超级好用，真心比mapreduce方便太多
巨好用的库
能解决90%问题的四大组件，无论是SQL、还是流数据处理、机器学习库、图计算，相当好用。当然，hadoop相关的库也不少，不过spark是原生包含，用起来方便点。
运行方便
Spark是可以脱离hadoop运行的，比如数据可以从数据库或者本地文件里面抽取。不过毕竟大数据时代，大家都习惯于将Spark和hadoop通过mesos或者yarn结合起来用；主要用Hadoop的HDFS，当然HBASE或者HIVE这种HDFS之上的组件，Spark也支持。

13. kafka+spark-streaming结合丢数据怎么解决？

spark streaming从1.2开始提供了数据的零丢失，想享受这个特性，需要满足如下条件：
1.数据输入需要可靠的sources和可靠的receivers
2.应用metadata必须通过应用driver checkpoint
3.WAL（write ahead log）

14.cache和pesist的区别

1）cache和persist都是用于将一个RDD进行缓存的，这样在之后使用的过程中就不需要重新计算了，可以大大节省程序运行时间；
2） cache只有一个默认的缓存级别MEMORY_ONLY ，cache调用了persist，而persist可以根据情况设置其它的缓存级别；
3）executor执行的时候，默认60%做cache，40%做task操作，persist最根本的函数，最底层的函数

15.常规的容错方式有哪几种类型？

1）.数据检查点,会发生拷贝，浪费资源
2）.记录数据的更新，每次更新都会记录下来，比较复杂且比较消耗性能"

16.spark streaming从kafka获取数据，有哪几种方式？

有两种方式：1.通过receiver的方式，2，通过redirect的方式，redirect的方式需要自己来管理偏移量。
公司之后倾向用spark 开发,你会么(就用java代码去写) "会，spark使用scala开发的，在scala中可以随意使用jdk的类库，可以用java开发，但是最好用原生的scala开发，兼容性好，scala更灵活。

17.driver的功能是什么？

一个Spark作业运行时包括一个Driver进程，也是作业的主进程，具有main函数，并且有SparkContext的实例，是程序的入口点；功能：负责向集群申请资源，向master注册信息，负责了作业的调度，，负责作业的解析、生成Stage并调度Task到Executor上。包括DAGScheduler，TaskScheduler。

18.spark作业调优？

序列化对于提高分布式程序的性能起到非常重要的作用。一个不好的序列化方式（如序列化模式的速度非常慢或者序列化结果非常大）会极大降低计算速度。很多情况下，这是你优化Spark应用的第一选择。Spark试图在方便和性能之间获取一个平衡。Spark提供了两个序列化类库：
Java 序列化：在默认情况下，Spark采用Java的ObjectOutputStream序列化一个对象。该方式适用于所有实现了java.io.Serializable的类。通过继承 java.io.Externalizable，你能进一步控制序列化的性能。Java序列化非常灵活，但是速度较慢，在某些情况下序列化的结果也比较大。
Kryo序列化：Spark也能使用Kryo（版本2）序列化对象。Kryo不但速度极快，而且产生的结果更为紧凑（通常能提高10倍）。Kryo的缺点是不支持所有类型，为了更好的性能，你需要提前注册程序中所使用的类（class）。

19.spark 序列化？

1. java serialization：spark默认使用java 的objectoutputSream框架来序列化对象。可以对任何实现类java.io.Serialization的任何类进行序列化。用户也可以通过集成类是吸纳更紧密的序列化性能控制；
2. Kryo serialization：spark也可以使用Kryo库（version 2）来实现更快的对象序列化。Kryo比java序列化更快、数据格式更紧凑，但不支持所有的serialization类型。用户如果希望使用kryo来获取更好的性能，需要先去注册应用程序中会使用到的类。

20.对于Spark中的数据倾斜问题你有什么好的方案？

1）前提是定位数据倾斜，是OOM了，还是任务执行缓慢，看日志，看WebUI
2)解决方法，有多个方面
· 避免不必要的shuffle，如使用广播小表的方式，将reduce-side-join提升为map-side-join
·分拆发生数据倾斜的记录，分成几个部分进行，然后合并join后的结果
·改变并行度，可能并行度太少了，导致个别task数据压力大
·两阶段聚合，先局部聚合，再全局聚合
·自定义paritioner，分散key的分布，使其更加均匀