问题描述
我正在Databricks上运行一个笔记本,该笔记本创建分区的PySpark数据帧并将其上传到s3。该表具有约5,000个文件,总大小约为5 GB(需要以这种方式进行分区,以便Athena对其进行有效查询)。我的问题是,将文件写入s3似乎是顺序的,而不是并行的,可能要花费一个小时。例如:
df.repartition("customer_id")
.write.partitionBy("customer_id")
.mode("overwrite")
.format("parquet")
.save("s3a://mybucket/path-to-table/")
我已使用以下配置在AWS上启动了集群(i3.xlarge):
spark.hadoop.orc.overwrite.output.file true
spark.databricks.io.directoryCommit.enableLogicalDelete true
spark.sql.sources.commitProtocolClass org.apache.spark.sql.execution.datasources.sqlHadoopMapReduceCommitProtocol
parquet.enable.summary-Metadata false
spark.hadoop.fs.s3.maxRetries 20
spark.databricks.hive.metastore.glueCatalog.enabled true
spark.hadoop.validateOutputSpecs false
mapreduce.fileoutputcommitter.marksuccessfuljobs false
spark.sql.legacy.parquet.datetimeRebaseModeInRead CORRECTED
spark.hadoop.fs.s3.consistent.retryPeriodSeconds 10
spark.speculation true
spark.hadoop.fs.s3.consistent true
spark.hadoop.fs.s3.consistent.retryCount 5
在这种情况下,当我有很多小文件需要快速写入s3时,推荐的方法是什么?
解决方法
我看到您的写入速度缓慢且可以加快速度的几个原因:
- 您可能有超过5,000个客户?因此,使用by分区,您可能会有超过5,000个分区。由于元存储中的开销,使用Parquet(非Delta Lake表)时,这可能会非常慢。我认为您不需要这么多分区。
- 有5,000个5GB的文件,每个文件的大小约为1MB。这很小。针对此问题,您写出的文件大小应接近100MB。
- 默认集群选项经过精心设计,我很少需要更改它们,当我这样做时,我会启用新功能。您应该尝试解决上述问题,并删除设置上的所有这些替代。
- Repartition(“ customer_id”)和partitionBy(“ customer_id”)是多余的。
推荐:
- 要获取的文件大小最大约为100MB,如果上一阶段创建了超过50个分区,则可以使用coalesce()进行操作。
- 通过customer_id删除分区,也许您可能会认为有充分的理由,但是小文件和大量分区正在损害您的性能。
- 尝试使用开放的Delta Lake格式(例如
CREATE TABLE ... USING DELTA LOCATION ...
。这将加快您的客户选择查询的速度,如果您也OPTIMIZE ... ZORDER BY customer_id
,则会加快对customer_id的联接,并且可以自动优化文件的大小。
最终结果看起来更加简洁
df.coalesce(50)
.write
.mode("overwrite")
.format("delta")
.save("s3a://mybucket/path-to-table/")
请参见自动优化选项以自动调整文件大小:https://docs.databricks.com/delta/optimizations/auto-optimize.html#usage
Delta Lake表可以与Athena https://docs.databricks.com/delta/presto-integration.html#presto-and-athena-to-delta-lake-integration
一起使用 ,在s3存储桶上,您是否设置了fs.s3a.fast.upload = true
?我正在此link