【问题标题】:Spark Sql Job optimizationSpark Sql 作业优化
【发布时间】:2018-09-30 18:46:03
【问题描述】:

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

我使用 Spark UI 做了一些分析,发现以下灰色区域可以改进:

  • 作业 5 中的第 8 阶段具有 1.5 TB 的随机输出。
  • 作业 4 和作业 5 之间的时间间隔为 20 分钟。我读到了这个时间间隔,发现 spark 执行 IO 超出 spark 作业,这反映了两个作业之间的间隔,可以在驱动程序日志中看到。

我们有一个由 800 个节点组成的集群,每个队列的资源有限,我使用下面的 conf 提交作业:

  • --执行人数 200 -- 执行器核心 1 -- 执行器内存 6G -- 部署模式客户端

也附上 UI 的图片。

现在我的问题是:

  • 我在哪里可以找到这项工作的驱动程序日志?
  • 在图片中,我看到一长串添加的 Executor,我总和超过 200,但在 Executor 选项卡中,数字正好是 200。对此有何解释?
  • 在所有阶段中,只有一个阶段的 TASK 约为 35000,而其余阶段只有 200 个任务。我应该增加执行者的数量还是应该使用 spark 的动态分配工具?

【问题讨论】:

  • 这 9 条单独的 SQL 语句是针对 HDFS 中的同一张表还是 N 表?
  • 前两个 SQL 从主表拉数据到一个公用表。查询的其余部分使用公用表根据过滤条件生成输出。

标签: apache-spark pyspark apache-spark-sql


【解决方案1】:

以下是可以在一定程度上指导你的思维过程:

每个执行器必须有一个核心吗?执行者不必总是很胖。您可以在一个执行器中拥有更多核心。这是创建苗条与肥胖执行者之间的权衡。

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

确保从 Hive 读取数据时,您使用的是 Sparksession(基本上是 HiveContext)。这会将 HDFS 中的数据和 Hive 的 Metastore 中的模式信息拉入 Spark 内存。

是的,资源的动态分配是一种有助于分配正确资源集的功能。这比固定分配要好。

【讨论】:

    猜你喜欢
    • 2020-02-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-02-03
    • 1970-01-01
    相关资源
    最近更新 更多