Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.

En esta página

Función de código abierto mejorada: Job Pipeline

Mostrar todo

Centro de ayuda/ MapReduce Service/ Descripción general del servicio/ Componentes/ Flink/ Funciones de código abierto mejoradas de Flink/ Job Pipeline

Job Pipeline

Actualización más reciente 2023-04-14 GMT+08:00

Ver PDF

Función de código abierto mejorada: Job Pipeline

Generalmente, el código lógico relacionado con un servicio se almacena en un paquete de JAR grande, que se llama Fat JAR. Las desventajas de Fat JAR son las siguientes:

Cuando la lógica de servicio se vuelve cada vez más compleja, el tamaño de Fat JAR aumenta.
Fat Jar hace que la coordinación sea compleja. Los desarrolladores de todos los servicios están trabajando con la misma lógica de servicio. Aunque la lógica de servicio puede dividirse en varios módulos, todos los módulos están estrechamente acoplados entre sí. Si es necesario cambiar el requisito, es necesario volver a planificar todo el diagrama de flujo.

La división de puestos de trabajo se enfrenta a los siguientes problemas:

La transmisión de datos entre trabajos se puede lograr utilizando Kafka. Por ejemplo, el trabajo A transmite datos al topic A en Kafka y, a continuación, el trabajo B y el trabajo C leen datos del topic A en Kafka. Esta solución es simple y fácil de implementar, pero la latencia es siempre superior a 100 ms.
Los operadores se conectan mediante el protocolo TCP. En un entorno distribuido, los operadores pueden programarse en cualquier nodo y los servicios ascendentes y descendentes no pueden detectar la programación.

Job Pipeline

Un Pipeline consiste en múltiples jobs de Flink conectados a través de TCP. Los jobs ascendentes pueden enviar datos a los jobs descendentes. El diagrama de flujo sobre la transmisión de datos se denomina canalización de trabajos, como se muestra en Figura 1.

Figura 1 Job pipeline

Principios de Job Pipeline

Figura 2 Principios de Job pipeline
haga clic para agrandar

NettySink y NettySource
En un pipeline, los jobs ascendentes y descendentes se comunican entre sí a través de Netty. El operador Sink del job ascendente funciona como un server y el operador Source del job descendente funciona como un cliente. El operador Sink del job ascendente se denomina NettySink y el operador Source del job descendente se denomina NettySource.
NettyServer y NettyClient
NettySink funciona como el servidor de Netty. En NettySink, NettyServer logra la función de un servidor. NettySource funciona como el cliente de Netty. En el NettySource, NettyClient cumple la función de un cliente.
Publicador
El job que envía datos a jobs descendentes a través de NettySink se denomina publicador.
Suscriptor
El job que recibe datos de jobs ascendentes a través de NettySource se denomina suscriptor.
RegisterServer
RegisterServer es la memoria de terceros que almacena la dirección IP, el número de puerto y la información de simultaneidad de NettyServer.
La arquitectura general exterior-interior es la siguiente:
- NettySink->NettyServer->NettyServerHandler
- NettySource->NettyClient->NettyClientHandler

Funciones de Job Pipeline

NettySink
NettySink consta de los siguientes módulos principales:
- RichParallelSinkFunction
  NettySink hereda el RichParallelSinkFunction y los atributos de los operadores de Sink. La API de RichParallelSinkFunction implementa las siguientes funciones:
  - Inicia el operador de NettySink.
  - Ejecuta el operador de NettySink y recibe datos del operador ascendente.
  - Cancela la ejecución de los operadores de NettySink.
  La siguiente información se puede obtener utilizando el atributo de RichParallelSinkFunction:
  - subtaskIndex acerca de la concurrencia de cada operador de NettySink.
  - Concurrencia del operador de NettySink.
- RegisterServerHandler
  RegisterServerHandler interactúa con el componente de RegisterServer y define las siguientes API:
  - start();: Inicia el RegisterServerHandler y establece un contacto con el RegisterServer de terceros.
  - createTopicNode();: Crea un nodo de topic.
  - register();: Registra información como la dirección IP, el número de puerto y la simultaneidad en el nodo de topic.
  - deleteTopicNode();: Elimina un nodo de topic.
  - unregister();: Borra la información de registro.
  - query();: Consulta información de registro.
  - isExist();: Verifica que existe una información específica.
  - shutdown();: Desactiva el RegisterServerHandler y se desconecta del RegisterServer de terceros.
  NOTA:
  - API de RegisterServerHandler permite a ZooKeeper trabajar como el handler de RegisterServer. Puede personalizar su handler según sea necesario. La información se almacena en el ZooKeeper de la siguiente forma:
    Namespace |---Topic-1 |---parallel-1 |---parallel-2 |.... |---parallel-n |---Topic-2 |---parallel-1 |---parallel-2 |.... |---parallel-m |...
  - La información sobre NameSpace se puede obtener de los siguientes parámetros del archivo flink-conf.yaml:
    nettyconnector.registerserver.topic.storage: /flink/nettyconnector
  - La autenticación simple de autenticación y capa de seguridad (SASL) entre ZookeeperRegisterServerHandler y ZooKeeper se implementa a través del marco de Flink.
  - Asegúrese de que cada job tiene un topic único. De lo contrario, la relación de suscripción puede ser poco clara.
  - Al invocar a shutdown(), ZookeeperRegisterServerHandler elimina la información de registro sobre la concurrencia actual y, a continuación, intenta eliminar el nodo de topic. Si el nodo de topic no está vacío, se cancelará la eliminación, ya que no se ha terminado toda la concurrencia.
