EMR 和 S3 上的 Delta Lake (OSS) 表 - 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：作业之间的长时间延迟，这似乎表明它可能与镶木地板有关？但我在增量方面没有看到任何选项来调整任何参数。

Answer 1

我还观察到 Delta 真空命令非常慢。开源开发人员可能无法在存储库中进行特定于 AWS 的优化，因为该库是跨平台的（需要在所有云上工作）。

我注意到真空在当地甚至很慢。您可以克隆 Delta 存储库，在本地计算机上运行测试套件，然后亲自查看。

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

假设您的目标是创建 1GB 文件。也许您有 15,000 个 1 GB 文件和 20,000 个小文件。现在，您的压缩操作正在重写所有数据（因此所有 35,000 个原始文件都需要在压缩后进行清理）。尝试重构代码以仅压缩 20,000 个小文件（因此清理操作只需要删除 20,000 个文件）。

真正的解决方案是构建一个针对 AWS 优化的真空命令。Delta Lake 需要与所有流行的云和本地文件系统配合使用。制作一个开源库应该非常容易，它可以读取事务日志，找出需要删除的文件，进行高性能文件删除 API 调用，然后将一个条目写入符合 Delta 的事务日志。也许我会做那个回购；）

以下是有关真空命令的更多信息。作为旁注，您可以使用coalesce而不是repartition在压缩时使用，如此处所述。

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