我正在使用开源版本将大量数据写入databricks delta lake，运行在aws emr上，s3作为存储层。我在用电子病历。
为了提高性能，我每隔一段时间就对table进行压缩和吸尘，就像这样：
spark.read.format("delta").load(s3path)
.repartition(num_files)
.write.option("dataChange", "false").format("delta").mode("overwrite").save(s3path)
t = DeltaTable.forPath(spark, path)
t.vacuum(24)然后从s3中删除10万个文件。然而，真空步骤需要非常长的时间。在此期间，作业似乎处于空闲状态，但每隔5-10分钟就会有一个小任务指示作业处于活动状态并正在执行某些操作。
我读过这篇博文《Spark：工作之间的长时间延迟》，这似乎表明这可能与Parquet地板有关？但我看不到任何选项在三角洲方面调整任何参数。
2条答案
按热度按时间vuktfyat1#
我还观察到delta真空指令非常慢。开源开发人员在repo中进行特定于aws的优化可能受到限制，因为这个库是跨平台的（需要在所有云上工作）。
我注意到局部的真空甚至很慢。您可以克隆delta repo，在本地计算机上运行测试套件，然后自己查看。
删除存储在s3中的数十万个文件很慢，即使您使用的是awscli。您应该看看是否可以重构压缩操作以创建更少的需要清空的文件。
假设您的目标是创建1gb文件。也许你有15000个单文件和20000个小文件。现在，压缩操作正在重写所有数据（因此压缩后需要清空所有35000个原始文件）。试着重构代码，只压缩20000个小文件（因此真空操作只需要删除20000个文件）。
真正的解决方案是建立一个为aws优化的真空命令。delta lake需要与所有流行的云和本地文件系统一起工作。创建一个开源库应该很容易，它可以读取事务日志，找出需要删除的文件，调用performant文件删除api，然后向事务日志中写入符合delta的条目。也许我会做回购；）
这里有更多关于真空命令的信息。作为旁注，您可以使用
coalesce而不是repartition压实时，如此处所述。编辑：增量问题：https://github.com/delta-io/delta/issues/395 和公关：https://github.com/delta-io/delta/pull/416
o75abkj42#
在deltalake有一个问题
问题陈述：deltalake真空作业需要很长时间才能完成，因为下面的文件删除逻辑是连续的。deltalake的已知错误（v0.6.1）参考：https://github.com/delta-io/delta/issues/395
解决方案：deltalake团队已经解决了这个问题&还没有发布稳定的版本。拉取请求：https://github.com/delta-io/delta/pull/522
对于v0.6.x
很多组织都在生产中使用0.6.x&希望它成为0.6.x的一部分。下面是使用此修补程序生成delta0.6.1jar的快速步骤
https://swapnil-chougule.medium.com/delta-with-improved-vacuum-patch-381378e79d1d
通过此更改，真空作业期间支持并行删除文件。它加快了进程并缩短了执行时间