Resolver Problemas de Desempenho da Atividade de Cópia

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Este artigo explica como resolver problemas de desempenho de atividade de cópia no Azure Data Factory.

Depois de executar uma atividade de cópia, é possível recolher o resultado da execução e as estatísticas de desempenho na vista de monitorização da atividade de cópia. A imagem seguinte mostra um exemplo.

Sugestões de otimização do desempenho

Em alguns cenários, quando você executa uma atividade de cópia, você vê "Dicas de ajuste de desempenho" na parte superior, conforme mostrado na imagem anterior. As dicas informam o gargalo identificado pelo serviço para essa execução de cópia específica, juntamente com sugestões sobre como aumentar a taxa de transferência da cópia. Tente fazer a alteração recomendada e execute a cópia novamente.

Como referência, atualmente as dicas de ajuste de desempenho fornecem sugestões para os seguintes casos:

Compreender os detalhes de execução da atividade de cópia

Os detalhes e durações de execução na parte inferior da exibição de monitoramento da atividade de cópia descrevem os principais estágios pelos quais sua atividade de cópia passa (veja o exemplo no início deste artigo), o que é especialmente útil para solucionar problemas de desempenho da cópia. O gargalo do seu processo de cópia é aquele com a maior duração. Consulte a tabela seguinte para a definição de cada etapa e aprenda como resolver problemas da atividade de cópia no Azure IR e resolver problemas da atividade de cópia no IR auto-hospedado com estas informações.

Solução de problemas da atividade de cópia no Azure IR

Siga as etapas de ajuste de desempenho para planejar e conduzir testes de desempenho para seu cenário.

Quando o desempenho da atividade de cópia não corresponder às suas expectativas, para diagnosticar a atividade de cópia única executada no Azure Integration Runtime, se vir dicas de ajuste de desempenho surgirem na visualização de monitorização de cópias, aplique a sugestão e tente novamente. Caso contrário, entenda os detalhes de execução da atividade de cópia, verifique qual estágio tem a maior duração e aplique as orientações abaixo para aumentar o desempenho da cópia:

• O "script de pré-cópia" demorou muito tempo: significa que o script de pré-cópia em execução no banco de dados de destino leva muito tempo para ser concluído. Ajuste a lógica de script de pré-cópia especificada para melhorar o desempenho. Se precisar de mais ajuda para melhorar o script, entre em contato com a equipe do banco de dados.

• "Transferência - Tempo até ao primeiro byte" teve um tempo de espera prolongado: a consulta de origem demora muito tempo a devolver qualquer dado. Isto pode significar que a consulta demora muito tempo a ser processada na sua fonte porque esta está ocupada com outras tarefas, ou a consulta não é ótima, ou os dados são armazenados de forma a demorar muito tempo a ser recuperados. Considere se outras consultas estão a correr nessa fonte ao mesmo tempo, ou se há atualizações que possa fazer à sua consulta para que ela possa recuperar dados mais rapidamente. Se houver uma equipa que gere a sua fonte de dados, contacte-a para modificar a sua consulta ou verificar o desempenho da fonte.

• "Transfer - Listing source" tem um tempo de processamento longo: isso significa que enumerar ficheiros de origem ou partições de dados da base de dados de origem está lento.

  • Ao copiar dados de uma fonte baseada em ficheiros, se utilizares um filtro de caracteres universais no caminho da pasta ou no nome do ficheiro, ou um filtro de tempo da última modificação do ficheiro, nota que tal filtro resultará numa atividade de cópia que lista todos os ficheiros da pasta especificada no lado do cliente e só depois aplica o filtro. Essa enumeração de arquivos pode se tornar o gargalo, especialmente quando apenas um pequeno conjunto de arquivos atende à regra de filtro.

    • Verifique se você pode copiar arquivos com base no caminho ou nome do arquivo particionado datetime. Dessa forma, não impõe carga sobre a parte da origem da listagem.

    • Verifique se pode usar o filtro nativo do repositório de dados, especificamente "prefix" para Amazon S3/Azure Blob storage/Ficheiros do Azure e "listAfter/listBefore" para ADLS Gen1. Esses filtros são filtros do lado do servidor de armazenamento de dados e teriam melhor desempenho.

    • Considere dividir um único conjunto de dados grande em vários conjuntos de dados menores e permitir que os trabalhos de cópia sejam executados simultaneamente, cada um lidando com uma parte dos dados. Você pode fazer isso com Lookup/GetMetadata + ForEach + Copy. Consulte Copiar arquivos de vários contêineres ou Migrar dados do Amazon S3 para modelos de solução ADLS Gen2 como exemplo geral.

  • Verifique se o serviço relata algum erro de limitação na origem ou se o armazenamento de dados está em estado de alta utilização. Em caso afirmativo, reduza as cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do repositório de dados para aumentar o limite de limitação ou o recurso disponível.

  • Usa o Azure IR na mesma ou perto da tua região de armazenamento de dados de origem.

