[
https://issues.apache.org/jira/browse/FLINK-26490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503340#comment-17503340
]
刘方奇 commented on FLINK-26490:
-----------------------------
[~yunta] Actually, setting the max parallelism very large from the begin is a
good answer for the new job without checkpoint. But there are usually so many
job restored from the checkpoint, they have a default max parallelism. For
example, SQL Job, some data stream job without setting max parallelism. I think
it can deal with the problem of the existed jobs not the new jobs.
> Adjust the MaxParallelism or remove the MaxParallelism check when unnecessary.
> ------------------------------------------------------------------------------
>
> Key: FLINK-26490
> URL: https://issues.apache.org/jira/browse/FLINK-26490
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / State Backends
> Reporter: 刘方奇
> Priority: Major
> Labels: pull-request-available
>
> Since Flink introduce key group and MaxParallelism, Flink can rescale with
> less cost.
> But when we want to update the job parallelism bigger than the
> MaxParallelism, it 's impossible cause there are so many MaxParallelism check
> that require new parallelism should not bigger than MaxParallelism.
> Actually, when an operator which don't contain keyed state, there should be
> no problem when update the parallelism bigger than the MaxParallelism,, cause
> only keyed state need MaxParallelism and key group.
> So should we remove this check or auto adjust the MaxParallelism when we
> restore an operator state that don't contain keyed state?
> It can make job restore from checkpoint easier.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
