Como ajustar a importação de dados para diferentes cenários - AnalyticDB: Central de Documentação do Alibaba Cloud

AnalyticDB for MySQL oferece diversos métodos de importação de dados para diferentes cenários. No entanto, fatores como modelagem inadequada de tabelas (que causa distorção de dados) ou uso ineficiente de recursos (devido a configurações de importação não otimizadas) podem afetar o desempenho. Este tópico descreve como ajustar o desempenho da importação de dados em diferentes cenários.

Otimizar a importação de tabela externa

Verificar a chave de distribuição

A chave de distribuição determina como os dados são distribuídos entre os shards para importação simultânea. Se a distribuição não for uniforme, os shards que recebem mais dados podem se tornar gargalos, causar distorção de dados e desacelerar todo o job de importação. Para evitar isso, garanta uma distribuição uniforme dos dados durante a importação. Para mais informações sobre como selecionar uma chave de distribuição, consulte Escolher uma chave de distribuição.

Verifique se a chave de distribuição é adequada:

Antes de importar dados, avalie a chave de distribuição escolhida com base na lógica de negócios. Por exemplo, na tabela Lineitem, escolher a coluna l_discount como chave de distribuição causará distorção severa de dados devido à baixa cardinalidade (apenas 11 valores distintos). Todos os registros com o mesmo valor de desconto serão enviados ao mesmo shard, criando um gargalo e degradando o desempenho. A coluna l_orderkey é uma escolha melhor, pois os IDs de pedido são únicos e distribuem os dados de forma mais uniforme.
Após a importação, se o relatório de Diagnóstico de Modelagem de Dados indicar distorção no campo de distribuição, a chave de distribuição está causando desigualdade na distribuição dos dados. Para saber como visualizar esses diagnósticos, consulte Diagnóstico de armazenamento.

Verificar a chave de partição

Ao usar INSERT OVERWRITE SELECT, a partição importada substitui qualquer partição existente com o mesmo nome na tabela de destino. Dentro de cada shard, os dados são importados para suas respectivas partições com base na chave de partição. Para evitar a ativação de um processo de classificação externa que degrade o desempenho, não importe muitas partições de uma só vez. Para mais informações sobre como selecionar uma chave de partição, consulte Escolher uma chave de partição.

Verifique se a chave de partição é adequada:

Antes da importação, avalie a chave de partição com base nas necessidades de negócios e na distribuição de dados. Por exemplo, particionar a tabela Lineitem pela coluna l_shipdate ao longo de 7 anos geraria mais de 2.000 partições se feito por dia, o que é ineficiente. O particionamento por mês ou ano é mais adequado.
Após a importação, se o relatório de Diagnóstico de Modelagem de Dados mostrar um número excessivo de partições, a chave de partição não é adequada. Para saber como visualizar esses diagnósticos, consulte Diagnóstico de tabela particionada.

Verificar o índice

Por padrão, o AnalyticDB for MySQL indexa todas as colunas ao criar uma tabela. Criar um índice de coluna completa em uma tabela larga consome muitos recursos. Ao importar dados para esse tipo de tabela, use um índice de chave primária. Esse índice serve para deduplicação, mas incluir muitas colunas na chave primária pode desacelerar o processo. Para mais informações sobre como selecionar uma chave primária, consulte Escolher uma chave primária.

Verifique se o índice é adequado:

Em cenários de importação offline, o índice de chave primária geralmente é desnecessário, pois o job de computação offline já deduplicou os dados.
Na aba Monitoring Information > Table Information Statistics, visualize o tamanho dos dados da tabela, dos índices e do índice de chave primária. Se o tamanho dos dados de índice exceder o dos dados da tabela, verifique se há colunas com strings longas. Indexar essas colunas consome tempo e muito espaço de armazenamento. Exclua esses índices se necessário. Para mais informações, consulte ALTER TABLE.

Nota
Não é possível excluir um índice de chave primária. Recrie a tabela.

Adicionar uma hint para acelerar a importação

Adicione a hint direct_batch_load=true à instrução de importação para acelerar o processo.

Nota

Essa hint é suportada apenas em clusters da Data Warehouse Edition elástica V3.1.5 ou posterior. Se não houver melhoria significativa de desempenho, Envie um ticket.

Exemplo:

SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;

Acelerar importações com importação elástica

Nota

