beam-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (Jira)" <j...@apache.org>
Subject [jira] [Work logged] (BEAM-12153) OOM on GBK in SparkRunner and SpartStructuredStreamingRunner
Date Tue, 31 Aug 2021 14:42:00 GMT

     [ https://issues.apache.org/jira/browse/BEAM-12153?focusedWorklogId=644074&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-644074
]

ASF GitHub Bot logged work on BEAM-12153:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 31/Aug/21 14:41
            Start Date: 31/Aug/21 14:41
    Worklog Time Spent: 10m 
      Work Description: echauchot commented on pull request #15267:
URL: https://github.com/apache/beam/pull/15267#issuecomment-909301845


   > > @aaltay next step is getting back from vacation, which just happened smile
   > > I'm gonna update the PR today.
   > 
   > Welcome back :)
   
   thanks Ahmet !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@beam.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 644074)
    Time Spent: 4h 50m  (was: 4h 40m)

> OOM on GBK in SparkRunner and SpartStructuredStreamingRunner
> ------------------------------------------------------------
>
>                 Key: BEAM-12153
>                 URL: https://issues.apache.org/jira/browse/BEAM-12153
>             Project: Beam
>          Issue Type: Bug
>          Components: runner-spark
>            Reporter: Etienne Chauchot
>            Assignee: Etienne Chauchot
>            Priority: P3
>          Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> We have being experiencing OOM errors on GroupByKey in batch mode in both Spark runners
even if behind the woods spark spills data to disk in such cases: taking a look at the translation
in the two runners, it might be due to using ReduceFnRunner for merging windows in GBK translation.
ReduceFnRunner.processElements expects to have all elements to merge the windows between each
other.:
> RDD spark runner:
> https://github.com/apache/beam/blob/752798e3b0e6911fa84f8d138dacccdb6fcc85ef/runners/spark/src/main/java/org/apache/beam/runners/spark/translation/SparkGroupAlsoByWindowViaOutputBufferFn.java#L99
> structured streaming spark: runner: [https://github.com/apache/beam/blob/752798e3b0e6911fa84f8d138dacccdb6fcc85ef/runners/spark/2/src/main/java/org/apache/beam/runners/spark/structuredstreaming/translation/batch/functions/GroupAlsoByWindowViaOutputBufferFn.java#L74|https://github.com/apache/beam/blob/752798e3b0e6911fa84f8d138dacccdb6fcc85ef/runners/spark/2/src/main/java/org/apache/beam/runners/spark/structuredstreaming/translation/batch/functions/GroupAlsoByWindowViaOutputBufferFn.java#L106]
> Even replacing the Iterable with an Iterator in ReduceFnRunner to avoid materialization
does not work because deep in ReduceFnRunner.processElements(), the collection is iterated
twice.
> It could be better to do what flink runner does and translate GBK as CombinePerKey with
a Concatenate combine fn and thus avoid elements materialization.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message