[
https://issues.apache.org/jira/browse/FLINK-36192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878688#comment-17878688
]
Rui Fan commented on FLINK-36192:
---------------------------------
Thanks [~heigebupahei] for reporting this issue!
{quote}When the degree of parallelism calculated in the autoscaler logic P1 >
partition/2, there will be two situations:
1. When the number of partitions is less than max paralleliem, use the number
of partitions as the degree of parallelism (I think this is optimal)
2. When the number of partitions is greater than max paralleliem, we have three
ways to select the final degree of parallelism. {color:#de350b}Select P1 as the
final degree of parallelism{color}, {color:#4c9aff}select partition/2 as the
final degree of parallelism (this ensures that the partitions are
aligned),{color} {color:#ffbdad}and max paralleliem is the final degree of
parallelism.{color}
{quote}
{color:#172b4d}In theory, the processing rate of these three options is the
same. So I {color}{color:#172b4d}also think partition/2 as the parallelism is a
suitable choice here. It will use the lowest parallelism.{color}
{color:#172b4d}In addition to the above discussion, when the recommended
parallelism is limited due to source partition or maxParallelism causing the
job to lag, could we record some events to remind the user?{color}
{color:#172b4d}For example, remind the user that it is currently unable to
scale up due to the limit of maxParallelism. Or it is currently unable to scale
up due to the limit of the number of source partitions.{color}
> Optimize the logic to make it the common divisor of the partition number of
> the data source when determining the parallelism of the source task.
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FLINK-36192
> URL: https://issues.apache.org/jira/browse/FLINK-36192
> Project: Flink
> Issue Type: Improvement
> Components: Autoscaler
> Reporter: yuanfenghu
> Priority: Minor
>
> *Description:*
> We hope that when we know the number of partitions of Kafka data, we can try
> our best to make the parallelism of tasks that consume Kafka equal to the
> common divisor of the partitions, so that the tasks that are consumed can be
> balanced.
>
> {*}current logic{*}:
> Currently, the parallelism of tasks in the autoscaler is determined as
> follows:
> step1: Calculate the processing rate of the task target and the corresponding
> parallelism p1
> step2: Use the currently calculated degree of parallelism and the maximum
> degree of parallelism of the operator to calculate, and take out the greatest
> common divisor p2 of the maximum degree of parallelism / 2. If p2 <
> maxparalleliem / 2, use p2 as the final degree of parallelism. If p2 >
> maxparalleliem / 2 then use p1 as the final parallelism
> If the task that needs to be judged is a task that consumes Kafka or Pulsar,
> the maximum parallelism of the task will be determined first: if the number
> of partitions < the maximum parallelism of the current task, then the maximum
> parallelism of the current task is the number of partitions of Kafka or
> Pulsar. , otherwise the maximum degree of parallelism remains unchanged, so
> there are the following situations:
> When the number of partitions in kafka or pulsar is less than the maximum
> parallelism of the operator
> 1. If the parallelism calculated in step 1 <the number of kafka or pulsar
> partitions/2, then the demand is met and the number of tasks can be balanced.
> 2. If the parallelism calculated in step 1 > the number of kafka or pulsar
> partitions / 2, use the parallelism calculated in step 1. At this time, the
> consumption will become unbalanced. For example, the number of partitions in
> kafka is 64, and the expected parallelism calculated in step 1 is If the
> degree is 48, the final task parallelism degree is 48
> When the number of partitions in kafka or pulsar is greater than the maximum
> parallelism of the operator
> Calculate the parallelism completely according to the logic of step 1. For
> example, the parallelism of one of my kafka partitions is 200, and the
> maximum parallelism of the operator is 128. Then the calculated parallelism
> is 2, 4, 8, 16... It is very likely that Kafka cannot be consumed evenly
>
> {*}expect logic{*}:
> * When the number of partitions is less than the maximum parallelism,
> determine the number of parallelism of the task as the common divisor of the
> number of partitions.
> * When the number of partitions is greater than the maximum parallelism, the
> number of parallelism of the task is determined to be the common divisor of
> the number of partitions but does not exceed the maximum parallelism.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