• "Transferência - leitura a partir da fonte" apresentou um longo tempo de execução:

  • Adote as melhores práticas de carregamento de dados específicas do conector, se aplicável. Por exemplo, ao copiar dados do Amazon Redshift, configure para usar o Redshift UNLOAD.

  • Verifique se o serviço relata algum erro de limitação na origem ou se o armazenamento de dados está sob alta utilização. Em caso afirmativo, reduza as cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do repositório de dados para aumentar o limite de limitação ou o recurso disponível.

  • Verifique o padrão de origem e destino de cópia:

    • Se o seu padrão de cópia suportar mais de quatro Unidades de Integração de Dados (DIUs) - consulte esta seção sobre detalhes, geralmente você pode tentar aumentar as DIUs para obter um melhor desempenho.

    • Caso contrário, considere dividir um único conjunto de dados de grandes dimensões em vários conjuntos de dados mais pequenos e permitir que esses trabalhos de cópia sejam executados simultaneamente, sendo que cada um aborda uma parte dos dados. Você pode fazer isso com Lookup/GetMetadata + ForEach + Copy. Consulte Copiar arquivos de vários contêineres, Migrar dados do Amazon S3 para o ADLS Gen2 ou Copiar em massa com modelos de solução de tabela de controle como exemplo geral.

  • Usa o Azure IR na mesma ou perto da tua região de armazenamento de dados de origem.

• "Transferência - escrita para o destino" teve uma longa duração de execução

  • Adote as melhores práticas de carregamento de dados específicas do conector, se aplicável. Por exemplo, ao copiar dados para Azure Synapse Analytics, use a instrução PolyBase ou COPY.

  • Verifique se o serviço relata algum erro de limitação no coletor ou se o armazenamento de dados está sob alta utilização. Em caso afirmativo, reduza as cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do repositório de dados para aumentar o limite de limitação ou o recurso disponível.

  • Verifique o padrão de origem e destino de cópia:

    • Se o seu padrão de cópia suportar mais de quatro Unidades de Integração de Dados (DIUs) - consulte esta seção sobre detalhes, geralmente você pode tentar aumentar as DIUs para obter um melhor desempenho.

    • Caso contrário, afine gradualmente as cópias paralelas. Muitas cópias paralelas podem até prejudicar o desempenho.

  • Usa o Azure IR na mesma região ou numa região próxima ao seu armazenamento de dados de destino.

Solucionar problemas de atividade de cópia no Self-hosted IR

Siga as etapas de ajuste de desempenho para planejar e conduzir testes de desempenho para seu cenário.

Quando o desempenho da cópia não corresponde às suas expectativas, para resolver uma atividade de cópia única a correr no Azure Integration Runtime, se vir dicas de afinação de desempenho a aparecer na vista de monitorização de cópias, aplique a sugestão e tente novamente. Caso contrário, entenda os detalhes de execução da atividade de cópia, verifique qual estágio tem a maior duração e aplique as orientações abaixo para aumentar o desempenho da cópia:

• "Fila" experimentou longa duração: significa que a atividade de cópia espera muito tempo na fila até que o seu IR auto-hospedado tenha recursos para executar. Verifique a capacidade e o uso de IR e aumente ou expanda a escala de acordo com a sua carga de trabalho.

• "Transfer - Time to first byte" apresentou uma longa duração de execução: significa que a sua consulta de origem leva muito tempo para retornar dados. Verifique e otimize a consulta ou o servidor. Se precisar de mais ajuda, entre em contato com sua equipe de armazenamento de dados.

