Delta (OSS)在电子病历和S3上的表格- Vacuum需要很长时间才能找到工作

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)

然后，它会从S3中删除10万个文件。然而，真空步骤需要极长的时间。在这段时间内，作业看起来是空闲的，但是每隔5-10分钟就会有一个小任务，表明作业是活动的并且正在做一些事情。

​

我通读了这篇文章，Spark: long delay between jobs似乎暗示它可能与拼花有关？但我在增量端看不到任何调整参数的选项。

Answer 1

我还观察到Delta vacuum命令相当慢。开源开发人员可能会受到限制，无法在存储库中进行AWS特定的优化，因为这个库是跨平台的(需要在所有云上工作)。

我注意到本地的吸尘器速度甚至很慢。您可以克隆Delta代码库，在本地计算机上运行测试套件，并亲自查看。

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

假设您的目标是创建1 1GB的文件。也许您有15,000个1G文件和20,000个小文件。现在，您的压缩操作正在重写所有数据(因此需要在压缩后清理所有35,000个原始文件)。尝试重构您的代码，使其只压缩20,000个小文件(这样vacuum操作只需要删除20,000个文件)。

真正的解决方案是构建一个针对AWS进行优化的vacuum命令。Delta Lake需要与所有流行的云和本地文件系统协同工作。应该很容易创建一个开源库，它读取事务日志，确定需要删除哪些文件，执行文件删除API调用，然后将符合Delta的条目写到事务日志中。也许我会做回购;)

这是more info on the vacuum command。顺便提一下，你可以在压缩时使用coalesce而不是repartition，as described here。

编辑:德尔塔问题：https://github.com/delta-io/delta/issues/395和PR：https://github.com/delta-io/delta/pull/416

Answer 2

在deltalake中有一个问题被提出

问题陈述: Deltalake vacuum作业需要太长时间才能完成，因为底层文件删除逻辑是顺序的。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的一部分。以下是使用此修补程序生成增量0.6.1JAR的快速步骤

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

通过此更改，在vacuum作业期间支持文件的并行删除。它加快了处理速度，减少了执行时间