大数据面经

封面新闻 2019-05-06



一、Spark面对OOM问题的解决方法及优化总结

    spark中oom可能出现的情况:

  • map执行中内存溢出

  • shuffle后内存溢出

解决办法:

1、map过程产生大量对象导致内存溢出

    这种溢出原因是指单个map过程产生大量对象导致的,针对这种问题,在不增加内存的情况下,可以减少每个task的大小,达到每个task即使产生大量对象executor内存也装得下,具体方法可以再map操作之前先repartition,分区hou传入map

2、数据不平衡导致内存溢出

    数据不平衡除了导致内存溢出外,还可能导致性能问题,解决方式和上面一样先分区

3、coalesce调用导致内存溢出

    因为HDFS不适合存储大量小文件,如果spark计算后产生的文件太小,我们会调用coalesce合并小文件再存入HDFS,

例如在coalesce之前有100个文件,这也意味着能够有100个Task,现在调用coalesce(10),最后只产生10个文件,因为coalesce并不是shuffle操作,这意味着coalesce并不是按照我原本想的那样先执行100个Task,再将Task的执行结果合并成10个,而是从头到位只有10个Task在执行,原本100个文件是分开执行的,现在每个Task同时一次读取10个文件,使用的内存是原来的10倍,这导致了OOM。解决这个问题的方法是令程序按照我们想的先执行100个Task再将结果合并成10个文件,这个问题同样可以通过repartition解决,调用repartition(10),因为这就有一个shuffle的过程,shuffle前后是两个Stage,一个100个分区,一个是10个分区,就能按照我们的想法执行。

4、shuffle后内存溢出:

    shuffle内存溢出的情况可以说都是shuffle后,单个文件过大导致的。在Spark中,join,reduceByKey这一类型的过程,都会有shuffle的过程,在shuffle的使用,需要传入一个partitioner,大部分Spark中的shuffle操作,默认的partitioner都是HashPatitioner,默认值是父RDD中最大的分区数,这个参数通过spark.default.parallelism控制(在spark-sql中用spark.sql.shuffle.partitions) , spark.default.parallelism参数只对HashPartitioner有效,所以如果是别的Partitioner或者自己实现的Partitioner就不能使用spark.default.parallelism这个参数来控制shuffle的并发量了。如果是别的partitioner导致的shuffle内存溢出,就需要从partitioner的代码增加partitions的数量

5、 standalone模式下资源分配不均匀导致内存溢出:

    在standalone的模式下如果配置了--total-executor-cores 和 --executor-memory 这两个参数,但是没有配置--executor-cores这个参数的话,就有可能导致,每个Executor的memory是一样的,但是cores的数量不同,那么在cores数量多的Executor中,由于能够同时执行多个Task,就容易导致内存溢出的情况。这种情况的解决方法就是同时配置--executor-cores或者spark.executor.cores参数,确保Executor资源分配均匀

优化:

1.使用mapPartitions代替大部分map操作,或者连续使用的map操作

2.broadcast join和普通join:

    在大数据分布式系统中,大量数据的移动对性能的影响也是巨大的。基于这个思想,在两个RDD进行join操作的时候,如果其中一个RDD相对小很多,可以将小的RDD进行collect操作然后设置为broadcast变量,这样做之后,另一个RDD就可以使用map操作进行join,这样能够有效的减少相对大很多的那个RDD的数据移动

3.先filter在join

4.partitionBy

5.combineByKey

6. 在内存不足的使用,使用rdd.persist(StorageLevel.MEMORY_AND_DISK_SER)代替rdd.cache():

7.在spark使用hbase的时候,spark和hbase搭建在同一个集群