我正在使用S3中的一个高度嵌套的不可拆分的JSON格式输入数据集。文件的大小可以有很大的不同-最小为10 KB，而其他为300 MB。
当使用下面的代码阅读文件时，并且仅仅进行简单的重新分区以获得所需数量的分区会导致任务分散-大多数任务在几秒钟内完成，但有一个任务会持续几个小时，然后遇到内存问题（心跳丢失/堆空间等）我重新分区是为了随机化分区到文件的Map，因为spark可能按顺序阅读文件，而同一目录中的文件往往具有相同的性质-均为大/均为小等。

df = spark.read.json('s3://my/parent/directory')
df.repartition(396)
# Settings (few):
default parallelism = 396
total number of cores = 400

我尝试的：

1.我认为输入分区（s3分区而不是spark）方案（文件夹层次结构）可能会导致这种分区倾斜的问题，其中一些s3文件夹（技术上的“前缀”）只有一个文件，而其他文件夹有数千个，所以我使用hashcode将输入转换为扁平的目录结构，其中每个文件夹只有一个文件：

之前：

/parent1
             /file1
             /file2
             .
             .
             /file1000
/parent2/
           /file1

现在：

hashcode=FEFRE#$#$$#FE/parent1/file1
   hashcode=#$#$#Cdvfvf@#/parent1/file1

但是没有任何效果。
1.我也尝试过使用非常大的集群--认为即使存在输入偏差--那么多的内存应该能够处理更大的文件，但我仍然陷入了零散的任务中。
当我检查文件数量时（每个文件由于其嵌套-不可拆分的性质而成为 Dataframe 中的一行）分配给每个分区-我看到分配的文件数量在2到32之间。这是因为Spark基于spark.sql.files.maxPartitionBytes在分区中拾取文件-并且可能它只分配两个文件大小巨大的文件，而当文件大小较小时，单个分区中的文件会多得多？
任何建议，使工作正常工作，并分配任务均匀-给定大小的输入文件是不能改变的东西，由于输入文件的性质。