[jira] [Commented] (SAMZA-921) Consolidate LocalityManager and TaskAssignmentManager

["Yi Pan (Data Infrastructure) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SAMZA-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222130#comment-15222130 ] 

Yi Pan (Data Infrastructure) commented on SAMZA-921:
----------------------------------------------------

Hi, [~jmaes], yeah, your description is accurate. IMHO, we need to have the per task to host message anyways. Hence, using the single message to carry task->container-host mapping actually reduce the number of messages in the CoordinatorStream, even after compaction. Besides that, the repetition of container in each message should not be a huge cost, since a) it only adds a field in the value, not the whole message; b) the number of tasks in a single container usually does not go beyond 10, which results in a bounded overhead.

> Consolidate LocalityManager and TaskAssignmentManager
> -----------------------------------------------------
>
>                 Key: SAMZA-921
>                 URL: https://issues.apache.org/jira/browse/SAMZA-921
>             Project: Samza
>          Issue Type: Bug
>            Reporter: Jake Maes
>
> As part of the work and discussion around SAMZA-906 there were a couple observations about how locality information should be managed in Samza.
> 1. There should be one locality manager that is ultimately responsible for mapping tasks to hosts. To do this, it may also need to manage separate intermediate mappings from task->container and container->host, though there are some contexts where both mappings will be needed. (e.g. some implementations of BalancingTaskNameGrouper)
> 2. Locality information should be written centrally. This facilitates a broadcast-like system, in which one leader writes the coordinator stream once and that information is consumed by all non-leaders either directly or through the leader. This also has the advantage that the leader can better track changes like a decrease in container count and clean up the container->host mapping, whereas the containers cannot do this naturally.
> Why doesn't it already work this way?
> 1. The locality manager writes the locality in the container in order to ensure that the task was actually executing before writing the locality to the coordinator stream. This prevents a scenario where a container is attempted and fails on multiple hosts, thrashing the locality information and losing the local state. However, after SAMZA-871 is implemented, the leader will have the means to determine that the container is running, which will enable the locality to be written centrally.
> 2. Since the container->host mapping is written in the containers, it registers itself as a CoordinatorStreamManager with "source" specific to the container doing the writing. Conversely, the TaskAssignmentManager writes all mappings centrally, so it uses one "TaskAssignmentManager" source. If, however the locality manager were updated to also write centrally, they could be combined and register with one "LocalityManager" source, which enables consolidation of the currently-separate CoordinatorStreamManager implementations (LocalityManager and TaskAssignmentManager)
> So, after SAMZA-871 we should be able to combine the LocalityManager and TaskAssignmentManager into one class that writes everything centrally, but still preserves the guarantee that the container-host mapping is not written until the container is actually running. That work is the goal of this task. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)