【问题标题】:Did spark dataframes load parquet data lazily?火花数据帧是否懒惰地加载镶木地板数据?
【发布时间】:2018-10-27 14:34:13
【问题描述】:

我想使用以下代码在 spark 中对我的 parquet 数据运行 sql,

val parquetDF = spark.read.parquet(path)
parquetDF.createOrReplaceTempView("table_name")
val df = spark.sql("select column_1, column_4, column 10 from table_name");
println(df.count())

我的问题是,此代码是否只读取光盘中所需的列?

理论上答案应该是肯定的。但我需要专家意见,因为在 Jdbc 查询(Mysql)的情况下, 与操作相比,读取(spark.read)阶段需要更多时间(可能与连接有关,但不确定)。 Jdbc代码如下,

spark.read.format("jdbc").jdbc(jdbcUrl, query, props).createOrReplaceTempView(table_name)
spark.sql("select column_1, column_4, column 10 from table_name");
df.show()
println(df.count())

如果有人能解释这两种情况下的框架流程,那将非常有帮助。

Spark 2.3.0 版

Scala 版本 2.11.11

【问题讨论】:

    标签: scala apache-spark dataframe parquet


    【解决方案1】:

    在这两种情况下,Spark 都会尽力而为(具体行为取决于格式和版本。根据上下文,可能不会应用某些优化,通常是深度嵌套的数据)以将流量限制为仅需要的数据。事实上,spark.sql("select ...) 部分甚至不相关,因为对于给定格式,实际查询应该限制为与 SELECT 1 FROM table 等效的内容。

    只要您不使用cache / persist,这就是事实。如果这样做,所有优化都会消失,Spark 将立即加载所有数据(请参阅我对Any performance issues forcing eager evaluation using count in spark?Caching dataframes while keeping partitions 的回答。还有here is an example 使用缓存时执行计划如何变化。)。

    【讨论】:

    • 所以您的意思是在第一种情况下,只会从磁盘中获取所需的列。 ?如果是这样,第二种情况有什么不同吗?它应该仅在调用“df.count()”之后从数据库加载数据。我说的对吗?
    • count 不需要数据,所以它不是一个很好的例子,否则是的。 JDBC 和 Parquet 源码没有区别。
    • 是的,count 可能不是一个很好的例子。再次不确定为什么 read(spark.read) 阶段需要更多时间
    • 查询优化只是整体性能的一小部分。这里还有更多因素(对于初学者来说,默认 JDBC 行为是顺序的)。
    猜你喜欢
    • 2019-02-11
    • 2020-01-10
    • 2016-01-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-12-20
    • 2019-02-09
    • 2018-07-09
    相关资源
    最近更新 更多