Realtime Compute for Apache Flink:Configurar recursos do job

Utilize as seguintes fórmulas para calcular os requisitos de recursos:

• Número de CUs = MAX(CPU total para JobManager e TaskManagers, Memória total para JobManager e TaskManagers / 4)

• Número real de TaskManagers = ceil(Parallelism / Slots per TaskManager)

• Slots reais por TaskManager = Parallelism / Número real de TaskManagers

Por exemplo, suponha que você defina o paralelismo como 12 e os slots por TaskManager como 4.

Neste exemplo, JobManager CPU é 2 núcleos, JobManager Memory é 4 GiB, TaskManager CPU é 2 núcleos e TaskManager Memory é 4 GiB.

No console do Realtime Compute for Apache Flink, o número real de TaskManagers é 3, e cada TaskManager possui 4 slots.

O cálculo do número real de TaskManagers e slots por TaskManager ocorre da seguinte forma:

1. Número real de TaskManagers = ceil(Paralelismo configurado / Slots por TaskManager configurados) = ceil(12 / 4) = 3.

2. Slots reais por TaskManager = Paralelismo / Número real de TaskManagers = 12 / 3 = 4.

Configurar recursos básicos

Configurar recursos de slot

1. No expert mode, clique em Get Plan Now para obter o gráfico de plano de recursos.

2. Clique no ícone Editar em uma caixa de slot. O gráfico de plano de recursos gerado exibe várias caixas de slot, cada uma contendo informações do operador VERTEX e um valor de PARALLELISM.

3. Modifique a configuração do slot. Na caixa de diálogo, configure os parâmetros de CPU, heap memory, off-heap memory e parallelism.

   O paralelismo definido aqui aplica-se a todos os operadores dentro deste Slot Sharing Group. Após salvar a configuração, o sistema automaticamente:

   • Define o mesmo paralelismo para todos os operadores neste Slot Sharing Group.

   • Aloca a memória necessária para o state backend, Python e operadores com base na lógica de computação do job. Essa alocação é automática.

   Nota

   • Para um nó Source, recomendamos definir um paralelismo proporcional à sua contagem de partições. Ou seja, o paralelismo deve ser um divisor da contagem de partições. Por exemplo, se um tópico Kafka tiver 16 partições, defina o paralelismo como 16, 8 ou 4 para evitar skew de dados.

   • Definir o paralelismo de um nó Source muito baixo pode causar gargalo, pois uma única Source pode ler dados demais e reduzir o throughput do job.

   • Para outros nós, defina o paralelismo de acordo com o tráfego de dados e atribua maior paralelismo aos nós com mais tráfego.

   Nota

   No modo especialista, a caixa de diálogo de configuração de slot expõe CPU, Heap Memory e Off-Heap Memory para configuração manual. Outros componentes de memória — incluindo JVM Overhead, buffers de rede e memória de framework — são alocados automaticamente pelo sistema em suas proporções padrão. Esses componentes são pré-alocados quando o TaskManager inicia e não sofrem ajuste dinâmico durante a execução do job.

   Se ocorrerem erros de memória insuficiente causados por esses componentes alocados automaticamente, configure os seguintes parâmetros no campo Other Configurations em Running Parameters Configuration:

   • taskmanager.memory.jvm-overhead.fraction: Tamanho do JVM Overhead como fração da memória total do TaskManager. Padrão: 0.1 (10%).

   • taskmanager.memory.jvm-overhead.max: Tamanho máximo do JVM Overhead.

   • taskmanager.memory.jvm-overhead.min: Tamanho mínimo do JVM Overhead.

4. Clique em OK.

Configurar recursos do operador

Por padrão, todos os operadores compartilham um único Slot Sharing Group, o que impede a configuração individual de seus recursos. Para configurar recursos para um operador específico, ative o Multiple SSG mode. Esse modo atribui um slot independente a cada operador e permite configurar seus recursos nesse slot.

1. Na aba Configuration, clique em Edit na seção Resources e defina o Resource mode como expert mode.

2. (Opcional) Se nenhum plano de recursos for exibido, clique em Get Plan Now.

   Por padrão, o gráfico de plano de recursos gerado mostra todos os operadores dentro de uma única caixa de slot.

3. Ative a chave Multiple SSG mode e clique em Re-fetch.

   Essa ação divide os operadores do grupo de compartilhamento em slots individuais.

4. Clique no ícone Editar na caixa de slot correspondente ao operador alvo e modifique os recursos do operador.

   Na caixa de diálogo Modify slot, configure os parâmetros de CPU, heap memory, off-heap memory e parallelism.

