[
https://issues.apache.org/jira/browse/SPARK-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294943#comment-14294943
]
Cheng Lian commented on SPARK-5446:
-----------------------------------
No, I believe it's irrelevant.
> Parquet column pruning should work for Map and Struct
> -----------------------------------------------------
>
> Key: SPARK-5446
> URL: https://issues.apache.org/jira/browse/SPARK-5446
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 1.2.0, 1.3.0
> Reporter: Jianshi Huang
>
> Consider the following query:
> {code:sql}
> select stddev_pop(variables.var1) stddev
> from model
> group by model_name
> {code}
> Where variables is a Struct containing many fields, similarly it can be a Map
> with many key-value pairs.
> During execution, SparkSQL will shuffle the whole map or struct column
> instead of extracting the value first. The performance is very poor.
> The optimized version could use a subquery:
> {code:sql}
> select stddev_pop(var) stddev
> from (select variables.var1 as var, model_name from model) m
> group by model_name
> {code}
> Where we extract the field/key-value only in the mapper side, so data being
> shuffled is small.
> A benchmark for a table with 600 variables shows drastic improvment in
> runtime:
> || || Parquet (using Map) || Parquet (using Struct) ||
> | Stddev (unoptimized) | 12890s | 583s |
> | Stddev (optimized) | 84s | 61s |
> Parquet already supports reading a single field/key-value in the storage
> level, but SparkSQL currently doesn’t have optimization for it. This will be
> very useful optimization for tables having Map or Struct with many columns.
> Jianshi
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
