火花Sql作业优化

Question

我有一个作业，它大约包含9条sql语句，用于从hive中提取数据并将其写回hive db。它目前运行3小时，这似乎太长，考虑火花的能力，以处理数据。应用程序启动总共11个阶段。

我使用Spark做了一些分析，发现下面的灰色区域可以改进：

• 工作5的第8阶段有1.5 TB的洗牌输出。
• 工作4和工作5之间的时间间隔是20分钟。我阅读了这个时间间隔，发现火花执行IO的火花作业，这反映了两个工作之间的差距，可以在司机日志中看到。

我们有一个由800个节点组成的集群，每个队列的资源都受到限制，我正在使用下面的conf提交作业：

• - num-executor 200 -- executor-core 1 -- executor-memory 6G -部署模式客户端

附加图像的UI以及。

现在我的问题是：

• 在哪里可以找到这份工作的司机日志？
• 在图像中，我看到了一个很长的执行者列表，其中我的和大于200，但是在Executor选项卡中，数字正好是200。

对此有什么解释吗？

• 在所有阶段中，只有一个阶段的任务在35000左右，其余阶段只有200个任务。我是应该增加执行者的数量，还是应该使用火花的动态分配机制？

Answer 1

以下是可能在某种程度上指导你的思维过程：

每个执行者有必要拥有一个核心吗？遗嘱执行人不必总是很胖。你可以在一个执行器里有更多的核心。这是在创造一个苗条的与肥胖的执行者之间的权衡。

配置混叠分区参数spark.sql.shuffle.partitions

确保在从Hive读取数据时，您使用的是Sparksession (基本上是HiveContext)。这将将数据从HDFS和Hive的Metastore中提取到Spark内存中。

是的，资源的动态分配是一项有助于分配正确资源集的功能。这总比有固定的分配好。