Spark常見錯誤問題彙總

一.SparkSQL相關

在執行insert 語句時報錯，堆棧資訊為：FileSystem closed。常常出現在ThriftServer裡面。

原因：由于hadoop FileSystem.get 獲得的FileSystem會從緩存加載，如果多線程一個線程closedFileSystem會導緻該BUG

解決方法：hdfs存在不從緩存加載的解決方式，在hdfs-site.xml 配置 fs.hdfs.impl.disable.cache=true即可

在執行Spark過程中抛出：Failed to bigdata010108:33381，caused by：java.nio.channels.unresolvedAdderssException

原因：該原因是由于hosts未配置，導緻不識别

解決方法：修改相應的機器的host即可

在執行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

Spark2.1.0不支援永久函數，這是由于Spark2.2.0之前不支援讀取hdfs上面的jar包。

Saprk-sql和ThriftServer使用時報錯：Java.net.socketTimeOutException:read time out

原因：是由于hivemetastore過于繁忙或者gc導緻連接配接逾時

解決方法：spark-sql解決：hive.metastore.client.socket.timeout将該參數調大。ThriftServer解決辦法：在獲得一個Connection之前加上：DriverManager.setLoginTimeout(100)

操作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

Spark-sql在執行時将一個很小的檔案拆分成了20個task進行運作，導緻運作速度太慢。

原因：是由于HaddopRDD生成過程中partitions是會拿參數mapreduce.job.maps ,或mapred.map.tasks（20）和spark預設分區數(2)做最大值比較，是以導緻預設為20

解決方法：修改該參數就可以将task降下來。

ThriftServer登入異常：javax.security.sasl.AuthenticationException: Error validating LDAP user

原因：是由于密碼錯誤或者LDAP服務異常

解決方法：解決密碼和驗證問題

使用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

在Spark SQL中運作的SQL語句過于複雜的話，會出現 java.lang.StackOverflowError 異常

原因：這是因為程式運作的時候 Stack 大小大于 JVM 的設定大小

解決方法：通過在啟動 Spark-sql 的時候加上 --driver-java-options “-Xss10m” 選項解決這個問題

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不帶分區重複執行不會出現問題

執行大資料量的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

Sparksql使用過程中Executor端抛出：java.lang.OutOfMemoryError: GC overhead limit exceeded

原因：這是由于大部分事件都在GC，導緻OOM。

解決方法：加大執行器記憶體，修改GC政策spark.executor.extraJavaOptions -XX:+UseG1GC

hiveserver2和SparkThriftServer使用操作orc表的時候報錯A使用者無法通路B使用者的目錄。

原因：這是由于orc 在進行Split過沖中會進行使用者緩存。ORC在hive1.2.1時的BUG，在hive2.X和Spark2.3.X版本後進行了解決

解決方法：暫時規避方法比較暴力，1、先使用超級使用者進行第一次查詢，導緻緩存的使用者為超級使用者。2、設定hive.fetch.task.conversion=none不進行緩存

spark-sql在使用過程中小資料量查詢很慢，檢視sparkUI顯示每個Task處理都很快，但是都隔了3秒進行排程導緻整體很慢。

原因：這是由于資料本地性導緻的，預設spark.locality.wait為3秒

解決方法：設定該參數為0即可加快速度，隻有在資料量較小的情況下才建議這樣設定。

二.Spark core相關

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

在使用Spark過程中出現：java.io.IOException: No space left on device

原因：一般是由于Spark的tmp目錄滿了導緻

解決方法：可以将該目錄空間設定大點，支援按逗号分割多個目錄：spark.local.dir

超出最大結果集：is bigger than spark.driver.maxResultSize (2.0GB)

原因：spark.driver.maxResultSize預設配置為1G

解決方法：調大該參數即可

常見OOM：java.lang.OutOfMemoryError: Java heap space

原因：1、資料量太大，申請的Executor資源不足以支撐。2.單分區的資料量過大，和分區數過多導緻執行task和job存儲的資訊過多導緻Driver OutOfMemoryError

解決方法：1、盡量不要使用collect操作。2、檢視資料是否有傾斜，增加shuffle的并行度，加大Executor記憶體

由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

jar包版本沖突時：java.lang.ClassNotFoundException: XXX

