Spark SQL执行缓慢且资源闲置

时间：2019-03-24 01:30:08

标签： apache-spark pyspark-sql hdinsight

我有一个Spark SQL，它过去执行了不到10分钟，现在在集群迁移后3小时运行，需要深入研究其实际功能。我是新来的火花，请不要介意我是否在询问无关的内容。

spark.executor.memory增加了，但是没有运气。

Env：Azure存储上的Azure HDInsight Spark 2.4

SQL：读取并联接一些数据，最后将结果写入Hive元存储。

spark.sql脚本以以下代码结尾： .write.mode("overwrite").saveAsTable("default.mikemiketable")

应用程序行为： 在前15分钟内，它将加载并完成大多数任务（199/200）；只剩下1个执行程序，这个程序还活着，并在不断地改组读/写数据。因为现在只剩下1个执行程序，所以我们需要等待3个小时才能完成此应用程序。 enter image description here

只剩下1个执行者在世 enter image description here

不确定执行者在做什么： enter image description here

我们不时可以告诉我们随机播放的阅读次数有所增加： enter image description here

因此，我将spark.executor.memory增加到20g，但是没有任何变化。从Ambari和YARN中，我可以告诉集群剩余很多资源。 enter image description here

几乎所有执行者的发布 enter image description here

非常感谢任何指导。

1 个答案:

答案 0 :(得分：0)

我想从您的情况开始一些观察：

  1. 从任务列表中，您可以看到Shuffle Spill（磁盘）和Shuffle Spill（内存）都有很高的值。交换数据should not exceed 2GB期间每个分区的最大块大小，因此应注意将混洗后的数据大小保持尽可能低。根据经验，您需要记住每个分区的大小应为200-500MB。例如，如果总数据为100GB，则需要至少250-500个分区，以使分区大小保持在上述限制之内。
  2. 前两个的并存也意味着执行程序的内存不足，Spark被迫将数据溢出到磁盘上。
  3. 任务的持续时间太长。 normal task应该持续50-200ms。
  4. 被杀死的执行者太多是另一个迹象，表明您面临OOM问题。
  5. Locality是RACK_LOCAL，它被视为您可以在群集中实现的最低值之一。简而言之，这意味着任务正在与存储数据的节点不同的位置执行。

作为解决方案，我将尝试以下几件事：

  • 通过使用repartition()或通过带有spark.sql.shuffle.partitions的Spark设置将分区数量增加到满足上述要求的数量，即1000或更多。
  • 更改存储数据的方式并使用partitionBy引入分区数据，即日/月/年
相关问题
最新问题