[ 
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)

Reply via email to