尝试在 aws emr 上另存为表时触发作业超时答案

【问题标题】：spark job timing out when trying to save as table on aws emr尝试在 aws emr 上另存为表时触发作业超时
【发布时间】：2020-12-03 02:42:12
【问题描述】：

我们在 AWS 上为我们的应用程序设置了一个专用集群。

这是核心的配置（我们有2个核心）

m5.xlarge
4 vCore, 16 GiB memory, EBS only storage
EBS Storage:64 GiB

当前数据集 -

我们正在尝试运行涉及许多连接并处理 8000 万条记录的 spark 作业每条记录有 60 多个字段

我们面临的问题 -

当我们尝试将最终数据帧保存为 athena 表时，它需要超过 1 小时并超时。

由于我们是唯一使用集群的人，我们应该如何配置以确保我们以最佳方式使用所有集群资源

当前配置

Executor Memory : 2G
Dynamic Allocation Enabled : true
Number of Executor Cores : 1
Number of Executors : 8
spark.dynamicAllocation.executorIdleTimeout : 3600
spark.sql.broadcastTimeout : 36000

【问题讨论】：

我遇到了同样的问题，在写入表格之前在最终数据帧上添加更多分区已解决。你是在 S3 上写这张表吗？一个好的起点是以 parquet 格式为每个分区节省 1GB。

标签： amazon-web-services apache-spark pyspark amazon-emr

【解决方案1】：

看看你的配置一些观察 -

你正在使用

m5.xlarge 拥有 4 个 vCore、16 GiB 内存

执行器配置

执行器核心数：1
执行器内存：2G

所以最多可以启动 4 个 executor，4 个 executor 需要的内存是 8 个。所以最后你并没有利用所有的资源。

也正如@Shadowtrooper 所说，如果可以的话，将数据保存在分区中（如果可能的话以 Parquet 格式），在 Athena 中查询时也会节省成本。

【讨论】：

很好的答案，用户在 Spark 中进行 IO 时没有使用所有内核并且他们的工作失败或运行很长时间是很常见的。当spark充分利用资源时，不仅程序速度快，而且节省了大量的云成本。