EMR和S3上的三角洲湖（OSS）表-真空需要很长时间，没有工作

Question

我正在使用开源版本将大量数据写入Databricks Delta lake，该版本在AWS EMR上运行，S3作为存储层。我正在使用EMRFS。

为了提高性能，我每隔一段时间就会压缩和清空表：

    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)

我已经阅读了这篇文章火花：作业之间的长延迟，这似乎表明它可能与镶木地板有关？但是我在增量端没有看到任何选项来调整任何参数。

Answer 1

在Deltalake有这个的存档

问题陈述：Deltalake真空作业需要太长时间才能完成，因为下面的文件删除逻辑是顺序的。deltalake（v0.6.1）的已知错误参考：https://github.com/delta-io/delta/issues/395

解决方案：Deltalake 团队已解决此问题

对于 v0.6.x

许多组织在生产中使用0.6.x

https://swapnil-chougule.medium.com/delta-with-improved-vacuum-patch-381378e79d1d

通过这一更改，在真空作业期间支持并行删除文件。它加快了进程

Answer 2

我还观察到Delta真空指令相当慢。开源开发者在回购中进行AWS特定的优化可能会受到限制，因为这个库是跨平台的(需要在所有云上工作)。

我注意到局部真空甚至很慢。您可以克隆Delta repo，在您的本地机器上运行测试套件，并亲自查看。

即使您使用的是AWS CLI，删除S3中存储的数十万个文件也很慢。您应该看看是否可以重构压缩操作，以创建更少需要清空的文件。

假设您的目标是创建1GB文件。也许你有15000个单曲文件和20000个小文件。现在，您的压缩操作正在重写所有数据（因此，压缩后需要对所有35000个原始文件进行真空处理）。尝试重构代码，使其只压缩20000个小文件（因此真空操作只需要删除20000个文件）。

真正的解决方案是构建针对 AWS 优化的真空命令。Delta Lake 需要与所有流行的云和本地文件系统一起工作。创建一个开源库应该很容易，该库读取事务日志，确定需要删除的文件，进行高性能文件删除 API 调用，然后将符合 Delta 标准的事务日志写出条目。也许我会让那个回购;)

下面是关于真空命令的更多信息。作为一个附带说明，您可以在压缩时使用合并而不是repartition，如本文所述。

编辑：三角洲问题：https://github.com/delta-io/delta/issues/395和公关：https://github.com/delta-io/delta/pull/416