Spark懒加载下rdd.getNumPartitions()准确性及动作前后差异问询

1. 为什么rdd.getNumPartitions()能在动作算子前返回正确值？ #

Spark的懒执行机制仅针对数据计算逻辑，而RDD/DataFrame的核心元数据（包括分区数量、分区策略等）是在构建转换算子的阶段就已确定的，不需要触发实际计算：

• 对于读取数据源的操作（比如你的read_file）：Spark会根据数据源的物理特性直接推导分区数——比如S3文件按文件块大小拆分、本地文件按默认规则拆分，这些信息在读取时就存入了DataFrame的元数据。
• 对于join这类shuffle转换：分区数由Spark的spark.sql.shuffle.partitions配置决定（你这里得到56，应该是修改过该配置的默认值），在构建df_main的转换逻辑时，Spark就已经确定了shuffle后的分区数并写入元数据。

getNumPartitions()只是直接读取这些预先生成的元数据，不需要触发任何实际数据计算，所以能在count()这类动作算子执行前返回正确结果。

2. 动作算子执行前后，DataFrame的分区数会不会变化？ #

大部分情况下，像count()这类仅触发计算的动作算子，不会修改原DataFrame的元数据，所以分区数不会改变（就像你的测试结果，df_main的分区数始终是56）。但存在以下几种特殊场景，会导致后续操作中分区数变化：

• 显式执行重分区转换：比如调用df.repartition(10)或df.coalesce(5)，这些转换会生成新的DataFrame，新对象的分区数会改变，但原DataFrame的分区数依然保持不变。
• 开启自适应执行（Adaptive Execution）：如果开启了spark.sql.adaptive.enabled=true，Spark在执行动作时会根据实际数据量动态调整shuffle分区数，但这只是执行阶段的临时调整，原DataFrame的getNumPartitions()返回的还是元数据中记录的初始分区数，实际执行的分区数可能不同。
• 数据源发生变更后重新读取：如果动作执行后，数据源文件被修改、新增或删除，重新读取该数据源会生成新的DataFrame，分区数可能变化，但原有的df_main分区数不会受影响。

示例代码（显式重分区场景） #

df_main = df2.join(df1, [df2['TransactionID'] == df1['TransactionID']], 'inner')
print('原分区数:', df_main.rdd.getNumPartitions())  # 输出56
df_repartitioned = df_main.repartition(10)
print('重分区后新DF的分区数:', df_repartitioned.rdd.getNumPartitions())  # 输出10
print('原DF分区数仍不变:', df_main.rdd.getNumPartitions())  # 还是56

内容的提问来源于stack exchange，提问作者kyl