Databricks中分区前排序DataFrame对性能有影响吗？求最优分区方案

一、预排序对计算速度与资源消耗的影响 #

先执行orderBy再分区写入的操作，写入阶段的资源消耗更高、速度更慢：orderBy会触发Spark的Shuffle操作，需要额外的磁盘I/O、网络传输来完成数据重排序，数据量越大，Shuffle的开销越明显。

二、Databricks能否识别分区内的排序状态加速读取？ #

不能。Spark（Databricks基于Spark）不会自动追踪分区内部数据的有序性。即便分区内movie_name是有序的，执行filter(year='xxx', movie_name='yyy')这类查询时，Spark依然会扫描该year分区下的所有数据文件，无法利用内部有序性实现数据跳过——原生Parquet/CSV数据源不支持记录文件内部的排序元数据。

因此你提供的第一段代码并不优于后者，反而增加了写入成本，读取阶段也没有任何性能收益。

三、针对year+movie_name高频过滤的最优分区方案 #

由于movie_name基数过高无法作为分区列，推荐以下两种适配场景的方案：

• 方案1：分区+分桶（适用于非Delta Lake场景）
  按year做分区，同时对movie_name进行分桶。分桶会将相同movie_name的数据哈希到固定数量的桶文件中，过滤特定year+movie_name时，Spark仅需扫描对应year分区下的目标桶文件，无需遍历整个分区，大幅减少数据扫描量。
  示例代码：

  df.write
    .partitionBy("year")
    .bucketBy(32, "movie_name") // 分桶数量建议设为集群核心数的2-4倍，根据数据规模调整
    .mode("overwrite")
    .parquet("dbfs:/FileStore/movies_bucketed")
  

  注意：分桶仅支持Parquet、ORC等列式格式，CSV不支持分桶功能。

• 方案2：分区+Z-Order索引（Databricks Delta Lake专属）
  如果使用Databricks Delta Lake（生产环境推荐），可以利用Z-Order索引优化多列过滤。按year分区后，在每个分区内对movie_name做Z-Order排序，Delta会自动追踪索引元数据，查询时跳过不匹配的数据文件。
  示例代码：

  // 写入Delta表并按year分区
  df.write
    .partitionBy("year")
    .mode("overwrite")
    .format("delta")
    .save("dbfs:/FileStore/movies_delta")
  
  // 对分区内的movie_name创建Z-Order索引
  spark.sql("OPTIMIZE dbfs:/FileStore/movies_delta ZORDER BY (movie_name)")
  

  Z-Order会在分区内将相关数据物理聚集，且Optimize操作是增量式的，避免了写入阶段全量Shuffle的开销。

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