如何优化Databricks中Delta表大DataFrame的写入性能？

1. 排查分区分布合理性 #

用df.groupBy('id_date').count().show()统计每个日分区的记录数：

• 如果存在单个分区数据量远超其他分区（比如单分区占总数据量10%以上），说明分区粒度太粗，建议拆分分区键（例如加上小时维度id_date + hour），避免单分区任务负载过高拖慢整体写入。
• 如果多数分区数据量过小（比如单分区不足1GB），会增加Delta元数据操作的开销，可考虑合并分区粒度（比如按周/月分区），或者调整写入逻辑减少小分区生成。

2. 调优Spark作业资源与并行度 #

• Executor配置：根据集群可用资源增加Executor数量、提升Executor内存和核心数。比如针对1.2亿条数据的任务，可尝试设置--num-executors 30 --executor-memory 16G --executor-cores 4（具体数值需结合集群规模调整），提升并行处理能力。
• Shuffle分区数：默认spark.sql.shuffle.partitions=200对超大规模数据来说太少，建议调整为每个Shuffle分区处理128MB左右数据的数值（比如1.2亿条数据约120GB的话，设为1000），避免单任务处理数据量过大导致超时。

3. 写入前合并小文件 #

如果读取源数据后生成大量小文件（单文件小于64MB），写入前先合并：

• 用df.repartition(col('id_date'), 10)按分区键重分区，让每个分区生成固定数量的文件（比如10个），控制单文件大小在64MB-256MB之间，减少Delta写入时的文件操作开销。
• 若数据分布均匀，也可以用df.coalesce(n)直接减少文件数（不会触发Shuffle，性能更高），但注意coalesce不能增加文件数。

4. 优化Delta写入模式与属性 #

• 动态分区覆盖：如果是overwrite模式且仅更新部分分区，一定要设置spark.sql.sources.partitionOverwriteMode=dynamic，这样Spark只会覆盖需要更新的分区，而非全表重写，能大幅降低IO耗时。
• 验证AutoOptimize生效：确认delta.autoOptimize.optimizeWrite=true和delta.autoOptimize.autoCompact=true已正确配置，并且写入前的文件大小符合AutoOptimize触发条件（默认几个文件apsRead Highway challengeavingOM）Go SaveAfter link father，这是一个很好的例子，说明如何使用面向对象编程来解决问题。不对，直接说：并且写入前的文件大小符合AutoOptimize触发条件（默认单文件小于64MB时会合并）。如果写入前已经合并了文件，AutoOptimize的效果会更明显。
• 关闭Schema合并：如果不需要合并Schema，设置spark.sql.mergeSchema=false，避免写入时的Schema校验开销。

5. 排查并解决数据倾斜 #

如果某个分区的写入任务耗时远高于其他分区，大概率是数据倾斜：

• 打开Spark UI的Stage页面，查看任务执行时间分布，定位耗时最长的任务对应的分区键。
• 针对倾斜分区，可单独拆分处理：比如把大分区的数据单独提取出来，分成多个子任务写入，再合并其他小分区的写入结果。

6. 优化数据格式与压缩 #

• 精简数据类型：把不必要的宽类型改成紧凑类型，比如将字符串格式的日期转为date类型，减少数据存储体积，降低IO开销。
• 确认压缩配置：确保Delta表使用Snappy压缩（默认配置），也可通过spark.sql.parquet.compression.codec=snappy明确设置，减少磁盘IO量。

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