[jira] [Commented] (FLINK-9428) Allow operators to flush data on checkpoint pre-barrier

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487507#comment-16487507 ] 

ASF GitHub Bot commented on FLINK-9428:
---------------------------------------

GitHub user StephanEwen opened a pull request:

    https://github.com/apache/flink/pull/6066

    [FLINK-9428] [checkpointing] Allow operators to flush data on checkpoint pre-barrier

    ## What is the purpose of the change
    
    Some operators maintain some small transient state that may be inefficient to checkpoint, especially when it would need to be checkpointed also in a re-scalable way.
    An example are opportunistic pre-aggregation operators, which have small the pre-aggregation state that is frequently flushed downstream.
    
    Rather that persisting that state in a checkpoint, it can make sense to flush the data downstream upon a checkpoint, to let it be part of the downstream operator's state.
    
    This feature is sensitive, because flushing state has a clean implication on the downstream operator's checkpoint alignment. However, used with care, and with the new back-pressure-based checkpoint alignment, this feature can be very useful.
    
    Because it is sensitive, this PR makes this an internal feature (accessible to operators) and does NOT expose it in the public API.
    
    ## Brief change log
    
      - Adds the `prepareSnapshotPreBarrier(long checkpointId)` call to `(Abstract)StreamOperator`, with an empty default implementation.
      - Adds a call on `OperatorChain` to call this in front-to-back order on the operators.
    
    ## Verifying this change
    
      - This change does not yet alter any behavior, it adds only a plug point for future stream operators.
      - The `OperatorChainTest` Unit Test validates that the call happens, and that operators are called in the right order.
    
    ## Does this pull request potentially affect one of the following parts:
    
      - Dependencies (does it add or upgrade a dependency): **no**
      - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: **no**
      - The serializers: **no**
      - The runtime per-record code paths (performance sensitive): **no**
      - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: **yes**
      - The S3 file system connector: **no**
    
    ## Documentation
    
      - Does this pull request introduce a new feature? **no**
      - If yes, how is the feature documented? **not applicable**


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/StephanEwen/incubator-flink pre_barrier

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/6066.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #6066
    
----

----


> Allow operators to flush data on checkpoint pre-barrier
> -------------------------------------------------------
>
>                 Key: FLINK-9428
>                 URL: https://issues.apache.org/jira/browse/FLINK-9428
>             Project: Flink
>          Issue Type: New Feature
>          Components: State Backends, Checkpointing
>            Reporter: Stephan Ewen
>            Assignee: Stephan Ewen
>            Priority: Major
>             Fix For: 1.6.0
>
>
> Some operators maintain some small transient state that may be inefficient to checkpoint, especially when it would need to be checkpointed also in a re-scalable way.
> An example are opportunistic pre-aggregation operators, which have small the pre-aggregation state that is frequently flushed downstream.
> Rather that persisting that state in a checkpoint, it can make sense to flush the data downstream upon a checkpoint, to let it be part of the downstream operator's state.
> This feature is sensitive, because flushing state has a clean implication on the downstream operator's checkpoint alignment. However, used with care, and with the new back-pressure-based checkpoint alignment, this feature can be very useful.
> Because it is sensitive, I suggest to make this only an internal feature (accessible to operators) and NOT expose it in the public API at this point.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)