重新分配pyspark数据框失败,以及如何避免初始分区大小

时间:2019-02-25 11:51:15

标签: python pyspark apache-spark-sql apache-spark-2.3

我正在尝试通过在spark数据帧上使用分区来调整spark的性能。这是代码:

file_path1 = spark.read.parquet(*paths[:15])
df = file_path1.select(columns) \
    .where((func.col("organization") == organization)) 
df = df.repartition(10)
#execute an action just to make spark execute the repartition step
df.first()

在执行first()的过程中,我检查了Spark UI中的作业阶段以及在这里找到的内容: Job details stage 7 details

  • 为什么阶段中没有repartition步骤?
  • 为什么还会有第8阶段?我只要求执行first()的一项操作。是因为repartition引起的洗牌吗?
  • 有没有一种方法可以更改镶木地板文件的重新分区而不必进行此类操作?最初,当我读到df时,您可以看到它被划分为43k个分区确实很多(与将其保存到一个csv文件时的大小相比:4 MB的行有13000行),并且在进一步的步骤中产生了问题,这就是为什么我要对其重新分区。
  • 重新分区后应该使用cache()吗? df = df.repartition(10).cache()?就像我第二次执行df.first()时一样,尽管df.rdd.getNumPartitions()返回了10,但我也获得了包含43k分区的预定阶段。 编辑:分区数仅供参考。我的问题是为了帮助我理解如何进行正确的分区。

注意:最初,数据帧是从Hadoop中的一组镶木地板文件中读取的。

我已经将其作为参考文献How does Spark partition(ing) work on files in HDFS?

进行了阅读

1 个答案:

答案 0 :(得分:0)

  • 每当改组时,都会有一个新阶段。还有
    重新分区会导致改组,这就是为什么您有两个阶段的原因。
  • 当您多次使用数据框以使用缓存时, 避免阅读两次。

使用合并而不是重新分配。我认为这会减少改组,因为它只会减少分区数。