• "Transfer - Listing source" tem um tempo de processamento longo: isso significa que enumerar ficheiros de origem ou partições de dados da base de dados de origem está lento.

  • Verifique se a máquina IR auto-hospedada tem baixa latência ao conectar-se ao repositório de dados de origem. Se a sua fonte estiver em Azure, pode usar esta ferramenta para verificar a latência da máquina IR auto-hospedada para a região Azure, quanto menos melhor.

  • Ao copiar dados de uma fonte baseada em ficheiros, se utilizares um filtro de caracteres universais no caminho da pasta ou no nome do ficheiro, ou um filtro de tempo da última modificação do ficheiro, nota que tal filtro resultará numa atividade de cópia que lista todos os ficheiros da pasta especificada no lado do cliente e só depois aplica o filtro. Essa enumeração de arquivos pode se tornar o gargalo, especialmente quando apenas um pequeno conjunto de arquivos atende à regra de filtro.

    • Verifique se você pode copiar arquivos com base no caminho ou nome do arquivo particionado datetime. Dessa forma, não impõe carga sobre a parte da origem da listagem.

    • Vê se podes usar o filtro nativo da loja de dados, especificamente "prefix" para Amazon S3/Azure Blob storage/Ficheiros do Azure e "listAfter/listBefore" para ADLS Gen1. Esses filtros são filtros do lado do servidor de armazenamento de dados e teriam melhor desempenho.

    • Considere dividir um único conjunto de dados grande em vários conjuntos de dados menores e permitir que os trabalhos de cópia sejam executados simultaneamente, cada um lidando com uma parte dos dados. Você pode fazer isso com Lookup/GetMetadata + ForEach + Copy. Consulte Copiar arquivos de vários contêineres ou Migrar dados do Amazon S3 para modelos de solução ADLS Gen2 como exemplo geral.

  • Verifique se o serviço relata algum erro de limitação na origem ou se o armazenamento de dados está em estado de alta utilização. Em caso afirmativo, reduza as cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do repositório de dados para aumentar o limite de limitação ou o recurso disponível.

• "Transferência - leitura a partir da fonte" apresentou um longo tempo de execução:

  • Verifique se a máquina IR auto-hospedada tem baixa latência ao conectar-se ao repositório de dados de origem. Se a sua fonte estiver na Azure, pode usar esta ferramenta para verificar a latência da máquina de Integração de Redes (IR) auto-hospedada para as regiões da Azure, quanto menos, melhor.

  • Verifique se a máquina de IR auto-hospedada tem largura de banda de entrada suficiente para ler e transferir os dados de forma eficiente. Se o seu armazenamento de dados de origem estiver em Azure, pode usar esta ferramenta para verificar a velocidade de download.

  • Verifique a tendência de consumo de CPU e memória do IR auto-hospedado no portal Azure -> na página de visão geral da sua Fábrica de Dados ou espaço de trabalho Synapse ->. Considere aumentar ou reduzir o IR se o uso da CPU for alto ou a memória disponível for baixa.

  • Adote as melhores práticas de carregamento de dados específicas do conector, se for aplicável. Por exemplo:

    • Ao copiar dados de Oracle, Netezza, Teradata, SAP HANA, SAP Table e SAP Open Hub), ative as opções de partição de dados para copiar dados em paralelo.

    • Ao copiar dados do HDFS, configure para usar o DistCp.

    • Ao copiar dados do Amazon Redshift, configure para usar o Redshift UNLOAD.

  • Verifique se o serviço relata algum erro de limitação na origem ou se o armazenamento de dados está sob alta utilização. Em caso afirmativo, reduza as cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do repositório de dados para aumentar o limite de limitação ou o recurso disponível.

  • Verifique o padrão de origem e destino de cópia:

    • Se você copiar dados de armazenamentos de dados habilitados para opção de partição, considere ajustar gradualmente as cópias paralelas. Muitas cópias paralelas podem até prejudicar o desempenho.

    • Caso contrário, considere dividir um único conjunto de dados de grandes dimensões em vários conjuntos de dados mais pequenos e permitir que esses trabalhos de cópia sejam executados simultaneamente, sendo que cada um aborda uma parte dos dados. Você pode fazer isso com Lookup/GetMetadata + ForEach + Copy. Consulte Copiar arquivos de vários contêineres, Migrar dados do Amazon S3 para o ADLS Gen2 ou Copiar em massa com modelos de solução de tabela de controle como exemplo geral.

