我认为任何使用过spark的人都会遇到oom错误，通常问题的根源很容易找到。然而，我有点困惑于这一点。目前，我正在尝试使用 partitionBy 功能。它看起来像下面这样（虚构的名字）：

df.write.partitionBy("account", "markers")
  .mode(SaveMode.Overwrite)
  .parquet(s"$location$org/$corrId/")

这个特定的Dataframe有大约30gb的数据、2000个帐户和30个标记。帐户和标记几乎均匀分布。我试过使用亚马逊r4.8XL（220+gb内存）的5个核心节点和1个主节点驱动程序，默认的最大化资源分配设置（执行器2倍的核心和165gb左右的内存）。我还明确地设置了内核的数量，执行器的数量不同，但有相同的问题。当我观察神经节时，我没有看到任何过度的内存消耗。
因此，根本原因似乎很可能是洗牌时可能发生的2gb bytearraybuffer问题。然后我尝试用不同的数字重新划分Dataframe，比如100、500、1000、3000、5000和10000，但没有成功。作业偶尔会记录堆空间错误，但大多数情况下会出现节点丢失错误。当查看单个节点日志时，它似乎突然失败，没有问题的迹象（这对于某些异常并不奇怪）。
对于Dataframe写入，partitionby是否有一个技巧来传递内存堆空间错误？