Solucionar problemas de desempenho da atividade de cópia

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Este artigo descreve como solucionar problemas de desempenho da atividade de cópia no Azure Data Factory.

Depois de executar uma atividade de cópia, você pode coletar o resultado da execução e as estatísticas de desempenho na exibição Monitoramento da atividade de cópia. A imagem a seguir mostra um exemplo.

Dicas de ajuste de desempenho

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

Como referência, no momento, as dicas de ajuste de desempenho mostram sugestões para os seguintes casos:

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

Os detalhes e as 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 (confira o exemplo no início deste artigo), que é especialmente útil para solucionar problemas de desempenho de cópia. O gargalo de sua execução de cópia é aquele com a duração mais longa. Consulte a tabela a seguir para definição de cada estágio e saiba como solucionar problemas da atividade de cópia no Azure IR e solucionar problemas da atividade de cópia no IR auto-hospedado com tais informações.

Solucionar problemas de atividade de cópia no IR Azure

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

Quando o desempenho da atividade de cópia não atender à sua expectativa, para solucionar problemas de atividade de cópia única em execução no Azure Integration Runtime, se você vir dicas de ajuste de desempenho mostradas na exibição monitoramento de cópia, aplique a sugestão e tente novamente. Caso contrário, entenda os detalhes da execução da atividade de cópia, verifique qual estágio tem a duração mais longa e aplique as diretrizes abaixo para melhorar o desempenho da cópia:

• "Script de pré-cópia" teve duração longa: significa que o script de pré-cópia em execução no banco de dados do coletor demora muito para ser concluído. Ajuste a lógica especificada do script de pré-cópia para melhorar o desempenho. Se precisar de ajuda adicional para melhorar o script, entre em contato com sua equipe do banco de dados.

• "Tempo de transferência até o primeiro byte" com duração de trabalho longa: sua consulta de origem demora muito para retornar dados. Isso pode significar que a consulta leva muito tempo para ser processada em sua origem porque a origem está ocupada com outras tarefas ou a consulta não é ideal, ou os dados são armazenados de tal forma que leva muito tempo para ser recuperada. Considere se outras consultas estão em execução nessa origem ao mesmo tempo ou se há atualizações que você pode fazer em sua consulta para que ela possa recuperar dados mais rapidamente. Se houver uma equipe que gerencie sua fonte de dados, entre em contato com eles para modificar sua consulta ou verificar o desempenho da origem.

• A "Origem da listagem de transferência" tem uma duração de trabalho longa: isso significa que a enumeração de arquivos de origem ou partições de dados de banco de dado de origem está lenta.

  • Ao copiar dados da fonte baseada em arquivo, se você usar o filtro curinga no caminho da pasta ou no nome do arquivo (wildcardFolderPath ou wildcardFileName), ou usar o filtro de tempo da última modificação do arquivo (modifiedDatetimeStart ou modifiedDatetimeEnd), observe que esse filtro resultaria na atividade de cópia listando todos os arquivos na pasta especificada para o lado do cliente e, em seguida, aplicaria o filtro. Tal enumeração de arquivo poderia se tornar o gargalo, principalmente quando apenas pequenos conjuntos de arquivos atingirem a regra de filtro.

    • Verifique se você pode copiar arquivos com base no caminho ou nome do arquivo particionado com data e hora. Dessa forma, o lado da fonte de listagem não fica sobrecarregado.

    • Verifique se você pode usar o filtro nativo do armazenamento de dados em vez disso, especificamente “prefixo” para Amazon S3/Armazenamento de blobs do Azure/Arquivos do Azure e “listAfter/listBefore” para ADLS Gen1. Esses filtros são filtros do lado do servidor de armazenamento de dados e teriam um desempenho melhor.

    • Considere dividir um único conjunto de dados grande em vários conjuntos de dados menores e permitir que esses trabalhos de cópia sejam executados simultaneamente, cada um lidando com uma parte dos dados. Você pode fazer isso com Lookup/GetMetadata + ForEach + Copy. Confira os modelos de solução Copiar arquivos de vários contêineres ou Migrar dados do Amazon S3 para 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. Nesse caso, reduza suas cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do armazenamento de dados para aumentar o limite ou o recurso disponível.

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

