一.SparkSQL相关
1.在执行insert 语句时报错，堆栈信息为：FileSystem closed。常常出现在ThriftServer里面。
原因：由于hadoop FileSystem.get 获得的FileSystem会从缓存加载，如果多线程一个线程closedFileSystem会导致该BUG
解决：hdfs存在不从缓存加载的解决方式，在hdfs-site.xml 配置 fs.hdfs.impl.disable.cache=true即可
2.在执行Spark过程中抛出：Failed to bigdata010108:33381，caused by：java.nio.channels.unresolvedAdderssException
原因：该原因是由于hosts未配置，导致不识别
解决：修改相应的机器的host即可
3.在执行Sparksql操作orc类型的表时抛出：java.lang.IndexOutOfBoundsException 或者 java.lang.NullPointerException
原因：分区或者表下存在空的orc文件。该BUG在
Spark2.3.0之后才修复
解决：规避解决。修改ORC的默认分割策略为：hive.exec.orc.split.strategy=BI进行解决。
Orc的分split有3种策略（ETL、BI、HYBIRD），默认是HYBIRD(混合模式，根据文件大小和文件个数自动选择ETL还是BI模式)，BI模式是按照文件个数来分split
4.Spark2.1.0不支持永久函数，这是由于Spark2.2.0之前不支持读取hdfs上面的jar包。
5.Saprk-sql和ThriftServer使用时报错：Java.net.socketTimeOutException:read time out
原因：是由于hivemetastore过于繁忙或者gc导致连接超时
解决：spark-sql解决：hive.metastore.client.socket.timeout将该参数调大。
ThriftServer解决办法：在获得一个Connection之前加上：DriverManager.setLoginTimeout(100)
6.操作snappy压缩的表时抛出：java.lang.RuntimeException: native snappy library not available: this version of libhadoop was built without snappy support.
原因：是由于没有在
java.library.path上加上snappy库
解决方法：修改spark-default.conf配置文件加上：
spark.executor.extraLibraryPath= /data/Install/hadoop/lib/native 或者
spark.executor.extraJavaOptions -Djava.library.path=/data/Install/hadoop/lib/native
7.Spark-sql在执行时将一个很小的文件拆分成了20个task进行运行，导致运行速度太慢。
原因：是由于HaddopRDD生成过程中partitions是会拿参数
mapreduce.job.maps,或mapred.map.tasks（20）和spark默认分区数(2)做最大值比较，所以导致默认为20
解决方法：修改该参数就可以将task降下来。
8.ThriftServer登录异常：javax.security.sasl.AuthenticationException: Error validating LDAP user
原因：是由于密码错误或者LDAP服务异常
解决方法：解决密码和验证问题
9.使用jdbc的方式连接到ThriftServer，可以执行类似与show tabls的等操作，但是不能执行select相关的操作：java.io.IOException: Failed to create local dir in /tmp/blockmgr-adb70127-0a28-4256-a205-c575acc74f9d/06.
原因：用户很久没使用ThriftServer导致系统清理了该上级目录或者用户根本就对该目录没有写权限
解决方法：重启ThriftServer和设置目录权限：spark.local.dir
10.在Spark SQL中运行的SQL语句过于复杂的话，会出现 java.lang.StackOverflowError 异常
原因：这是因为程序运行的时候 Stack 大小大于 JVM 的设置大小
解决方法：通过在启动 Spark-sql 的时候加上 --driver-java-options “-Xss10m” 选项解决这个问题
11.INSERT INTO重复执行出现：Unable to move source hdfs://bigdata05/tmp/hive-hduser1101_hive_2017-09-11_14-50-56_038_2358196375683362770-82/-ext-10000/part-00000 to destination hdfs://bigdata05/user/hive
原因：该问题是2.1.0的Bug，在Spark2.1.1中已经解决2.1.0。
解决方法：2.1.0规避办法INSERT OVERWRITE不带分区重复执行不会出现问题
12.执行大数据量的join等操作时出现：
1.Missing an output location for shuffle；
2.Failed to connect to bigdata030015/100.103.131.13:38742;
3.FileNotFoundException……(not such file or directory)。
4.Container killed on request. Exit code is 143
原因：shuffle分为shuffle write和shuffle read两部分。shuffle write的分区数由上一阶段的RDD分区数控制，shuffle read的分区数则是由Spark提供的一些参数控制。shuffle write可以简单理解为类似于saveAsLocalDiskFile的操作，将计算的中间结果按某种规则临时放到各个executor所在的本地磁盘上。
shuffle read的时候数据的分区数则是由spark提供的一些参数控制。可以想到的是，如果这个参数值设置的很小，同时shuffle read的量很大，那么将会导致一个task需要处理的数据非常大。结果导致JVM crash（OOM），从而导致取shuffle数据失败，同时executor也丢失了，看到Failed to connect to host的错误，也就是executor lost的意思。有时候即使不会导致JVM crash也会造成长时间的gc
解决方法：
1.调优sql。
2.SparkSQL和DataFrame的join,group by等操作通过spark.sql.shuffle.partitions控制分区数，默认为200，根据shuffle的量以及计算的复杂度提高这个值。
3.Rdd的join,groupBy,reduceByKey等操作，通过spark.default.parallelism控制shuffle read与reduce处理的分区数，设置大一点。
4.通过提高executor的内存设置spark.executor.memory适当提高executor的memory值。
5.判断join过程中是否存在数据倾斜的问题：可以参考链接：https://tech.meituan.com/spark-tuning-pro.html
13.Sparksql使用过程中Executor端抛出：java.lang.OutOfMemoryError: GC overhead limit exceeded
原因：这是由于大部分事件都在GC，导致OOM。
解决方法：加大执行器内存，修改GC策略spark.executor.extraJavaOptions -XX:+UseG1GC
14.hiveserver2和SparkThriftServer使用操作orc表的时候报错A用户无法访问B用户的目录。
原因：这是由于orc 在进行Split过冲中会进行用户缓存。ORC在hive1.2.1时的BUG，在hive2.X和Spark2.3.X版本后进行了解决
解决方法：暂时规避方法比较暴力，
1、先使用超级用户进行第一次查询，导致缓存的用户为超级用户。
2、设置hive.fetch.task.conversion=none不进行缓存
15.spark-sql在使用过程中小数据量查询很慢，查看sparkUI显示每个Task处理都很快，但是都隔了3秒进行调度导致整体很慢。
原因：这是由于数据本地性导致的，默认
spark.locality.wait为3秒
解决方法：设置该参数为0即可加快速度，只有在数据量较小的情况下才建议这样设置。
二.Spark core相关
1.spark on yarn启动spark-sql 和spark-submit时出现：java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig
原因：和yarn相关Jersey包冲突
解决方法：配置上–conf spark.hadoop.yarn.timeline-service.enabled=false
2.在使用Spark过程中出现：java.io.IOException: No space left on device
原因：一般是由于Spark的tmp目录满了导致
解决方法：可以将该目录空间设置大点，支持按逗号分割多个目录：spark.local.dir
3.超出最大结果集：is bigger than spark.driver.maxResultSize (2.0GB)
原因：
spark.driver.maxResultSize默认配置为1G
解决方法：调大该参数即可
4.常见OOM：java.lang.OutOfMemoryError: Java heap space
原因：1、数据量太大，申请的Executor资源不足以支撑。2.单分区的数据量过大，和分区数过多导致执行task和job存储的信息过多导致Driver OutOfMemoryError
解决方法：1、尽量不要使用collect操作。2、查看数据是否有倾斜，增加shuffle的并行度，加大Executor内存
5.由Executor的FullGC引起Executor lost，task失败，各种超时：Futures timed out after【120S】
原因：一般是由于Executor处理数据量过大如倾斜导致，从而使Executor full gc导致时间超时，Executor 和 task 的lost
解决方法：1、如果通过查看Executor的日志是full GC导致，适当调优SQL，加大Executor内存。2、如果没有fullGC考虑提高：spark.network.timeout
6.jar包版本冲突时：java.lang.ClassNotFoundException: XXX
原因：一般可能是用户jar和Spark jar冲突
解决方法：1、最好和Spark相关的jar进行适配。2、如果不行可以使用参数：spark.driver.userClassPathFirst和spark.executor.userClassPathFirst设置为true
7.进行shuffle抛出：Shuffle Fetch Failed: OOM
原因：Shuffle fetch阶段开启的fetch数据量过大导致
解决方法：1、加大Executor内存。2、将参数spark.reduce.maxSizeInFlight调小，默认48M
8.shuffle报org.apache.spark.shuffle.FetchFailedException: Direct buffer memory
原因：堆外内存不够导致
解决方法：增大JVM 参数-XX:MaxDirectMemorySize（如：spark.executor.extraJavaOptions = -XX:MaxDirectMemorySize=xxxm）
9.集群节点异常导致Spark job失败，如磁盘只读。
原因：Spark 是一个高性能、容错的分布式计算框架，一旦它知道某个计算所在的机器出现问题会依据之前生成的 lineage 重新在这台机器上调度这个 Task，如果超过失败次数就会导致job失败。
解决方法：Spark有黑名单机制，在超出一定次数的失败后不会往该节点或者Executor调度Task。设置相应Black参数：spark.blacklist.enabled=true
转载自：https://mp.weixin.qq.com/s/bqDu_4WBqjjJ7HIjW4KyiQ