AWS Glue 3.0：即使重新分区后，分区计数也会自行更改

Question

我有一项作业在 AWS Glue 3.0 上与 G.8x 工作人员一起运行。我正在使用 100 名工人 配置。 在最近的运行中，

count()

导致 OOM，我发现重新分区可能会有所帮助。

我读到我们必须保留

partition count = data set size /128 MB

我决定使用 32 个分区，因为每个工作线程有 32 个 vCPU。

我通过了作业。但即使我将重新分区计数设置为 32 或 3200，我也没有看到任何差异。 我的假设 - 3200 是一个很好的数字，因为

1. 每个执行器有 32 个 vCPU
2. 分区数量如果是核心数量的倍数就很好

我的第一个问题：这个重新分区策略是否正确，我的数据集大小约为3GB。

主要问题：重新分区后会发生一系列连接，然后如果我检查

df.rdd.getNumPartitions()

，我可以看到分区计数是我最初设置的一些随机数。 对于一次运行，即使我将其设置为 320，连接后的分区数仍为 6123。 我发现很难理解这种行为背后的原因。

Answer 1

.count() 确实会收集驱动程序节点上的结果，这会导致 OOM 问题。

您的数据集只有 3GB，您不需要 Spark 来处理它。

关于重新分区的问题： 如果您运行需要在节点之间进行洗牌的广泛转换，Spark 会再次重新分区数据以在执行器上运行。您可以通过设置

sparkContext.setConf("spark.sql.shuffle.partitions", "3200")

来更改此设置