• "Transferência – leitura da origem" experimentou uma longa duração de execução:

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

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

  • Verifique a fonte de cópia e o padrão de coletor:

    • Se o padrão de cópia permitir mais de quatro DIUs (unidades de integração de dados) – confira esta seção para ver mais detalhes. Geralmente você pode tentar aumentar os DIUs para obter um melhor desempenho.

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

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

• "Transferência – gravação no coletor" teve uma duração de trabalho longa:

  • Adote as melhores práticas específicas para carregamento de dados 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 seu armazenamento de dados está em alta utilização. Nesse caso, reduza suas cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do armazenamento de dados para aumentar o limite ou o recurso disponível.

  • Verifique a fonte de cópia e o padrão de coletor:

    • Se o padrão de cópia permitir mais de quatro DIUs (unidades de integração de dados) – confira esta seção para ver mais detalhes. Geralmente você pode tentar aumentar os DIUs para obter um melhor desempenho.

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

  • Use Azure IR na mesma região ou perto da região do armazenamento de dados de destino.

Solucionar problemas de atividade de cópia no IR auto-hospedado

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

Quando o desempenho da cópia não atender à sua expectativa, para solucionar problemas de atividade de cópia única em execução no Azure Integration Runtime, se você vir dicas de ajuste de desempenho mostradas na exibição monitoramento de cópia, aplique a sugestão e tente novamente. Caso contrário, entenda os detalhes da execução da atividade de cópia, verifique qual estágio tem a duração mais longa e aplique as diretrizes abaixo para melhorar o desempenho da cópia:

• "Fila" tem uma duração longa: isso significa que a atividade de cópia aguarda muito tempo na fila até que o IR auto-hospedado tenha o recurso a ser executado. Verifique a capacidade e o uso do IR e escalone verticalmente ou horizontalmente de acordo com sua carga de trabalho.

• "Tempo de transferência até o primeiro byte" com duração de trabalho longa: isso significa que sua consulta de origem demora muito 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.

• A "Origem da listagem de transferência" tem uma duração de trabalho longa: isso significa que a enumeração de arquivos de origem ou partições de dados de banco de dado de origem está lenta.

  • Verifique se o computador do IR auto-hospedado tem baixa latência conectando-se ao armazenamento de dados de origem. Se sua fonte estiver no Azure, você poderá usar essa ferramenta para verificar a latência do computador de IR auto-hospedado internamente para a região do Azure: quanto menos, melhor.

  • Ao copiar dados da fonte baseada em arquivo, se você usar o filtro curinga no caminho da pasta ou no nome do arquivo (wildcardFolderPath ou wildcardFileName), ou usar o filtro de tempo da última modificação do arquivo (modifiedDatetimeStart ou modifiedDatetimeEnd), observe que esse filtro resultaria na atividade de cópia listando todos os arquivos na pasta especificada para o lado do cliente e, em seguida, aplicaria o filtro. Tal enumeração de arquivo poderia se tornar o gargalo, principalmente quando apenas pequenos conjuntos de arquivos atingirem a regra de filtro.

    • Verifique se você pode copiar arquivos com base no caminho ou nome do arquivo particionado com data e hora. Dessa forma, o lado da fonte de listagem não fica sobrecarregado.

    • Verifique se você pode usar o filtro nativo do armazenamento de dados em vez disso, especificamente “prefixo” para Amazon S3/Armazenamento de blobs do Azure/Arquivos do Azure e “listAfter/listBefore” para ADLS Gen1. Esses filtros são filtros do lado do servidor de armazenamento de dados e teriam um desempenho melhor.

    • Considere dividir um único conjunto de dados grande em vários conjuntos de dados menores e permitir que esses trabalhos de cópia sejam executados simultaneamente, cada um lidando com uma parte dos dados. Você pode fazer isso com Lookup/GetMetadata + ForEach + Copy. Confira os modelos de solução Copiar arquivos de vários contêineres ou Migrar dados do Amazon S3 para 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. Nesse caso, reduza suas cargas de trabalho no armazenamento de dados ou tente entrar em contato com o administrador do armazenamento de dados para aumentar o limite ou o recurso disponível.

