我有一个工作，从s3读取gzip csv数据，进行一些处理并将其转储到parquet中。源代码几乎没有3gb大小的文件，所以当我以parquet格式转储它时，得到的是很少的2-3gb大小的snappy压缩parquet文件。
我知道这可以通过在写为parquet之前重新划分分区来解决，但这反过来又会导致诸如

Job aborted due to stage failure: org.apache.spark.memory.SparkOutOfMemoryError: error while calling spill() on org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter@230c5841 : No space left on device

我读到1gb被认为是Parquet文件的最佳尺寸（是一个大的Parquet文件还是很多小的Parquet文件更好？）。但是，我不清楚这背后的基本原理，如果读取巨大的Parquet文件会以任何方式降低性能（考虑到snappy压缩的Parquet文件是可拆分的）。
如果有巨大的文件不是一个问题，我不会使用重分区，因为这将涉及在分区之间的数据洗牌。