[
https://issues.apache.org/jira/browse/FLINK-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16577479#comment-16577479
]
ASF GitHub Bot commented on FLINK-8532:
---------------------------------------
Guibo-Pan opened a new pull request #6544: [FLINK-8532] [Streaming] modify
RebalancePartitioner to use a random partition as its first partition
URL: https://github.com/apache/flink/pull/6544
## What is the purpose of the change
This pull request makes RebalancePartitioner to use a random partition as
its first partition, rather than the same 0th. In this way we avoid message
sending to the same subtask at one moment, which may cause lag of the subtask,
and make some other subtask with no message arrived to be idle. This helps
RebalancePartitioner balance message better, and increase throughput.
## Brief change log
- RebalancePartitioner starts with a random partition rather than the same
0th partition
- corresponding RebalancePartitionerTest
## Verifying this change
This change is already covered by existing tests, such as
RebalancePartitionerTest.
## 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): ( don't know)
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
- The S3 file system connector: (no)
## Documentation
- Does this pull request introduce a new feature? (no)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> RebalancePartitioner should use Random value for its first partition
> --------------------------------------------------------------------
>
> Key: FLINK-8532
> URL: https://issues.apache.org/jira/browse/FLINK-8532
> Project: Flink
> Issue Type: Improvement
> Components: DataStream API
> Reporter: Yuta Morisawa
> Priority: Minor
> Labels: pull-request-available
>
> In some conditions, RebalancePartitioner doesn't balance data correctly
> because it use the same value for selecting next operators.
> RebalancePartitioner initializes its partition id using the same value in
> every threads, so it indeed balances data, but at one moment the amount of
> data in each operator is skew.
> Particularly, when the data rate of former operators is equal , data skew
> becomes severe.
>
>
> Example:
> Consider a simple operator chain.
> -> map1 -> rebalance -> map2 ->
> Each map operator(map1, map2) contains three subtasks(subtask 1, 2, 3, 4, 5,
> 6).
> map1 map2
> st1 st4
> st2 st5
> st3 st6
>
> At the beginning, every subtasks in map1 sends data to st4 in map2 because
> they use the same initial parition id.
> Next time the map1 receive data st1,2,3 send data to st5 because they
> increment its partition id when they processed former data.
> In my environment, it takes twice the time to process data when I use
> RebalancePartitioner as long as I use other partitioners(rescale, keyby).
>
> To solve this problem, in my opinion, RebalancePartitioner should use its own
> operator id for the initial value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