• "Transferência – leitura da origem" experimentou uma longa duração de execução:

  • Verifique se o computador do IR auto-hospedado tem baixa latência conectando-se ao armazenamento de dados de origem. Se sua origem estiver no Azure, você poderá usar esta ferramenta para verificar a latência da máquina de IR auto-hospedada para as regiões do Azure, quanto menor, melhor.

  • Verifique se o computador do IR auto-hospedado tem largura de banda de entrada suficiente para ler e transferir os dados com eficiência. Se o armazenamento de dados de origem estiver em Azure, você poderá usar a ferramenta para verificar a velocidade de download.

  • Verifique a tendência de uso da CPU e da memória do IR auto-hospedado no portal do Azure>, na página de visão geral do seu data factory ou workspace do Synapse>. Considere escalar verticalmente ou horizontalmente o IR se o uso da CPU for alto ou se a memória disponível estiver baixa.

  • Se for aplicável, adote a prática recomendada de carregamento de dados específicos do conector. Por exemplo:

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

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

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

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

  • Verifique a fonte de cópia e o padrão de coletor:

    • Se você copiar dados de armazenamentos de dados com a opção de partição habilitada, considere ajustar gradualmente as cópias paralelas. Muitas cópias paralelas podem prejudicar o desempenho.

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

• "Transferência – gravação no coletor" teve uma duração de trabalho longa:

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

  • Verifique se o computador do IR auto-hospedado tem baixa latência conectando-se ao armazenamento de dados do coletor. Se o seu coletor estiver no Azure, você poderá usar esta ferramenta para verificar a latência do computador de IR auto-hospedado internamente para a região do Azure: quanto menos, melhor.

  • Verifique se o computador do IR auto-hospedado tem largura de banda de saída suficiente para transferir e gravar os dados com eficiência. Se o armazenamento de dados de destino estiver na Azure, você poderá usar esta ferramenta para verificar a velocidade de upload.

  • Verifique a tendência de uso da CPU e da memória do IR auto-hospedado no portal do Azure>, na página de visão geral do seu data factory ou workspace do Synapse>. Considere escalar verticalmente ou horizontalmente o IR se o uso da CPU for alto ou se a memória disponível estiver baixa.

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

  • Considere ajustar gradualmente as cópias paralelas. Muitas cópias paralelas podem 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 runtime de integração.

O tempo de execução da atividade varia entre o Azure IR e o IR da rede virtual do Azure.

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

• Sintomas: simplesmente alternar a lista suspensa Serviço Vinculado no conjunto de dados executa as mesmas atividades de pipeline, mas tem tempos de execução drasticamente diferentes. Quando o conjunto de dados é baseado no Runtime de Integração da Rede Virtual Gerenciada, demora mais em média para ser executado do que quando é baseado no Runtime de Integração Padrão.

• Causa: ao verificar os detalhes das execuções de pipeline, você poderá ver que o pipeline lento está em execução no IR da rede virtual gerenciada enquanto o pipeline normal está em execução no Azure IR. Por design, o IR da rede virtual gerenciada leva mais tempo de fila do que o Azure IR, pois não estamos reservando um nó de computação por instância de serviço, portanto, há um aquecimento para cada atividade Copy iniciar, e isso ocorre principalmente na junção de rede virtual em vez do Azure IR.

Baixo desempenho ao carregar dados em Banco de Dados SQL do Azure

• Sintomas: o processo de copiar dados para o Banco de Dados SQL do Azure torna-se lento.

• Cause: a causa raiz do problema é principalmente o gargalo do lado do Banco de Dados SQL do Azure. Estas são as possíveis causas:

  • O nível do Banco de Dados SQL do Azure não é alto o suficiente.

  • O uso de DTUs do Banco de Dados SQL do Azure está próximo de 100%. Você pode monitorar o desempenho e considerar atualizar a camada do Banco de Dados SQL do Azure.

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

  • O WriteBatchSize não é grande o suficiente para comportar o tamanho da linha do esquema. Tente aumentar a propriedade para o problema.

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

