Spark面试问题

1.spark作业调优

序列化对于提高分布式程序的性能起到非常重要的作用。一个不好的序列化方式（如序列化模式的速度非常慢或者序列化结果非常大）会极大降低计算速度。很多情况下，这是你优化Spark应用的第一选择。Spark试图在方便和性能之间获取一个平衡。Spark提供了两个序列化类库：

 

Java 序列化：在默认情况下，Spark采用Java的ObjectOutputStream序列化一个对象。该方式适用于所有实现了java.io.Serializable的类。通过继承 java.io.Externalizable，你能进一步控制序列化的性能。Java序列化非常灵活，但是速度较慢，在某些情况下序列化的结果也比较大。

Kryo序列化：Spark也能使用Kryo（版本2）序列化对象。Kryo不但速度极快，而且产生的结果更为紧凑（通常能提高10倍）。Kryo的缺点是不支持所有类型，为了更好的性能，你需要提前注册程序中所使用的类（class）。

 

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

spark streaming从1.2开始提供了数据的零丢失，想享受这个特性，需要满足如下条件：

1.数据输入需要可靠的sources和可靠的receivers

2.应用metadata必须通过应用driver checkpoint

3.WAL（write ahead log）

 

3.公司之后倾向用spark 开发,你会么(就用java代码去写)

会，spark使用scala开发的，在scala中可以随意使用jdk的类库，可以用java开发，但是最好用原生的scala开发，兼容性好，scala更灵活。

4.你觉得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也支持。

 

5.storm和spark-streaming：为什么用storm不同spark-streaming

对于Storm来说：

1、建议在那种需要纯实时，不能忍受1秒以上延迟的场景下使用，比如实时金融系统，要求纯实时进行金融交易和分析

2、此外，如果对于实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，一条也不能多，一条也不能少，也可以考虑使用Storm

3、如果还需要针对高峰低峰时间段，动态调整实时计算程序的并行度，以最大限度利用集群资源（通常是在小型公司，集群资源紧张的情况），也可以考虑用Storm

4、如果一个大数据应用系统，它就是纯粹的实时计算，不需要在中间执行SQL交互式查询、复杂的transformation算子等，那么用Storm是比较好的选择

对于Spark Streaming来说：

1、如果对上述适用于Storm的三点，一条都不满足的实时场景，即，不要求纯实时，不要求强大可靠的事务机制，不要求动态调整并行度，那么可以考虑使用Spark StrStreaming

2、考虑使用Spark Streaming最主要的一个因素，应该是针对整个项目进行宏观的考虑，即，如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询等业务功能，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性

 6.Spark Streaming与Storm的优劣分析

事实上，Spark Streaming绝对谈不上比Storm优秀。这两个框架在实时计算领域中，都很优秀，只是擅长的细分场景并不相同。

Spark Streaming仅仅在吞吐量上比Storm要优秀，而吞吐量这一点，也是历来挺Spark Streaming，贬Storm的人着重强调的。但是问题是，是不是在所有的实时计算场景下，都那么注重吞吐量？不尽然。因此，通过吞吐量说Spark Streaming强于Storm，不靠谱。

事实上，Storm在实时延迟度上，比Spark Streaming就好多了，前者是纯实时，后者是准实时。而且，Storm的事务机制、健壮性 / 容错性、动态调整并行度等特性，都要比Spark Streaming更加优秀。

Spark Streaming，有一点是Storm绝对比不上的，就是：它位于Spark生态技术栈中，因此Spark Streaming可以和Spark Core、Spark SQL无缝整合，也就意味着，我们可以对实时处理出来的中间数据，立即在程序中无缝进行延迟批处理、交互式查询等操作。这个特点大大增强了Spark Streaming的优势和功能。