原因：一般可能是使用者jar和Spark jar沖突

解決方法：1、最好和Spark相關的jar進行适配。2、如果不行可以使用參數：spark.driver.userClassPathFirst和spark.executor.userClassPathFirst 設定為true

進行shuffle抛出：Shuffle Fetch Failed: OOM

原因：Shuffle fetch階段開啟的fetch資料量過大導緻

解決方法：1、加大Executor記憶體。2、将參數spark.reduce.maxSizeInFlight調小，預設48M

shuffle報org.apache.spark.shuffle.FetchFailedException: Direct buffer memory

原因：堆外記憶體不夠導緻，直接記憶體

解決方法：增大JVM 參數-XX:MaxDirectMemorySize（如：spark.executor.extraJavaOptions = -XX:MaxDirectMemorySize=xxxm）

叢集節點異常導緻Spark job失敗，如磁盤隻讀。

原因：Spark 是一個高性能、容錯的分布式計算架構，一旦它知道某個計算所在的機器出現問題會依據之前生成的 lineage 重新在這台機器上排程這個 Task，如果超過失敗次數就會導緻job失敗。

解決方法：Spark有黑名單機制，在超出一定次數的失敗後不會往該節點或者Executor排程Task。設定相應Black參數：spark.blacklist.enabled=true

三.Pyspark相關

driver python和Executor Python版本不一緻問題

原因：pyspark要求所有的Executor運作的python版本一緻

解決方法：指定python的運作路徑：spark.pyspark.python /data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python 或者 env配置上：export PYSPARK_PYTHON=/data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python；export PYSPARK_DRIVER_PYTHON=/data/Install/Anaconda2Install/Anaconda3-5.1.0/bin/python

Pyspark使用過程中出現：RDD時出現序列化pickle.load(obj)報錯，EOFError。有時可以，在local也可以。

原因：在on yarn時，機器上也有安裝相關的Spark。導緻包沖突

解決方法：删除nodeManager上的Spark安裝路徑就可以解決

運作RDD操作時報Randomness of hash of string should be disabled via PYTHONHASHSEED mean in pyspark

原因：這是由于各個Executor的Hash随機值不一樣導緻。

解決方法：隻需要指定各Executor的PYTHONHASHSEED環境變量即可如：–conf spark.executorEnv.PYTHONHASHSEED=321

四.Streaming相關

消費kafka時，第一個job讀取了現有所有的消息，導緻第一個Job處理過久甚至失敗

原因：auto.offset.reset設定為了earliest 從最早的offset開始進行消費，也沒有設定spark.streaming.kafka.maxRatePerPartition參數

解決方法：指定從之前開始消費的資料開始：設定offsetRange。并将參數設定為：auto.offset.reset=latest 設定Spark每個分區的速率。

盡量使用高性能算子

使用reduceByKey/aggregateByKey替代groupByKey

使用mapPartitions替代普通map

使用foreachPartitions替代foreach

使用filter之後進行coalesce操作

使用repartitionAndSortWithinPartitions替代repartition與sort類操作

Streaming如果存在多個Batch延遲時，消費不過來。有時會報出：Hbase相關的異常如：RegionTooBusyException

原因：Streaming在進行處理時如果單個Batch讀取的資料多，會導緻計算延遲甚至導緻存儲元件性能壓力

解決方法：1、如果是計算延遲試着調整讀取速率如：spark.streaming.kafka.maxRatePerPartition參數 2、調優存儲元件的性能 3、開啟Spark的反壓機制：spark.streaming.backpressure.enabled，該參數會自動調優讀取速率。但是如果設定了spark.streaming.receiver.maxRate 或 spark.streaming.kafka.maxRatePerPartition，那麼最後到底接收多少資料取決于三者的最小值

消費kafka時，讀取消息報錯：OffsetOutOfRangeException

原因：讀取的offsetRange超出了Kafka的消息範圍，如果是小于也就是kafka儲存的消息已經被處理掉了（log.retention.hours）。或者超出Kafka現有的offset

解決方法：在讀取offset時先進行校正，拿到offset的earliestOffset 和lastestOffset

Kafka抖動導緻No leader found

kafka變更或者其他原因導緻

解決方法：設定 spark.streaming.kafka.maxRetries 大于1

未完待續。