O recurso de importação elástica está disponível apenas para clusters com versão de kernel 3.1.10.0 ou posterior.
Este recurso é suportado em clusters da Enterprise Edition, Basic Edition e Data Lakehouse Edition que possuem um grupo de recursos de job.
A importação elástica suporta apenas dados do MaxCompute e dados CSV, Parquet ou ORC do Object Storage Service (OSS).
Ao usar a importação elástica, garanta que o grupo de recursos de job tenha recursos suficientes para evitar filas longas, execução lenta e falhas no job.

A importação elástica permite executar vários jobs de importação simultaneamente. Também é possível acelerar um único job alocando mais recursos a ele. Para mais informações, consulte Métodos de importação de dados.

Exemplo:

/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;

Para obter informações sobre os parâmetros, consulte Parâmetros de hint.

Otimizar a importação de dados do DataWorks

Otimizar configurações de job

Otimize Data Records Per Write

Este parâmetro define o tamanho do lote para cada importação. Na maioria dos casos, mantenha o valor padrão de 2048.

No entanto, se um registro for grande (por exemplo, 512 KB), defina este parâmetro como 16. Isso mantém o tamanho do lote abaixo de 8 MB e evita alto uso de memória nos nós de frontend.
Otimize o channel control
- O desempenho da sincronização de dados é diretamente proporcional ao valor do parâmetro Expected Maximum Concurrency. Aumente a Expected Maximum Concurrency o máximo possível.
  
  Importante
  Um valor maior para Expected Maximum Concurrency consome mais recursos do DataWorks. Escolha um valor adequado às suas necessidades.
- Para melhorar o desempenho da sincronização, ative a Distributed Execution.

Problemas comuns e soluções

Se o cliente enviar dados muito lentamente, a utilização da CPU do cluster, a E/S de disco e o tempo de resposta de gravação também serão baixos. Embora o servidor de banco de dados possa processar os dados enviados, o baixo volume de entrada resulta em um TPS de gravação inferior ao esperado.

Solução: Aumente os valores de Data Records Per Write e Expected Maximum Concurrency. O desempenho da importação melhora linearmente conforme a pressão de importação aumenta.
Se houver distorção de dados na tabela de destino, alguns nós do cluster ficarão sobrecarregados, degradando o desempenho da importação. Nesse caso, a utilização da CPU e da E/S de disco é baixa, mas o tempo de resposta de gravação é alto. Identifique tabelas distorcidas na página Diagnostics and Optimization > Data Modeling Diagnostics.

Solução: Redesenhe o esquema da tabela e reimporte os dados. Para mais informações, consulte design de esquema de tabela.

Otimizar a importação de dados JDBC

Otimização no lado do cliente

Agrupe dados em lotes no aplicativo
- Ao importar dados com um programa JDBC, use importações em lote para reduzir a sobrecarga de rede e de conexão. Evite importações linha a linha, a menos que haja requisitos específicos.
- Use um tamanho de lote de 2048 registros. Se um registro for grande, mantenha o tamanho total do lote abaixo de 8 MB. Calcule o número de registros por lote dividindo 8 MB pelo tamanho de um único registro. Lotes excessivamente grandes podem consumir muita memória no nó de frontend e degradar o desempenho da importação.
Configure a simultaneidade do aplicativo
- Ao importar dados de um aplicativo, use várias threads simultâneas. Uma única thread não utiliza totalmente os recursos do cliente e frequentemente não acompanha a velocidade de importação do banco de dados devido ao processamento e agrupamento de dados no lado do cliente. Importações simultâneas aumentam significativamente a velocidade.
- O nível ideal de simultaneidade depende de fatores como agrupamento em lotes, source de dados e carga da máquina cliente. Não existe um valor único ideal. Teste para encontrar a simultaneidade ótima para sua carga de trabalho. Se a velocidade de importação estiver abaixo do esperado, tente dobrar a simultaneidade. Se a velocidade diminuir, reduza-a gradualmente até encontrar a configuração ideal.

Problemas comuns e soluções

Se houver baixo desempenho ao importar dados para o AnalyticDB for MySQL a partir de um programa personalizado, verifique primeiro se há gargalos de desempenho no lado do cliente.

Garanta que a source de dados forneça dados a uma taxa suficiente. Se os dados vierem de outros sistemas ou arquivos, verifique se há gargalos de saída no cliente.
Verifique a velocidade de processamento de dados, confirme se a produção e o consumo estão sincronizados e garanta que haja dados suficientes aguardando importação para o AnalyticDB for MySQL.
Verifique a carga da máquina cliente para garantir recursos de sistema suficientes, como CPU e E/S de disco.