Realtime Compute for Apache Flink:Performance tuning for Paimon tables

Ajustar o paralelismo do sink

Use SQL Hints para definir o parâmetro sink.parallelism. O aumento do paralelismo distribui a carga de escrita e compactação por mais workers, reduzindo a probabilidade de um único bucket se tornar um gargalo. Observe que um paralelismo maior também eleva o consumo de recursos.

Ajustar as configurações de checkpoint

Como o desempenho de escrita no Paimon está intimamente ligado à frequência de checkpoints, ajustar o comportamento dos checkpoints costuma ser a maneira mais rápida de reduzir a contrapressão.

Use qualquer combinação dos seguintes ajustes:

• Aumente o intervalo de checkpoint configurando execution.checkpointing.interval. Para etapas de configuração, consulte Como configuro parâmetros para execução de deployment?

  Importante

  O intervalo de checkpoint afeta diretamente a latência de dados — o tempo entre a escrita dos dados e o momento em que ficam disponíveis para consumo. Aumente esse intervalo apenas se sua carga de trabalho tolerar latências maiores.

• Adicione execution.checkpointing.max-concurrent-checkpoints: 3 para permitir até três checkpoints simultâneos. Isso reduz o impacto de checkpoints lentos no throughput geral.

• Mude para um deployment em lote para eliminar completamente a sobrecarga de checkpoints.

Ativar compactação totalmente assíncrona

Por padrão, a compactação é síncrona com o ciclo de checkpoint. A compactação totalmente assíncrona rompe essa dependência: a compactação executa em segundo plano sempre que há recursos disponíveis, e os checkpoints prosseguem sem esperar o término da compactação.

A contrapartida é que arquivos pequenos podem se acumular durante períodos de alta escrita. Isso não afeta o consumo em stream, mas degrada o consumo em lote e o desempenho de consultas OLAP até que a compactação em segundo plano acompanhe o ritmo. Monitore o número de arquivos pequenos em cada bucket usando a tabela files fornecida pelo Paimon.

Configure os seguintes parâmetros usando a instrução ALTER TABLE ou SQL Hints:

'num-sorted-run.stop-trigger' = '2147483647',
'sort-spill-threshold' = '10',
'changelog-producer.lookup-wait' = 'false'

Alterar o formato de arquivo para Avro

Se o seu foco for consumo em lote ou em stream, sem necessidade de consultas ad hoc OLAP, configure os parâmetros abaixo para mudar o formato do arquivo de dados e desativar a coleta de estatísticas. Isso melhora a eficiência das operações de escrita.

Configure os seguintes parâmetros ao criar a tabela:

'file.format' = 'avro',
'metadata.stats-mode' = 'none'

Limitar o tamanho do arquivo temporário local

Defina write-buffer-spill.max-disk-size em SQL Hints para limitar o espaço máximo em disco usado pelos buffers de escrita com spill. Isso impede que os workers de escrita consumam disco local em excesso.

Ajustar o paralelismo do source

Use SQL Hints para definir o parâmetro scan.parallelism do source Paimon. Aumentar esse valor permite que mais leitores paralelos processem dados simultaneamente.

Usar a tabela otimizada para leitura

Durante o consumo em lote, a fase de varredura completa do consumo em stream e consultas ad hoc OLAP, o Paimon precisa mesclar dados de arquivos pequenos na memória usando merge sort. Um grande número de arquivos pequenos desacelera significativamente esse processo.

Caso não precise consumir os dados mais recentes, use a tabela otimizada para leitura para melhorar a eficiência do consumo. Quando você ativa a compactação totalmente assíncrona para maximizar o throughput de escrita, os arquivos pequenos se acumulam mais rápido do que são mesclados — nesse cenário, usar a tabela otimizada para leitura, lendo apenas dados já compactados, melhora o desempenho de leitura, embora os registros escritos mais recentemente não fiquem visíveis.

Limitar o tamanho do cache de lookup join

Ao executar lookup joins em uma tabela Paimon, os arquivos em cache podem crescer indefinidamente. Configure os seguintes parâmetros em SQL Hints para controlar o crescimento do cache:

• lookup.cache-max-disk-size — Espaço máximo em disco utilizado pelo cache de lookup.

• lookup.cache-file-retention — Tempo de retenção dos arquivos em cache antes da expiração.

Ajustar o paralelismo do sink

Use SQL Hints para definir o parâmetro sink.parallelism. Lembre-se de que um paralelismo maior aumenta o consumo de recursos.

Resolver skew de dados

Os dados upstream não passam por shuffle antes de serem gravados em uma tabela escalável de anexação. Se a distribuição dos dados upstream apresentar skew, alguns workers do sink receberão muito mais dados que outros, deixando recursos subutilizados e criando um gargalo de escrita.

Defina sink.parallelism com um valor diferente do paralelismo do nó upstream. Isso força um shuffle entre o operador upstream e o sink. Para confirmar que o shuffle está ativo, verifique o console de desenvolvimento do Realtime Compute for Apache Flink: se o operador sink e seu nó upstream aparecerem em subtarefas diferentes, os dados estão sendo redistribuídos via shuffle.

Limitar o tamanho do arquivo temporário local

Defina write-buffer-spill.max-disk-size em SQL Hints para limitar o espaço em disco usado pelos buffers de escrita com spill.

Ajustar o paralelismo do source

Use SQL Hints para definir o parâmetro scan.parallelism do source Paimon.

Ordenar dados para melhorar a eficiência de consultas

A ordem dos dados impacta significativamente o desempenho do processamento em lote e de consultas ad hoc OLAP. Ordenar os dados pelas colunas mais usadas nas condições de filtro reduz a quantidade de dados que cada consulta precisa varrer.

A ordenação exige a execução de um job Flink em modo batch. Antes de começar, conclua a configuração necessária descrita em Configuração de gerenciamento de dados. Depois, configure os parâmetros do job no campo Entry Point Main Arguments.

Quando usar cada estratégia de ordenação:

O exemplo a seguir ordena os dados de partições específicas pelas colunas date e type usando Z-order:

compact
--warehouse 'oss://your-bucket/data-warehouse'
--database 'your_database'
--table 'your_table'
--order_strategy 'zorder'
--order_by 'date,type'
--partition 'dt=20240311,hh=08;dt=20240312,hh=09'
--catalog_conf 'fs.oss.endpoint=oss-cn-hangzhou-internal.aliyuncs.com'
--catalog_conf 'fs.oss.endpoint=oss-cn-beijing-internal.aliyuncs.com'
--table_conf 'write-buffer-size=256 MB'
--table_conf 'your_table.logRetentionDuration=7 days'