- NettyServer
  NettyServer es el núcleo del operador de NettySink, cuya función principal es crear un NettyServer y recibir solicitudes de conexión de NettyClient. Utilice NettyServerHandler para enviar datos recibidos de operadores ascendentes de un mismo job. El número de puerto y la subred de NettyServer deben configurarse en el archivo flink-conf.yaml.
  - Rango de puertos
```
nettyconnector.sinkserver.port.range: 28444-28943
```
  - Subred
```
nettyconnector.sinkserver.subnet: 10.162.222.123/24 
```
    NOTA:
    
    El parámetro nettyconnector.sinkserver.subnet se establece en la subred (dirección IP del servicio) del cliente Flink de forma predeterminada. Si el cliente y TaskManager no están en la misma subred, puede producirse un error. Por lo tanto, debe establecer manualmente este parámetro en la subred (dirección IP del servicio) de TaskManager.
- NettyServerHandler
  El handler permite la interacción entre NettySink y suscriptores. Después de que NettySink recibe mensajes, el handler envía estos mensajes. Para garantizar la seguridad de la transmisión de datos, este canal se encripta mediante SSL. El nettyconnector.ssl.enabled configura si se habilita la encriptación sw SSL. La encriptación de SSL solo se habilita cuando nettyconnector.ssl.enabled se establece en true.
NettySource
NettySource consta de los siguientes módulos principales:
- RichParallelSourceFunction
  NettySource hereda RichParallelSinkFunction y atributos de los operadores de Source. La API de RichParallelSourceFunction implementa las siguientes funciones:
  - Inicia el operador de NettySink.
  - Ejecuta el operador de NettySink, recibe datos de los suscriptores e inyecta los datos a los jobs.
  - Cancela la ejecución de operadores de Source.
  La siguiente información se puede obtener utilizando el atributo RichParallelSourceFunction:
  - subtaskIndex acerca de la concurrencia de cada operador de NettySource.
  - Concurrencia del operador de NettySource.
  Cuando el operador del NettySource entra en la etapa de ejecución, se monitoriza el estado del NettyClient. Una vez que ocurre la anomalía, NettyClient se reinicia y se vuelve a conectar a NettyServer evitando la confusión de datos.
- RegisterServerHandler
  RegisterServerHandler de NettySource tiene una función similar a la del RegisterServerHandler de NettySink. Obtiene la dirección IP, número de puerto e información de operadores simultáneos de cada trabajo suscrito obtenido en el operador de NettySource.
- NettyClient
  NettyClient establece una conexión con NettyServer y utiliza NettyClientHandler para recibir datos. Cada operador de NettySource debe tener un nombre único (especificado por el usuario). NettyServer determina si cada cliente proviene de NettySources diferentes basados en nombres únicos. Cuando se establece una conexión entre NettyClient y NettyServer, NettyClient se registra con NettyServer y el nombre de NettySource de NettyClient se transfiere a NettyServer.
- NettyClientHandler
  El NettyClientHandler permite la interacción con los publicadores y otros operadores del job. Cuando se reciben mensajes, NettyClientHandler transfiere estos mensajes al job. Para garantizar la transmisión segura de los datos, NettySink está habilitado la encriptación de SSL para la comunicación con ellos. El encriptación SSL solo se habilita cuando SSL está habilitado y nettyconnector.ssl.enabled está establecido en true.

La relación entre los trabajos puede ser de muchos a muchos. La concurrencia entre cada operador NettySink y NettySource es de uno a varios, como se muestra en Figura 3.

Figura 3 Diagrama de relaciones

Tema principal: Funciones de código abierto mejoradas de Flink

Tema anterior: Ventana

Tema siguiente: Stream SQL Join

Comentarios

¿Le pareció útil esta página?

Sí No

Deje algún comentario

Muchas gracias por sus comentarios. Seguiremos trabajando para mejorar la documentación.

El sistema está ocupado. Vuelva a intentarlo más tarde.

¿Cuáles de los siguientes problemas se presentaron?

Contenido diferente a la de la IU del producto

Descripciones poco claras

Falta de ejemplos o código

Pasos incorrectos

No puedo encontrar lo que necesito

Falta de prácticas recomendadas

Comentarios (opcional)

0/500

Seleccione al menos un tipo de problema e ingrese sus comentarios o sugerencias.

Ingrese 500 caracteres como máximo.

Enviar Cancelar