Spark 谓词下推性能答案

【问题标题】：Spark predicate pushdown performanceSpark 谓词下推性能
【发布时间】：2019-01-21 22:12:06
【问题描述】：

我将镶木地板文件按日期存储在以下目录中的分区中：

/activity
    /date=20180802

我使用的是 Spark 2.2，有 400 多个分区。我的理解是谓词下推应该允许我运行如下查询并获得快速结果。

spark.read.parquet(".../activity")
    .filter($"date" === "20180802" && $"id" === "58ff800af2")
    .show()

但是，上面的查询大约需要 90 秒，而下面的查询大约需要 5 秒。 我做错了什么还是这是预期的行为？

spark.read.parquet(".../activity/date=20180802")
    .filter($"id" === "58ff800af2")
    .show()

【问题讨论】：

您是否尝试过连续多次运行查询？第一个要慢得多，因为 Spark 需要扫描所有分区。此外，可能值得调用 .explain() 来查看计划并验证过滤器是否确实按预期下推。
我最初误解了这个问题，太仓促了。我想知道谓词下推是否真的在这里有效。这不是 SPARK SQL，而是 spark.read 非 JDBC。
关于 SO 的一些有趣陈述的有趣问题。我认为丹尼斯有答案，因为您使用的不是 SQL 语句而是 spark.read。也就是说，人们会期待更智能的性能，但是......
stackoverflow.com/questions/37180073/… 请注意给出的示例和丹尼斯的回答，我认为这可以解释。
我想我们也在这里讨论分区修剪。

【解决方案1】：

我也注意到了这一点，talked about it at a Spark Summit presentation。

Spark 执行昂贵的文件列表操作，这确实会减慢速度。 Spark 不擅长列出文件。我已经将 Spark 文件列出时间与 AWS CLI 进行了比较，但不知道为什么 Spark 列出文件需要这么长时间。

您应该将“我的理解是谓词下推...”改写为“我的理解是分区过滤器...”。谓词下推过滤不同。

这也是an issue with Delta Data lakes。 Delta 数据湖实际上更糟糕，因为您提到的避免文件列表的解决方法不适用于 Delta。

简而言之，您没有做错任何事情，这是预期的行为。您只有 400 个分区，因此在您的情况下，不必要的文件列表并不是那么糟糕。想象一下，当您有 20,000 个分区时，这会变得多么慢！

【讨论】：

【解决方案2】：

试试这个，看看谓词下推和分区修剪是否有效：

val df = spark.read.parquet(".../activity")
df.filter($"date" === "20180802" && $"id" === "58ff800af2").explain(true)

在生成的物理计划中查找 PushedFilter[ ...] 和 PartitionFilters [ ...]。这将告诉您第一部分不起作用的原因。但我不确定如何解决它，因为我面临着类似和奇怪的事情，但尚未解决。

【讨论】：