简单搞定Spark性能优化:常见异常解决（二）

第一部分内容链接：https://blog.youkuaiyun.com/github_36444580/article/details/117037685

 

11. ERROR shuffle.RetryingBlockFetcher: Failed to fetch block shuffle_7_18444_7412, and will not retry

原因：Executor被kill，无法拉取该block。可能是开启AE特性时数据倾斜造成的，其他executor都已完成工作被回收，只有倾斜的executor还在工作，拉取被回收的executor上的数据时可能会拉不到。

解决方法：如果确实是发生了数据倾斜，可以根据这两个链接的方法进行处理：（1）http://www.jasongj.com/spark/skew/；（2）https://www.cnblogs.com/hd-zg/p/6089220.html；

 

还可以参考《SparkSQL内核剖析》第11章第266页的几种SQL层面的处理方法，如下所示：

--广播小表

select /*+ BROADCAST (table1) */ * from table1 join table2 on table1.id = table2.id

--分离倾斜数据（倾斜key已知）

select * from table1_1 join table2 on table1_1.id = table2.id

union all

select /*+ BROADCAST (table1_2) */ * from table1_2 join table2 on table1_2.id = table2.id

--打散数据（倾斜key未知）

select id, value, concat(id, (rand() * 10000) % 3) as new_id from A

select id, value, concat(id, suffix) as new_id

from ( 

select id, value, suffix

from B Lateral View explode(array(0, 1, 2)) tmp as suffix

)

--打散数据（倾斜key已知）

select t1.id, t1.id_rand, t2.name

from (

select id ,

case when id = null then concat(‘SkewData_’, cast(rand() as string))

else id end as id_rand

from test1

where statis_date = ‘20200703’) t1

left join test2 t2

on t1.id_rand = t2.id

 

同时，适度增大spark.sql.shuffle.partitions参数，通过提高并发度的方式也可缓解数据倾斜。

 

12. org.apache.spark.memory.SparkOutOfMemoryError: Unable to acquire 65536 bytes of memory, got 0

原因：代码逻辑或任务参数配置不合理、数据倾斜等导致OOM。分为driver OOM和executor OOM。

 

解决方法：（1）查看代码中是否有coalesce()等函数，该函数相比repartition()不会进行shuffle，处理大分区易造成OOM，如果有则可换成repartition()，尽量减少coalesce()的使用。

 

                  （2）是否使用了将各executor上所有数据拉回到driver的collect()函数，尽量避免或谨慎使用collect()与cache()等函数，让各executor分布式拉数据与执行，多节点分担海量数据负载。

 

                  （3）代码中是否有超过5个连续join或多层嵌套for循环等不合理的代码逻辑，代码解析与相关对象序列化都是在driver端进行，过于冗余复杂不拆分的代码会造成driver OOM，可参考第10点优化。

 

                  （4）代码中是否广播了过大的表，可以合理设置spark.sql.adaptiveBroadcastJoinThreshold参数（以B为单位，默认10485760即10MB）；在业务代码逻辑极复杂、扫描文件数和数据量、task数等极端大（如几十万个）且广播阈值设置的再小也依然OOM，可以设置为-1关闭broadcast join。

 

                  （5）查看任务提交参数中--executor-cores与--executor-memory的比例是否至少为1：4，一个executor上的所有core共用配置的executor内存，如果有类似2core4G等情况存在，在数据量较大的情况下易OOM，至少应是1core4G或者2core8G等。

 

                  （6）个别executor的OOM也是数据倾斜会出现的现象之一，如果是这种情况可参考第11点解决。

 

                  （7）在代码逻辑和参数合理的前提下，最后一步才是适度增加资源，例如--executor-memory=8g、--driver-memory=4g等。

 

13. Caused by: Java.lang.ClassCastException:org.apache.hadoop.io.IntWritable cannot be cast to org.apache.hadoop.io.DoubleWritable

原因：下游Hive表在select from上游Hive表时，select的同名字段的类型不同。

解决方法：修改该下游Hive表的对应字段类型与上游表一致，alter table xxx change 原字段名 新字段名(可不变) 类型;

 

14. driver端频繁出现“Full GC”字样或“connection refused”等日志内容。

原因：与第12点OOM类似，driver端此时内存压力很大，无力处理与executor的网络心跳连接等其他工作。

 

解决方法：（1）查看是否有过于复杂不拆分不够优化的代码逻辑（如过多连续join），可参考第10点将不合理的代码拆分精简，在临时表中尽早过滤多余数据。

 

                  （2）如果数据量确实十分巨大，并非代码不够合理的原因，可以减小SparkSQL的broadcast join小表阈值甚至禁用该功能，增加参数set spark.sql.autoBroadcastJoinThreshold=2048000或-1等（默认为10M，根据具体数据量调整）。

 

                  （3）由于driver也负责application对应的spark ui网页状态维护，小文件过多会造成task数较多，在维护job执行进度时也会内存压力较大，可通过该博客来判断小文件现象：https://blog.youkuaiyun.com/qq_33588730/article/details/109353336

 

                  （4）改过代码也合理调参过了，最后才是增加driver端内存，--driver-memory=4g等。

 

15. Caused by: org.apache.spark.SparkException: This RDD lacks a SparkContext. It could happen in the following cases:(1) RDD transformations and actions are NOT invoked by the driver, but inside of other transformations; for example, rdd1.map(x => rdd2.values.count() * x) is invalid because the values transformation and count action cannot be performed inside of the rdd1.map transformation. For more information, see SPARK-5063.(2) When a Spark Streaming job recovers from checkpoint, this exception will be hit if a reference to an RDD not defined by the streaming job is used in DStream operations. For more information, See SPARK-13758.

