[
https://issues.apache.org/jira/browse/BEAM-6735?focusedWorklogId=214130&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-214130
]
ASF GitHub Bot logged work on BEAM-6735:
----------------------------------------
Author: ASF GitHub Bot
Created on: 16/Mar/19 01:00
Start Date: 16/Mar/19 01:00
Worklog Time Spent: 10m
Work Description: kyle-winkelman commented on issue #7929: [BEAM-6735]
Add noSpilling option to WriteFiles.
URL: https://github.com/apache/beam/pull/7929#issuecomment-473483762
I mainly use the spark-runner in batch mode. The pipeline, as it is now, has
WriteUnshardedTempFilesFn be a ParDo.MultiOutput. The way ParDo.MultiOutputs
are implemented in the spark-runner are to immediately cache the output and use
it twice. Currently this is the only location in my pipeline with caching.
I use spark.dynamicAllocation so that I can release idle executors, but
because of this caching those executors are not eligible to be released. This
means at the end of my job I am holding onto hundreds of executors while only
one of them does the copy from temp location to final location.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 214130)
Time Spent: 2h 20m (was: 2h 10m)
> WriteFiles with runner-determined sharding is forced to handle spilling
> -----------------------------------------------------------------------
>
> Key: BEAM-6735
> URL: https://issues.apache.org/jira/browse/BEAM-6735
> Project: Beam
> Issue Type: Improvement
> Components: sdk-java-core
> Reporter: Kyle Winkelman
> Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> As a result of BEAM-2302, files in excess of WriteFiles
> maxNumWritersPerBundle are shuffled to be written later. The downside to this
> is that even if you can guarantee that maxNumWritersPerBundle is high enough
> to handle all writes you still have to pay the overhead of this write now
> being a MultiOutput ParDo.
> e.g. In the Spark Runner when a ParDo has multiple outputs the returned data
> is cached and if using the disableCache pipeline option it would cause
> recalculation and all the temp files would be written again.
> I'm sure that the Spark Runner is not the only runner that would benefit from
> an optional setting for WriteFiles that would skip this spilling and simplify
> the pipeline.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
