Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.

Nesta página

Recurso de código aberto aprimorado: pipeline de job

Mostrar todos

Central de ajuda/ MapReduce Service/ Visão geral de serviço/ Componentes/ Flink/ Recursos de código aberto aprimorados do Flink/ Pipeline de job

Pipeline de job

Atualizado em 2023-05-19 GMT+08:00

Ver PDF

Recurso de código aberto aprimorado: pipeline de job

Geralmente, o código lógico relacionado a um serviço é armazenado em um grande pacote JAR, que é chamado de Fat JAR. As desvantagens do Fat JAR são as seguintes:

Quando a lógica de serviço se torna cada vez mais complexa, o tamanho do Fat JAR aumenta.
Fat Jar torna a coordenação complexa. Os desenvolvedores de todos os serviços estão trabalhando com a mesma lógica de serviço. Mesmo que a lógica de serviço possa ser dividida em vários módulos, todos os módulos são fortemente acoplados uns com os outros. Se o requisito precisa ser alterado, todo o diagrama de fluxo precisa ser replanejado.

A divisão de jobs enfrenta os seguintes problemas:

A transmissão de dados entre jobs pode ser alcançada usando Kafka. Por exemplo, o job A transmite dados para o tópico A no Kafka e, em seguida, o job B e o job C lêem dados do tópico A no Kafka. Esta solução é simples e fácil de implementar, mas a latência é sempre superior a 100 ms.
Os operadores são conectados usando o protocolo TCP. No ambiente distribuído, os operadores podem ser agendados para qualquer nó e os serviços upstream e downstream não podem detectar o agendamento.

Pipeline de trabalho

Um pipeline consiste em vários jobs do Flink conectados por meio de TCP. Os jobs de upstream podem enviar dados para jobs de downstream. O diagrama de fluxo sobre a transmissão de dados é chamado de pipeline de job, como mostrado em Figura 1.

Figura 1 Pipeline de job

Princípios do pipeline de job

Figura 2 Princípios do pipeline de job
Clique para ampliar

NettySink e NettySource
Em um pipeline, os jobs upstream e downstream se comunicam uns com os outros por meio de Netty. O operador Sink do job upstream funciona como um servidor e o operador Source do job downstream funciona como um cliente. O operador Sink do job upstream é chamado NettySink e o operador Source do job downstream é chamado NettySource.
NettyServer e NettyClient
O NettySink funciona como o servidor de Netty. No NettySink, o NettyServer cumpre a função de um servidor. NettySource é o cliente de Netty. Em NettySource, o NettyClient realiza a função de um cliente.
Publicador
O job que envia dados para jobs downstream por meio do NettySink é chamado de publicador.
Assinante
O job que recebe dados de jobs upstream por meio do NettySource é chamado de assinante.
RegisterServer
RegisterServer é a memória de terceiros que armazena o endereço IP, o número da porta e as informações de simultaneidade sobre NettyServer.
A arquitetura geral de fora para dentro é a seguinte:
- NettySink->NettyServer->NettyServerHandler
- NettySource->NettyClient->NettyClientHandler

Funções do pipeline de job

NettySink
O NettySink é composto pelos seguintes módulos principais:
- RichParallelSinkFunction
  NettySink herda RichParallelSinkFunction e atributos dos operadores Sink. A API de RichParallelSinkFunction implementa as seguintes funções:
  - Inicia o operador NettySink.
  - Executa o operador NettySink e recebe dados do operador upstream.
  - Cancela a execução de operadores NettySink.
  As seguintes informações podem ser obtidas usando o atributo de RichParallelSinkFunction:
  - subtaskIndex sobre a simultaneidade de cada operador NettySink.
  - Simultaneidade do operador NettySink.