原因：根据上面英文提示的原因，对RDD的transformation中嵌套transformation或action操作会导致计算失败。

 

解决方法：从报错那一行附近找到嵌套的transformation或action操作，将该嵌套逻辑独立出来。

 

16. removing executor 38 because it has been idle for 60 seconds

原因：一般为数据倾斜导致，开启AE特性后空闲下来的executor会被回收。

解决方法：与第11与第12点的解决方法类似，第10、11、12、16、17点的日志现象可能会有某几种同时出现。

 

17. Container killed by YARN for exceeding memory limits. 12.4 GB of 11GB physical memory used.

原因：（1）数据倾斜，个别executor内存占用非常大超出限制。

 

           （2）任务小文件过多，且数据量较大，导致executor内存用光。

 

           （3）任务参数设置不合理，executor数量太少导致压力负载集中在较少的executor上。

 

           （4）代码不合理，有repartition(1)等代码逻辑。

 

解决方法：（1）数据倾斜情况可以参考第11、12点。

 

                  （2）数据量很大可参考第10、14点。

 

                  （3）查看是否任务参数设置不合理，例如executor-memory是设的大，但是--num-executors设置的很少才几十个，可以根据集群情况和业务量大小合理增大executor数，数量判断标准是一个executor的CPU core同一时刻尽量只处理一个HDFS block的数据（如128或256M），在没有设置--executor-cores等参数的情况下，默认一个executor包含一个CPU core。

 

                  （4）查看代码中是否有如repartition(1)等明显不合理的逻辑。

 

                  （5）在代码性能与逻辑合理，且参数合理的前提下再增加资源，可增加对外内存：--conf  spark.yarn.executor.memoryOverhead=4096（单位为M，根据业务量情况具体设置）。

 

18. Found unrecoverable error returned Bad Request - failed to parse; Bailing out

原因：ES中有历史索引没删除。

解决方法：删除ES中的对应历史索引。

 

19. org.apache.spark.shuffle.FetchFailedException: Too large frame

原因：shuffle中executor拉取某分区时数据量超出了限制。

解决方法：（1）根据业务情况，判断是否多余数据量没有在临时表中提前被过滤掉，依然参与后续不必要的计算处理。

 

                  （2）判断是否有数据倾斜情况，如果是则参考第11、12点，或者通过repartition()进行合理重分区，避免某个分区内数据量过大。

 

                  （3）判断--num-executors即executor数量是否过少，可以合理增加并发度，使数据负载不集中于少量executor上，减轻压力。

 

20. 读写Hive表时报“Table or view not found”，但实际上Hive表在元数据库与HDFS上都存在。

解决方法：排除不是集群连接地址配置等原因后，查看代码中SparkSession建立时是否有加enableHiveSupport()，没加可能会无法识别到Hive表。

 

21. java.io.FileNotFoundException

原因：（1）除文件确实在对应HDFS路径上不存在以外，可能代码中前面有create view但数据来源于最后要insert的目标表，后面insert overwrite 目标表时又from这个view，因为Spark有“谓词下推”等懒执行机制，实际开始执行create view的transformation操作时，因为前面insert overwrite目标表删了目标表上的文件，所以相当于自己查询自己并写入自己，会造成要读的文件不存在。

 

           （2）由于Spark的内存缓存机制，短时间内该目录下文件有变动但缓存中的元信息未及时同步，依然以为有该文件，Spark会优先读取缓存中的文件元信息，如果和实际该目录下的文件情况不一致也会报错。

 

解决方法：（1）如果是上述的代码逻辑，可以不用create view，而是创建临时表落到磁盘，insert目标表时from临时表就可以了。

 

                  （2）可以在读写代码前面加上refresh table 库名.表名，这样就丢弃了该缓存信息，依然从磁盘实际文件情况来读。

 

22. org.apache.shuffle.FetchFailedException: Connect from xxx closed

原因：一般是数据倾斜导致，其他executor工作完成因闲置被回收，个别负载大的executor拉其他executor数据时拉不到。

解决方法：可参考第11点，加上参数，set spark.sql.adaptive.join.enabled=true和set spark.sql.adaptive.enabled=true，并根据业务数据量合理设置spark.sql.adaptiveBroadcastJoinThreshold即broadcast join的小表大小阈值。

 

23. caused by:org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get the locations

原因：如果地址配置等都正确，一般就是大数据平台对HBase组件的连接并发数有限制，导致大量SparkSQL任务连接HBase时有部分任务会连接超时。

解决方法：检查代码与任务中的HBase连接配置等属性是否正确，若正确则直接请教负责HBase组件的平台开发人员。

 

24. sparksql在某个stage长时间跑不动，但task很少，数据量也不大，且代码逻辑只是简单的join，如下现象所示：

 

原因：点进该stage的链接查看细节现象，发现stage中各task的shuffle read数据量不大，但shuffle spill数据量大得多，如下所示：

 

可以判定该join操作可能发生了笛卡尔积，join on中的两个字段各自都有很多重复值不唯一，会导致这种情况。

 

解决方法：加上参数，set spark.sql.adaptive.shuffle.targetPostShuffleInputSize=64000000能够缓解这种现象，根本上依然是根据业务逻辑进行字段值去重、避免重复字段值参与join等。

 

未完待续。。。