• "Transferência - escrita para o destino" teve uma longa duração de execução

  • Adote as melhores práticas de carregamento de dados específicas do conector, se aplicável. Por exemplo, ao copiar dados para Azure Synapse Analytics, use a instrução PolyBase ou COPY.

  • Verifique se a máquina IR auto-hospedada tem baixa latência ao conectar-se ao armazenamento de dados de destino. Se o seu ponto de destino estiver na Azure, pode usar esta ferramenta para verificar a latência da máquina IR auto-hospedada para a região da Azure; quanto menor, melhor.

  • Verifique se a máquina IR auto-hospedada tem largura de banda de saída suficiente para transferir e gravar os dados de forma eficiente. Se o teu armazenamento de dados do sink estiver em Azure, podes usar esta ferramenta para verificar a velocidade de upload.

  • Verifique se a tendência de consumo de CPU e memória do IR auto-hospedado na página de visão geral da sua fábrica de dados ou do espaço de trabalho do Synapse no portal Azure > ->. Considere aumentar ou reduzir o IR se o uso da CPU for alto ou a memória disponível for baixa.

  • Verifique se o serviço relata algum erro de limitação no coletor ou se o armazenamento de dados está sob alta utilização. Em caso afirmativo, reduza as cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do repositório de dados para aumentar o limite de limitação ou o recurso disponível.

  • Considere afinar gradualmente as cópias paralelas. Muitas cópias paralelas podem até prejudicar o desempenho.

Desempenho do Conector e do IR

Esta seção explora alguns guias de solução de problemas de desempenho para determinado tipo de conector ou tempo de execução de integração.

O tempo de execução da atividade varia usando Azure IR vs Azure virtual network IR

O tempo de execução da atividade varia quando o conjunto de dados se baseia em diferentes Integration Runtime.

• Sintomas: simplesmente alternar a lista de serviços vinculados no conjunto de dados executa as mesmas atividades de pipeline, mas apresenta tempos de execução drasticamente diferentes. Quando o conjunto de dados é baseado no Integration Runtime da Rede Virtual Gerida, leva, em média, mais tempo do que quando é executado no Integration Runtime Padrão.

• Cause: Ao verificar os detalhes das execuções do pipeline, pode ver que o pipeline lento está a correr na rede virtual gerida (Rede Virtual) IR enquanto o normal está a correr no Azure IR. Por design, o IR de rede virtual gerida demora mais tempo de espera do que o Azure IR, pois não reservamos um nó de computação por instância de serviço, por isso há um aquecimento para cada atividade de cópia, e isso ocorre principalmente na junção de rede virtual em vez do Azure IR.

Baixo desempenho ao carregar dados no Base de Dados SQL do Azure

• Sintomas: Copiar dados para Base de Dados SQL do Azure torna-se lento.

• Causa: A causa raiz do problema é principalmente provocada pelo gargalo do lado do Base de Dados SQL do Azure. Seguem-se algumas causas possíveis:

  • O nível do Base de Dados SQL do Azure não é suficientemente alto.

  • Base de Dados SQL do Azure a utilização de DTU está próxima de 100%. Podes monitorizar desempenho e considerar atualizar o Base de Dados SQL do Azure tier.

  • Os índices não estão definidos corretamente. Remova todos os índices antes do carregamento de dados e recrie-os após a conclusão do carregamento.

  • WriteBatchSize não é grande o suficiente para se ajustar ao tamanho da linha do esquema. Tente expandir as propriedades para resolver o problema.

  • Em vez de inserção em massa, o procedimento armazenado está sendo usado, o que deve ter pior desempenho.

Timeout ou desempenho lento ao analisar ficheiro Excel de grande dimensão

• Sintomas:

  • Quando crias um conjunto de dados do Excel e importas o esquema da ligação ou armazenamento, pré-visualizas dados, listas ou atualizas folhas de cálculo, podes encontrar um erro de tempo de espera esgotado se o ficheiro Excel for de grande dimensão.

  • Quando usas a atividade de cópia para copiar dados de ficheiros grandes de Excel (>= 100 MB) para outra loja de dados, podes experienciar desempenho lento ou problemas de OOM.

• Causa:

  • Para operações como importação de esquema, visualização de dados e listagem de planilhas no conjunto de dados do Excel. O tempo limite é de 100 s e é estático. Para ficheiros Excel grandes, estas operações podem não terminar dentro do valor de time-out.

  • A atividade de cópia lê todo o ficheiro Excel para a memória e depois localiza a folha de cálculo e as células especificadas para ler os dados. Esse comportamento é devido ao SDK subjacente que o serviço usa.

