[
https://issues.apache.org/jira/browse/FLINK-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237111#comment-16237111
]
Sihua Zhou commented on FLINK-7866:
-----------------------------------
[~till.rohrmann] thanks and so happy for thinking of me when you plan to
revision scheduler, I do have some thought about a properly scheduler, works
incrementally is a nice requirement as you have explained. IMO, it also need
the follow features.
1, Strong Extendibility.
This means that scheduler should be easy to extends for other
`schedule-factor` not only just for state & inputs, E.g: TM's status and
cluster's status.
2, Consider the Runtime Information of the job.
This means that when do scheduling we need to consider the previous
runtime information of the execution, the runtime information should contains
but only `task manager location`, `state size`, `input flow rate`,
`thoughtput`, I think these will be helpful for scheduler. For example, imagine
that vertex `A`,`B` both connect to vertex 'C' with `forward` and if A's
`thoughtput` was `1M \ s` and B's `thoughput` was `100M\s`, than B's slot will
be picked for 'C'. Currently, runtime information can only be filled when we do
recover, is there a chance that the scheduler can Self-Regulating, dynamic
change the schdule result. Ah, what I want to express is runtime information of
execution is helpful.
I am looking forward to your plan and interest in it :)
> Weigh list of preferred locations for scheduling
> ------------------------------------------------
>
> Key: FLINK-7866
> URL: https://issues.apache.org/jira/browse/FLINK-7866
> Project: Flink
> Issue Type: Improvement
> Components: Scheduler
> Affects Versions: 1.4.0, 1.3.2
> Reporter: Till Rohrmann
> Assignee: Sihua Zhou
> Priority: Major
> Fix For: 1.5.0
>
>
> [~sihuazhou] proposed to not only use the list of preferred locations to
> decide where to schedule a task, but to also weigh the list according to how
> often a location appeared and then select the location based on the weight.
> That way, we would obtain better locality in some cases.
> Example:
> Preferred locations list: {{[location1, location2, location2]}}
> Weighted preferred locations list {{[(location2 , 2), (location1, 1)]}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)