2023年7月17日发(作者：)

【Spark】Spark常见错误问题汇总（~持续更新）⼀、SparkSQL相关1.在执⾏insert 语句时报错，堆栈信息为：FileSystem closed。常常出现在ThriftServer⾥⾯。原因：由于hadoop 获得的FileSystem会从缓存加载，如果多线程⼀个线程closedFileSystem会导致该BUG解决：hdfs存在不从缓存加载的解决⽅式，在 配置 =true即可2.在执⾏Spark过程中抛出：Failed to bigdata010108:33381，caused by：lvedAdderssException原因：该原因是由于hosts未配置，导致不识别解决⽅法：修改相应的机器的host即可3.在执⾏Sparksql操作orc类型的表时抛出：utOfBoundsException 或 interException原因：分区或者表下存在空的orc⽂件。该BUG在Spark2.3.0之后才修复解决⽅法：规避解决。修改ORC的默认分割策略为：gy=BI进⾏解决。Orc的分split有3种策略（ETL、BI、HYBIRD），默认是HYBIRD(混合模式，根据⽂件⼤⼩和⽂件个数⾃动选择ETL还是BI模式)，BI模式是按照⽂件个数来分-sql和ThriftServer使⽤时报错：TimeOutException:read time out原因：是由于hivemetastore过于繁忙或者gc导致连接超时解决⽅法：spark-sql解决：t将该参数调⼤。ThriftServer解决办法：在获得⼀个Connection之前加上：inTimeout(100)5.操作snappy压缩的表时抛出：eException: native snappy library not available: this version of libhadoop wasbuilt without snappy support.原因：是由于没有在上加上snappy库解决⽅法：修改配置⽂件加上：ibraryPath /data/Install/hadoop/lib/native或者avaOptions -=/data/Install/hadoop/lib/-sql在执⾏时将⼀个很⼩的⽂件拆分成了20个task进⾏运⾏，导致运⾏速度太慢。原因：是由于HaddopRDD⽣成过程中partitions是会拿参数或（20）和spark默认分区数(2)做最⼤值⽐较，所以导致默认为20解决⽅法：修改该参数就可以将task降下来。Server登录异常：ticationException: Error validating LDAP user原因：是由于密码错误或者LDAP服务异常解决⽅法：解决密码和验证问题8.使⽤jdbc的⽅式连接到ThriftServer，可以执⾏类似与show tabls的等操作，但是不能执⾏select相关的操作：ption:Failed to create local dir in /tmp/blockmgr-adb70127-0a28-4256-a205-c575acc74f9d/06.原因：⽤户很久没使⽤ThriftServer导致系统清理了该上级⽬录或者⽤户根本就对该⽬录没有写权限解决⽅法：重启ThriftServer和设置⽬录权限：9.在Spark SQL中运⾏的SQL语句过于复杂的话，会出现 verflowError 异常原因：这是因为程序运⾏的时候 Stack ⼤⼩⼤于 JVM 的设置⼤⼩解决⽅法：通过在启动 Spark-sql 的时候加上 --driver-java-options “-Xss10m” 选项解决这个问题 INTO重复执⾏出现：Unable to move source hdfs://bigdata05/tmp/hive-hduser1101_hive_2017-09-11_14-50-56_038_23582770-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不带分区重复执⾏不会出现问题11.执⾏⼤数据量的join等操作时出现：g an output location for shuffle； to connect to bigdata030015/100.103.131.13:38742;tFoundException……(not such file or directory)。ner 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。QL和DataFrame的join,group by等操作通过ions控制分区数，默认为200，根据shuffle的量以及计算的复杂度提⾼这个值。的join,groupBy,reduceByKey等操作，通过elism控制shuffle read与reduce处理的分区数，设置⼤⼀点。4.通过提⾼executor的内存设置适当提⾼executor的memory值。5.判断join过程中是否存在数据倾斜的问题：可以参考链接：12. Sparksql使⽤过程中Executor端抛出：emoryError: GC overhead limit exceeded原因：这是由于⼤部分事件都在GC，导致OOM。解决⽅法：加⼤执⾏器内存，修改GC策略avaOptions -XX:+rver2和SparkThriftServer使⽤操作orc表的时候报错A⽤户⽆法访问B⽤户的⽬录。原因：这是由于orc 在进⾏Split过冲中会进⾏⽤户缓存。ORC在hive1.2.1时的BUG，在hive2.X和Spark2.3.X版本后进⾏了解决解决⽅法：暂时规避⽅法⽐较暴⼒，1、先使⽤超级⽤户进⾏第⼀次查询，导致缓存的⽤户为超级⽤户。2、设置sion=none不进⾏缓存-sql在使⽤过程中⼩数据量查询很慢，查看sparkUI显⽰每个Task处理都很快，但是都隔了3秒进⾏调度导致整体很慢。原因：这是由于数据本地性导致的，默认为3秒解决⽅法：设置该参数为0即可加快速度，只有在数据量较⼩的情况下才建议这样设置。⼆.Spark core相关 on yarn启动spark-sql 和spark-submit时出现：sDefFoundError: com/sun/jersey/api/client/config/ClientConfig原因：和yarn相关Jersey包冲突解决⽅法：配置上–conf d=false2.在使⽤Spark过程中出现：ption: No space left on device原因：⼀般是由于Spark的tmp⽬录满了导致解决⽅法：可以将该⽬录空间设置⼤点，⽀持按逗号分割多个⽬录：3.超出最⼤结果集：is bigger than ultSize (2.0GB)原因：ultSize默认配置为1G解决⽅法：调⼤该参数即可4.常见OOM：emoryError: 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考虑提⾼：包版本冲突时：otFoundException: XXX原因：⼀般可能是⽤户jar和Spark jar冲突解决⽅法：1、最好和Spark相关的jar进⾏适配。2、如果不⾏可以使⽤参数：assPathFirst和assPathFirst 设置为true7.进⾏shuffle抛出：Shuffle Fetch Failed: OOM原因：Shuffle fetch阶段开启的fetch数据量过⼤导致解决⽅法：1、加⼤Executor内存。2、将参数eInFlight调⼩，默认e报ailedException: Direct buffer memory原因：堆外内存不够导致，直接内存解决⽅法：增⼤JVM 参数-XX:MaxDirectMemorySize（如：avaOptions = -XX:MaxDirectMemorySize=xxxm）9.集群节点异常导致Spark job失败，如磁盘只读。原因：Spark 是⼀个⾼性能、容错的分布式计算框架，⼀旦它知道某个计算所在的机器出现问题会依据之前⽣成的 lineage 重新在这台机器上调度这个 Task，如果超过失败次数就会导致job失败。解决⽅法：Spark有⿊名单机制，在超出⼀定次数的失败后不会往该节点或者Executor调度Task。设置相应Black参数：d=true三.Pyspark相关 python和Executor Python版本不⼀致问题原因：pyspark要求所有的Executor运⾏的python版本⼀致解决⽅法：指定python的运⾏路径： /data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python或者env配置上：export PYSPARK_PYTHON=/data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python；exportPYSPARK_DRIVER_PYTHON=/data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/k使⽤过程中出现：RDD时出现序列化(obj)报错，EOFError。有时可以，在local也可以。原因：在on yarn时，机器上也有安装相关的Spark。导致包冲突解决⽅法：删除nodeManager上的Spark安装路径就可以解决3.运⾏RDD操作时报Randomness of hash of string should be disabled via PYTHONHASHSEED mean in pyspark原因：这是由于各个Executor的Hash随机值不⼀样导致。解决⽅法：只需要指定各Executor的PYTHONHASHSEED环境变量即可如：–HASHSEED=321 四.Streaming相关1.消费kafka时，第⼀个job读取了现有所有的消息，导致第⼀个Job处理过久甚⾄失败原因：设置为了earliest 从最早的offset开始进⾏消费，也没有设置ePerPartition参数解决⽅法：指定从之前开始消费的数据开始：设置offsetRange。并将参数设置为：=latest 设置Spark每个分区的速率。2.尽量使⽤⾼性能算⼦使⽤reduceByKey/aggregateByKey替代groupByKey使⽤mapPartitions替代普通map使⽤foreachPartitions替代foreach使⽤filter之后进⾏coalesce操作使⽤repartitionAndSortWithinPartitions替代repartition与sort类操作ing如果存在多个Batch延迟时，消费不过来。有时会报出：Hbase相关的异常如：RegionTooBusyException原因：Streaming在进⾏处理时如果单个Batch读取的数据多，会导致计算延迟甚⾄导致存储组件性能压⼒解决⽅法：1、如果是计算延迟试着调整读取速率如：ePerPartition参数2、调优存储组件的性能3、开启Spark的反压机制：d，该参数会⾃动调优读取速率。但是如果设置了e 或 ePerPartition，那么最后到底接收多少数据取决于三者的最⼩值 4.消费kafka时，读取消息报错：OffsetOutOfRangeException原因：读取的offsetRange超出了Kafka的消息范围，如果是⼩于也就是kafka保存的消息已经被处理掉了（）。或者超出Kafka现有的offset解决⽅法：在读取offset时先进⾏校正，拿到offset的earliestOffset 和抖动导致No leader foundkafka变更或者其他原因导致解决⽅法：设置 ries ⼤于1