Tempo limite ou desempenho lento ao analisar um arquivo grande do Excel

• Sintomas:

  • Quando você cria o conjunto de dados do Excel e importa o esquema de conexões/armazenamento, visualizar dados, listar ou atualizar planilhas, poderá encontrar um erro de tempo limite se o arquivo do Excel for grande em tamanho.

  • Quando você usa a atividade de cópia para copiar dados de um arquivo de Excel grande (>= 100 MB) para outro armazenamento de dados, você pode enfrentar um desempenho lento ou problema de OOM.

• Causa:

  • Para operações como importar esquema, visualizar dados e listar planilhas no conjunto de dados do Excel. O tempo limite é de 100 s e estático. Para um arquivo de Excel grande, essas operações podem não ser concluídas dentro do valor de tempo limite.

  • A atividade de cópia lê todo o arquivo Excel na memória e, em seguida, localiza a planilha e as células especificadas para ler dados. Esse comportamento se deve 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 um arquivo grande do Excel (>100 MB) para outro repositório, você pode usar a fonte do Fluxo de Dados do Excel que oferece leitura em streaming e tem melhor desempenho.

O problema do OOM de ler arquivos JSON/Excel/XML grandes

• Symptoms: ao ler arquivos JSON/Excel/XML grandes, você encontra o problema de memória insuficiente (OOM) durante a execução da atividade.

• Causa:

  • Para arquivos XML grandes: o problema de OOM ao 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 arquivos grandes do Excel: o problema de OOM ao ler arquivos grandes do Excel é esperado. A causa é que o SDK (POI/NPOI) usado deve ler todo o arquivo do Excel na memória e, em seguida, inferir o esquema e obter dados.
  • Para arquivos JSON grandes: o problema de OOM ao ler arquivos JSON grandes é esperado quando o arquivo JSON é um único objeto.

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

  • Opção-1: registre um runtime de integração auto-hospedada online com um computador avançado (alta CPU/memória) para ler dados do arquivo grande por meio da atividade de cópia.
  • Opção-2: use a memória otimizada e o cluster de tamanho grande (por exemplo, 48 núcleos) para ler os dados do arquivo grande por meio da atividade de fluxo de dados de mapeamento.
  • Opção-3: divida o arquivo grande em pequenos e use a atividade de fluxo de dados de cópia ou mapeamento para ler a pasta.
  • Opção-4: se você estiver travado ou atender ao problema do OOM durante a cópia da pasta XML/Excel/JSON, use a atividade foreach + atividade de fluxo de dados de mapeamento/cópia no pipeline para manipular cada arquivo ou subpasta.
  • Opção-5: outros:
    • Para XML, use a atividade do notebook com cluster otimizado para memória para ler dados de arquivos se cada arquivo tiver o mesmo esquema. Atualmente, o Spark tem implementações diferentes 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 sob fonte de fluxo de dados de mapeamento. Se o conteúdo do arquivo JSON for Documento por linha, ele consumirá pouca memória.

Outras referências

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

• Azure Armazenamento de Blobs: Escalabilidade e metas de desempenho para armazenamento de blobs e Lista de verificação de desempenho e escalabilidade para armazenamento de blobs.
• Azure Armazenamento de Tabelas: Objetivos de escalabilidade e desempenho para Armazenamento de Tabelas e Checklist de performance e escalabilidade para Armazenamento de Tabelas.
• Banco de Dados SQL do Azure: você pode monitorar o desempenho e verificar a porcentagem de DTU (Unidade de Transação de Banco de Dados).
• Azure Synapse Analytics: sua capacidade é medida em DWUs (unidades de Data Warehouse). Consulte Gerenciar poder de computação no Azure Synapse Analytics (Visão Geral).
• Azure Cosmos DB: Níveis de desempenho no Azure Cosmos DB.
• SQL Server: monitoramento e ajuste do desempenho.
• Servidor de arquivos local: ajuste de desempenho para servidores de arquivos.

Conteúdo relacionado

Confira os outros artigos sobre atividade de cópia:

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