在Databricks中将gzip文件保存为Hive表耗时过长问题咨询

读取阶段优化 #

• gzip属于不可分割的压缩格式，单个gzip文件默认只能使用1个CPU核心读取，这是本次任务的核心性能瓶颈：60GB的单文件哪怕集群配置再高，读取阶段也只能跑1个任务，耗时会非常久。如果条件允许，建议提前将大的gzip文件拆分为多个小gzip分片，每个分片解压后大小控制在128MB~256MB，即可实现多任务并行读取。
• 若无法拆分源文件，读取完成后立刻手动重分区，充分利用集群并行能力，分区数建议设置为集群核心数的1~2倍，你的112核集群可以设置为224个分区：

  df = df.repartition(224)
  

• 读取CSV时显式指定Schema，禁止使用Spark自动推断Schema功能：自动推断需要全量扫描一遍源文件，会额外消耗大量时间。你可以提前根据源文件的字段定义好Schema再传入读取接口，示例如下：

  from pyspark.sql.types import StructType, StringType, IntegerType
  # 请根据Papers.txt的实际字段结构调整下面的Schema定义
  custom_schema = StructType() \
      .add("paper_id", StringType(), nullable=True) \
      .add("title", StringType(), nullable=True) \
      .add("publish_year", IntegerType(), nullable=True)
  df = spark.read.csv(".../Papers.txt.gz", sep="\t", schema=custom_schema)
  

• 如果该DataFrame后续还会被多次使用，可以在读取完成后做持久化，避免重复计算：

  from pyspark import StorageLevel
  df.persist(StorageLevel.MEMORY_AND_DISK)
  

写入阶段优化 #

• 写入前调整分区数，控制输出文件大小：建议每个输出文件大小控制在512MB_{1GB左右，60GB的总数据可以调整为60}120个分区再写入，避免生成大量小文件影响后续Hive查询性能。
• 优先使用列式存储格式写入，不要直接存储为文本格式：Parquet/ORC等列式存储不仅占用空间更小，后续Hive查询性能也远高于文本格式，还可以搭配Snappy压缩进一步降低存储开销，示例代码如下：

  df.write \
    .format("parquet") \
    .option("compression", "snappy") \
    .mode("overwrite") \
    .saveAsTable("your_target_hive_table")
  

• 如果你使用的是高版本Databricks，建议开启自适应查询执行（AQE）功能，它会自动优化数据倾斜、动态调整分区数，大幅提升写入性能：

  spark.conf.set("spark.sql.adaptive.enabled", "true")
  

• 如果不需要写入分区表，可以提前关闭Hive动态分区功能，减少不必要的开销：

  spark.conf.set("hive.exec.dynamic.partition", "false")
  

集群配置优化 #

• 调整shuffle分区数参数，匹配你的集群规格：spark.sql.shuffle.partitions默认值为200，你的112核集群可以调整为224，避免shuffle阶段并行度不足或者任务过多产生额外调度开销。
• 合理配置Executor规格：建议单个Executor分配4~8核、32GB左右内存，避免单个Executor资源过大导致GC开销过高。
• 确认存储层IO性能：如果源文件和目标表都存储在对象存储中，确认集群开通了高吞吐访问权限，避免网络IO成为瓶颈。

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