• Resolução:

  • Para importar o esquema, você pode gerar um arquivo de exemplo menor, que é um subconjunto do arquivo original, e escolher "importar esquema do arquivo de exemplo" em vez de "importar esquema da conexão/armazenamento".

  • Para listar a planilha, na lista suspensa da planilha, você pode selecionar "Editar" e inserir o nome/índice da planilha.

  • Para copiar ficheiros grandes de Excel (>100 MB) para outro armazenamento, podes usar a fonte de Fluxo de Dados do Excel que permite leitura em streaming e proporciona um desempenho melhor.

O problema de falta de memória (OOM) ao ler ficheiros JSON/Excel/XML grandes

• Sintomas: Quando lês ficheiros JSON/Excel/XML grandes, encontra-se o problema de falta de memória (OOM) durante a execução da atividade.

• Causa:

  • Para arquivos XML grandes: O problema OOM de ler arquivos XML grandes é por design. A causa é que todo o arquivo XML deve ser lido na memória, pois é um único objeto, então o esquema é inferido e os dados são recuperados.
  • Para ficheiros Excel grandes: O problema OOM de ler ficheiros Excel grandes é intencional. A causa é que o SDK (POI/NPOI) usado deve ler todo o arquivo excel na memória, em seguida, inferir o esquema e obter dados.
  • Para grandes arquivos JSON: O problema OOM ao ler grandes arquivos JSON é intencional quando o arquivo JSON é um único objeto.

• Recomendação: Aplique uma das seguintes opções para resolver o problema.

  • Opção-1: Registre um tempo de execução de integração auto-hospedado on-line com máquina poderosa (alta CPU/memória) para ler dados de seu arquivo grande através de sua atividade de cópia.
  • Opção-2: Use memória otimizada e cluster de tamanho grande (por exemplo, 48 núcleos) para ler dados de seu arquivo grande através da atividade de fluxo de dados de mapeamento.
  • Opção-3: Divida o arquivo grande em arquivos pequenos e, em seguida, use a atividade de fluxo de dados de cópia ou mapeamento para ler a pasta.
  • Opção-4: Se estiveres bloqueado ou encontrares o problema de OOM ao copiar a pasta XML/Excel/JSON, usa a atividade foreach + a atividade de cópia/mapeamento do fluxo de dados no teu pipeline para gerir cada ficheiro ou subpasta.
  • Opção-5: Outros:
    • Para XML, utilize a atividade do Notebook com um cluster otimizado para memória para ler dados de ficheiros, se todos os ficheiros tiverem o mesmo esquema. Atualmente, o Spark tem diferentes implementações para lidar com XML.
    • Para JSON, use diferentes formulários de documento (por exemplo, Documento único, Documento por linha e Matriz de documentos) nas configurações JSON em Mapeamento da fonte de fluxo de dados. Se o conteúdo do ficheiro JSON for Documento por linha, consome poucos recursos de memória.

Outras referências

Aqui estão as referências de monitoramento e ajuste de desempenho para alguns dos armazenamentos de dados suportados:

• Azure Armazenamento Blob: Escalabilidade e metas de desempenho para armazenamento Blob e Lista de verificação de desempenho e escalabilidade para armazenamento Blob.
• Azure Armazenamento de Tabelas: Metas de escalabilidade e desempenho para armazenamento de Tabelas e Lista de verificação de desempenho e escalabilidade para armazenamento de Tabelas.
• Base de Dados SQL do Azure: Pode monitorizar o desempenho e verificar a percentagem da Unidade de Transação da Base de Dados (DTU).
• Azure Synapse Analytics: A sua capacidade é medida em Data Warehouse Units (DWUs). Ver Gerir o poder de computação em Azure Synapse Analytics (Visão geral).
• Azure Cosmos DB: níveis de desempenho em Azure Cosmos DB.
• SQL Server: Monitorizar e ajustar para desempenho.
• Servidor de arquivos local: ajuste de desempenho para servidores de ficheiros.

Conteúdos relacionados

Veja os outros artigos sobre a atividade de cópia:

• Visão geral da atividade de cópia
• Guia de desempenho e escalabilidade da atividade de cópia
• Funcionalidades de otimização de desempenho da atividade de cópia
• Migre dados do seu data lake ou data warehouse para Azure
• Migrar dados da Amazon S3 para Armazenamento do Azure