You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "zhengruifeng (Jira)" <ji...@apache.org> on 2021/10/22 10:48:00 UTC
[jira] [Updated] (SPARK-37099) Impl a rank-based filter to optimize
top-k computation
[ https://issues.apache.org/jira/browse/SPARK-37099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
zhengruifeng updated SPARK-37099:
---------------------------------
Description:
in JD, we found that more than 80% usage of window function follows this pattern:
select (... row_number() over(partition by ... order by ...) as rn)
where rn ==[\<=] k
However, existing physical plan is not optimum:
1, we should select local top-k records within each partitions, and then compute the global top-k. this can help reduce the shuffle amount;
2, skewed-window: some partition is skewed and take a long time to finish computation.
A real-world skewed-window case in our system is attached.
was:
in JD, we found that more than 80% usage of window function follows this pattern:
select (... row_number() over(partition by ... order by ...) as rn)
where rn ==[\<=] k
However, existing physical plan is not optimum:
1, we should select local top-k records within each partitions, and then compute the global top-k. this can help reduce the shuffle amount;
2, skewed-window: some partition is skewed and take a long time to finish computation.
This is a real-world skewed-window case in our system:
!image-2021-10-22-18-46-58-496.png!
> Impl a rank-based filter to optimize top-k computation
> ------------------------------------------------------
>
> Key: SPARK-37099
> URL: https://issues.apache.org/jira/browse/SPARK-37099
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 3.3.0
> Reporter: zhengruifeng
> Priority: Major
>
> in JD, we found that more than 80% usage of window function follows this pattern:
>
> select (... row_number() over(partition by ... order by ...) as rn)
> where rn ==[\<=] k
>
> However, existing physical plan is not optimum:
>
> 1, we should select local top-k records within each partitions, and then compute the global top-k. this can help reduce the shuffle amount;
>
> 2, skewed-window: some partition is skewed and take a long time to finish computation.
>
> A real-world skewed-window case in our system is attached.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org