- RegisterServerHandler
  O RegisterServerHandler interage com o componente do RegisterServer e define as seguintes APIs:
  - start();: inicia o RegisterServerHandler e estabelece um contato com o RegisterServer de terceiros.
  - createTopicNode();: cria um nó de tópico.
  - register();: registra informações como endereço IP, número da porta e simultaneidade ao nó do tópico.
  - deleteTopicNode();: exclui um nó de tópico.
  - unregister();: exclui informações de registro.
  - query();: consulta informações de registro.
  - isExist();: verifica se existe uma informação específica.
  - shutdown();: desabilita o RegisterServerHandler e desconecta do RegisterServer de terceiros.
  - A API de RegisterServerHandler permite que o ZooKeeper funcione como o manipulador do RegisterServer. Você pode personalizar seu manipulador conforme necessário. As informações são armazenadas no ZooKeeper da seguinte forma:
    Namespace |---Topic-1 |---parallel-1 |---parallel-2 |.... |---parallel-n |---Topic-2 |---parallel-1 |---parallel-2 |.... |---parallel-m |...
  - Informações sobre NameSpace podem ser obtidas a partir dos seguintes parâmetros do arquivo flink-conf.yaml:
    nettyconnector.registerserver.topic.storage: /flink/nettyconnector
  - A autenticação simples da camada de autenticação e segurança (SASL) entre ZookeeperRegisterServerHandler e ZooKeeper é implementada através da estrutura de Flink.
  - Certifique-se de que cada job tenha um tópico único. Caso contrário, a relação de assinatura pode não ser clara.
  - Ao chamar shutdown(), o ZookeeperRegisterServerHandler exclui as informações de registro sobre a simultaneidade atual e tenta excluir o nó do tópico. Se o nó do tópico não estiver vazio, a exclusão será cancelada, porque nem toda a simultaneidade saiu.
- NettyServer
  NettyServer é o núcleo do operador NettySink, cuja principal função é criar um NettyServer e receber solicitações de conexão do NettyClient. Use o NettyServerHandler para enviar dados recebidos de operadores upstream de um mesmo job. O número da porta e a sub-rede do NettyServer precisam ser configurados no arquivo flink-conf.yaml.
  - Intervalo da porta
```
nettyconnector.sinkserver.port.range: 28444-28943
```
  - Sub-rede
```
nettyconnector.sinkserver.subnet: 10.162.222.123/24 
```
    O parâmetro nettyconnector.sinkserver.subnet é definido como a sub-rede (endereço IP do serviço) do cliente de Flink por padrão. Se o cliente e o TaskManager não estiverem na mesma sub-rede, poderá ocorrer um erro. Portanto, você precisa definir manualmente esse parâmetro para a sub-rede (endereço IP do serviço) do TaskManager.
- NettyServerHandler
  O manipulador permite a interação entre NettySink e assinantes. Depois que o NettySink recebe mensagens, o manipulador envia essas mensagens. Para garantir a segurança da transmissão de dados, este canal é criptografado usando SSL. O nettyconnector.ssl.enabled configura se a criptografia SSL deve ser ativada. A encriptação SSL é ativada apenas quando nettyconnector.ssl.enabled está definido como true.
NettySource
O NettySource é composto pelos seguintes módulos principais:
- RichParallelSourceFunction
  NettySource herda RichParallelSinkFunction e atributos dos operadores Source. A API de RichParallelSourceFunction implementa as seguintes funções:
  - Inicia o operador NettySink.
  - Executa o operador NettySink, recebe dados de assinantes e injeta os dados em jobs.
  - Cancela a execução dos operadores Source.
  As seguintes informações podem ser obtidas usando o atributo de RichParallelSourceFunction:
  - subtaskIndex sobre a simultaneidade de cada operador NettySource.
  - Simultaneidade do operador NettySource.
  Quando o operador NettySource entra no estágio de execução, o status do NettyClient é monitorado. Quando a anormalidade ocorre, o NettyClient é reiniciado e reconectado ao NettyServer para evitar confusão de dados.
- RegisterServerHandler
  RegisterServerHandler de NettySource tem função semelhante ao RegisterServerHandler de NettySink. Obtém o endereço IP, o número da porta e as informações dos operadores concorrentes de cada job subscrito obtido no operador NettySource.
- NettyClient
  O NettyClient estabelece uma conexão com o NettyServer e usa o NettyClientHandler para receber dados. Cada operador NettySource deve ter um nome exclusivo (especificado pelo usuário). O NettyServer determina se cada cliente vem de NettySources diferentes com base em nomes exclusivos. Quando uma conexão é estabelecida entre NettyClient e NettyServer, NettyClient é registrado com NettyServer e o nome de NettySource em NettyClient é transferido para NettyServer.
- NettyClientHandler
  O NettyClientHandler permite a interação com editores e outros operadores do job. Quando as mensagens são recebidas, o NettyClientHandler as transfere para o job. Para garantir a transmissão segura de dados, a criptografia SSL é ativada para a comunicação com o NettySink. A encriptação SSL só é ativada quando o SSL está ativado e nettyconnector.ssl.enabled está definido como true.

A relação entre os jobs pode ser muitos-para-muitos. A simultaneidade entre cada operador NettySink e NettySource é um-para-muitos, como mostrado em Figura 3.

Figura 3 Diagrama de relação