You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Erik Erlandson (JIRA)" <ji...@apache.org> on 2019/07/03 00:05:00 UTC
[jira] [Commented] (SPARK-27296) User Defined Aggregating Functions
(UDAFs) have a major efficiency problem
[ https://issues.apache.org/jira/browse/SPARK-27296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877374#comment-16877374 ]
Erik Erlandson commented on SPARK-27296:
----------------------------------------
The basic approach as described above appears to be working (see the linked PR). To obtain the desired behavior I had to create a new API, which is fairly similar to UDAF, but inherits from TypedImperativeAggregate. This new API supports UDT and Column instantiation, and so I believe it offers feature parity with the original UDAF, with substantial performance improvements.
> User Defined Aggregating Functions (UDAFs) have a major efficiency problem
> --------------------------------------------------------------------------
>
> Key: SPARK-27296
> URL: https://issues.apache.org/jira/browse/SPARK-27296
> Project: Spark
> Issue Type: Bug
> Components: Spark Core, SQL, Structured Streaming
> Affects Versions: 2.3.3, 2.4.0, 3.0.0
> Reporter: Erik Erlandson
> Priority: Major
> Labels: performance, usability
>
> Spark's UDAFs appear to be serializing and de-serializing to/from the MutableAggregationBuffer for each row. This gist shows a small reproducing UDAF and a spark shell session:
> [https://gist.github.com/erikerlandson/3c4d8c6345d1521d89e0d894a423046f]
> The UDAF and its compantion UDT are designed to count the number of times that ser/de is invoked for the aggregator. The spark shell session demonstrates that it is executing ser/de on every row of the data frame.
> Note, Spark's pre-defined aggregators do not have this problem, as they are based on an internal aggregating trait that does the correct thing and only calls ser/de at points such as partition boundaries, presenting final results, etc.
> This is a major problem for UDAFs, as it means that every UDAF is doing a massive amount of unnecessary work per row, including but not limited to Row object allocations. For a more realistic UDAF having its own non trivial internal structure it is obviously that much worse.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org