Parquet谓词下推在使用Spark非EMR的S3上有效吗？

Question

只是想知道Parquet谓词下推是否也适用于S3，而不仅限于HDFS。具体来说，如果我们使用Spark（非EMR）。

进一步的解释可能会有所帮助，因为它可能涉及对分布式文件系统的理解。

Answer 1

我本人对此很纳闷，所以我只是对其进行了测试。我们使用EMR集群和Spark 1.6.1。

• 我在Spark中生成了一些虚拟数据，并将其保存为本地以及S3上的实木复合地板文件。
• 我使用不同类型的过滤器和列选择创建了多个Spark作业。我对本地文件和S3文件都运行了这些测试。
• 然后，我使用Spark History Server查看每个作业作为输入有多少数据。

结果：

• 对于本地拼花文件：结果显示，当作业包含过滤器或列选择时，由于输入大小减小，因此将列选择和过滤器下推到读取位置。
• 对于S3拼花文件：输入大小始终与处理所有数据的Spark作业相同。没有过滤器或列选择被下推到读取。拼花地板文件始终是从S3完全加载的。即使查询计划（.queryExecution.executedPlan）显示过滤器已下推。

有时间时，我将添加有关测试和结果的更多详细信息。

Answer 2

是的。过滤器下推不依赖于底层文件系统。它仅取决于spark.sql.parquet.filterPushdown过滤器的类型和类型（并非所有过滤器都可以下推）。

见https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetFileFormat.scala#L313为下推逻辑。