5. Clique em OK.

Paralelismo do operador, estratégia de encadeamento e State TTL

Configure o paralelismo, a estratégia de encadeamento e o State TTL para operadores individuais.

1. Clique no ícone Expandir na caixa VERTEX alvo.

   Após a expansão, a caixa VERTEX exibe cada nó de operador, seu valor de PARALLELISM e um ícone Editar ao lado de cada operador.

   Nota

   Clique no ícone Editar em um VERTEX para definir o paralelismo de todos os operadores dentro desse VERTEX em lote.

2. Clique no ícone Editar do operador.

3. Configure os recursos do operador.

   A tabela a seguir descreve os parâmetros.

   Parâmetro	Descrição
   Parallelism	Paralelismo do operador.
   Chaining strategy	O encadeamento conecta vários operadores em uma única tarefa, melhorando o desempenho ao reduzir a transferência de dados e a sobrecarga de serialização. No entanto, é possível quebrar uma cadeia para obter controle mais fino sobre o fluxo de execução. As seguintes estratégias estão disponíveis: ALWAYS (Padrão): O operador sempre pode ser encadeado com operadores upstream e downstream. HEAD: O operador atual atua como início de uma cadeia. Ele não é encadeado com operadores upstream, mas permanece encadeado com operadores downstream. NEVER: O operador atual não é encadeado com nenhum operador upstream ou downstream.
   State TTL	Defina o tempo de expiração em segundos, minutos, horas ou dias. Por padrão, o operador herda o tempo de expiração de estado do job, cujo padrão é 1,5 dias. Para configurar o tempo de expiração no nível do job, consulte Configurar parâmetros de execução. Nota Este recurso é suportado apenas no Ververica Runtime (VVR) 8.0.7 e posterior. A configuração de TTL é suportada apenas para operadores com estado. A expiração de estado é um mecanismo de limpeza aproximado. O sistema não garante a remoção imediata do estado expirado após o término do TTL. O tempo real de limpeza depende dos padrões de acesso ao estado em segundo plano e das políticas de limpeza.

4. Clique em OK.

Definir o paralelismo equivale a consumir o mesmo número de CUs?

Não. Paralelismo refere-se ao número de tarefas concorrentes executadas em um job. CU (Compute Unit) é a unidade de faturamento e recursos usada pelo Realtime Compute for Apache Flink. Eles não possuem relação de 1:1.

O consumo total de CU é calculado com a seguinte fórmula:

Consumo total de CU = Paralelismo × CU por tarefa

A CU consumida por cada tarefa é determinada pela especificação de recursos por slot configurada para o job. Aumentar o paralelismo aumenta o consumo total de CU, mas o aumento é proporcional à especificação de CU por tarefa, não uma proporção simples de 1:1.

Por que SET 'parallelism.default' não funciona em jobs SQL?

Usar SET 'parallelism.default' = 'N'; diretamente nas instruções do job SQL não é eficaz no Realtime Compute for Apache Flink. Para configurar o paralelismo, use um dos seguintes métodos:

1. Defina o paralelismo na cláusula WITH da instrução SQL relevante.

2. Modifique o paralelismo na interface de edição de configuração de recursos na página O&M > Deployments.

O que fazer quando um operador Print Sink ou Join causa recursos insuficientes ou baixo desempenho?

A ação apropriada depende do sintoma específico:

• Print Sink causa escassez de recursos do TaskManager — Esse problema não pode ser resolvido apenas com ajuste de parâmetros. Avalie os requisitos de recursos com base no volume real de dados, verifique se os tipos de campo da tabela source estão definidos corretamente (por exemplo, use BIGINT em vez de STRING quando apropriado) e aloque recursos suficientes ao TaskManager para suportar a sobrecarga de depuração do Print Sink.

• Desempenho do Join ruim apesar da baixa utilização de memória — Aumente o número de CUs. No entanto, se a causa raiz for skew de dados, adicionar mais recursos pode não resolver o problema. Resolva primeiro o problema de skew de dados e depois avalie se recursos adicionais são necessários.

• Job reinicia frequentemente com alta latência de ponta a ponta — Se o job estiver em fase de sincronização de estado completo após reinicialização sem estado, tente definir o número de slots como 1, configurar o paralelismo apropriado separadamente e usar especificação de TaskManager de 1 núcleo e 4 GiB com concorrência moderada (por exemplo, 10) para testar e otimizar o desempenho.