Imagen intermedia / intermedia / imagen de cuatro capas
Un trabajo de transmisión de Flink, desde el envío del cliente al clúster de Flink, hasta la ejecución final, experimentará un total de cuatro estados diferentes.
En general:
1. El cliente primero genera un StreamGraph basado en el código escrito por el usuario, y luego construye el StreamGraph en un JobGraph y lo envía
al nodo maestro del clúster de Flink.
2. Una vez que el JobMaster iniciado recibe el JobGraph, ser paralelizado para generar un ExecutionGraph. El post-despacho
inicia la ejecución de StreamTask.
3. StreamTask se ejecuta en paralelo en el clúster de Flink, que es la estructura de estado final del gráfico de ejecución física.
El gráfico de ejecución en Flink se puede dividir en cuatro capas: StreamGraph ==> JobGraph ==> ExecutionGraph ==> gráfico de ejecución física.
StreamGraph : es el gráfico inicial generado en base al código escrito por el usuario a través de la API de Stream. Se utiliza para representar la estructura topológica del programa.
JobGraph : StreamGraph genera JobGraph después de la optimización y lo envía a la estructura de datos de JobManager. La principal optimización es
que varios nodos elegibles se encadenan juntos como un solo nodo, lo que puede reducir el
consumo de transmisión de serialización y deserialización requerido para el flujo de datos entre nodos .
ExecutionGraph : JobManager genera ExecutionGraph basado en JobGraph. ExecutionGraph es
una versión paralelizada de JobGraph y la estructura de datos central de la capa de programación.
Gráfico de ejecución física : después de que JobManager programe el trabajo de acuerdo con ExecutionGraph,
el gráfico formado después de que las tareas se implementan en cada TaskManager no es una estructura de datos específica
La imagen de arriba muestra claramente el principio de funcionamiento y el proceso de conversión de cada diagrama de Flink. El último gráfico de ejecución física no es
la estructura de datos de Flink , pero una vez que el programa comienza a ejecutarse, cada tarea se distribuye en diferentes nodos y se muestra la relación física formada:
1. En el gráfico JobGraph, puede ver que los datos son de Durante el flujo del operador anterior (JobVertex) al siguiente
operador (JobVertex), el upstream proporciona un IntermediateDataSet como productor y el downstream
requiere JobEdge como consumidor . De hecho, JobEdge es una canalización de comunicación que conecta el conjunto de datos producido en sentido ascendente y el
nodo JobVertex en sentido descendente.
2. Durante la conversión de JobGraph a ExecutionGraph, se han producido los siguientes cambios:
(1) El concepto de paralelismo se ha agregado para convertirse en un posibilidad real Estructura grafica programada
(2) ExecutionJobVertex generado, ExecutionVertex correspondiente a JobVertex, IntermediateResult e IntermediateResultPartition correspondiente a
IntermediateDataSet, etc., y se implementará a través de estas clases en paralelo
3. ExecutionGraph ya se puede utilizar para la programación de tareas. Podemos ver que Flink genera una
Tarea correspondiente uno a uno según el gráfico , y cada Tarea corresponde a una Ejecución de un ExecutionGraph. La tarea usa InputGate,
InputChannel y ResultPartition corresponden a IntermediateResult y ExecutionEdge en la figura anterior
Entonces, ¿por qué hay una lógica de ejecución de cuatro capas en el diseño? Cual es su significado?
1. StreamGraph es un mapeo de la lógica del usuario.
2. JobGraph está optimizado sobre la base de StreamGraph, como encadenar algunas operaciones en una cadena para mejorar la eficiencia.
3. ExecutionGraph existe para la programación, agregando el concepto de procesamiento paralelo.
4. Físico Estructura de ejecución: la tarea y las estructuras relacionadas se ejecutan realmente
Explicación del término:
1)
StreamGraph: El gráfico inicial generado en base al código escrito por el usuario a través de la API de Stream (1) StreamNode: La clase utilizada para representar al operador, y tiene todos los atributos relevantes, como concurrencia, inbound y outbound.
(2) StreamEdge: representa el borde que conecta dos StreamNodes.
2) JobGraph : StreamGraph genera JobGraph después de la optimización y lo envía a la estructura de datos de JobManager.
(1) JobVertex: después de la optimización, varios StreamNodes que cumplen las condiciones pueden encadenarse para generar un JobVertex,
es decir, un JobVertex contiene uno o más operadores, la entrada de JobVertex es JobEdge y la salida es IntermediateDataSet.
(2) IntermediateDataSet: Representa la salida de JobVertex, es decir, el conjunto de datos generado por el procesamiento del operador.
El productor es JobVertex y el consumidor es JobEdge.
(3) JobEdge: representa un canal de transmisión de datos en el gráfico de trabajos. El origen es IntermediateDataSet y el destino es JobVertex.
Es decir, los datos se pasan al JobVertex de destino desde IntermediateDataSet a través de JobEdge.
3) ExecutionGraph : JobManager genera ExecutionGraph de acuerdo con JobGraph.
ExecutionGraph es una versión paralelizada de JobGraph, y es la estructura de datos central de la capa de programación
(1) ExecutionJobVertex: correspondencia uno a uno con JobVertex en JobGraph. Cada
ExecutionJobVertex tiene tantos ExecutionVertex como simultaneidad.
(2) ExecutionVertex: representa una de las subtareas simultáneas de
ExecutionJobVertex, la entrada es ExecutionEdge y la salida es IntermediateResultPartition.
(3) IntermediateResult: correspondencia uno a uno con IntermediateDataSet en JobGraph. Un
IntermediateResult contiene varias IntermediateResultPartitions, cuyo número es igual a la concurrencia del operador.
(4) IntermediateResultPartition: representa una partición
de salida de ExecutionVertex, el productor es ExecutionVertex y el consumidor son varios ExecutionEdges.
(5) ExecutionEdge: representa la entrada de ExecutionVertex, la fuente es IntermediateResultPartition, el
destino es ExecutionVertex. Tanto el origen como el destino solo pueden ser uno.
(6) Ejecución: es un intento de ejecutar un ExecutionVertex. Cuando ocurre una falla o los datos deben ser
En el caso del cálculo, ExecutionVertex puede tener varios ExecutionAttemptID. Una ejecución
se identifica de forma exclusiva mediante ExecutionAttemptID. La implementación de la tarea y la actualización del estado de la tarea entre JM y TM
utilizan ExecutionAttemptID para determinar el destinatario del mensaje.
从这些基本概念中，也可以看出以下几点：
⚫ 由于每个 JobVertex 可能有多个 IntermediateDataSet，所以每个 ExecutionJobVertex
可能有多个 IntermediateResult，因此，每个 ExecutionVertex 也可能会包含多个
IntermediateResultPartition；
⚫ ExecutionEdge 这里主要的作⼀是把 ExecutionVertex 和 IntermediateResultPartition
连接起来，表示它们之间的连接关系。
4) Gráfico de ejecución física : después de que JobManager programe el trabajo de acuerdo con ExecutionGraph,
el "gráfico" formado después de que las tareas se implementan en cada TaskManager no es una estructura de datos específica.
(1) Tarea: una vez programada la ejecución, se inicia la tarea correspondiente en el TaskManager asignado. La tarea envuelve
al operador con la lógica de ejecución del usuario.
(2) ResultPartition: representa los datos generados por una tarea y
corresponde a IntermediateResultPartition en ExecutionGraph uno a uno.
(3) ResultSubpartition: Es una subpartición de ResultPartition. Cada ResultPartition contiene múltiples
ResultSubpartitions, el número de las cuales está determinado por el número de tareas de consumo posteriores y DistributionPattern.
(4) InputGate: representa el paquete de entrada de Task, que corresponde a JobEdge en JobGraph uno a uno. Cada InputGate
consume una o más ResultPartitions.
(5) InputChannel: Cada InputGate contendrá más de un InputChannel,
que corresponde al ExecutionEdge en ExecutionGraph uno a uno, y también está conectado uno a uno a ResultSubpartition, es decir, un InputChannel
recibe la salida de una subpartición de resultados.