Share via

Solucionar problemas de desempenho da atividade de cópia

  • Artigo

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

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 seguir, é mostrado um exemplo.

Monitor copy activity run details

Dicas de ajuste de desempenho

Em alguns cenários, ao executar uma atividade de cópia, você verá “Dicas de ajuste de desempenho” na parte superior, conforme mostrado no exemplo acima. 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:

Categoria Dicas de ajuste de desempenho
Específico do armazenamento de dados Carregando dados no Azure Synapse Analytics: sugira usar o PolyBase ou a instrução COPY se ele não for usado.
  Copiando dados de/para o Banco de Dados SQL do Azure: quando a DTU está sob alta utilização, sugira atualizar para uma camada superior.
  Copiando dados de/para o Azure Cosmos DB: quando a RU está sob alta utilização, sugira atualizar para uma RU maior.
Copiando dados da tabela SAP: ao copiar uma grande quantidade de dados, sugira aproveitar a opção de partição do conector SAP para habilitar a carga paralela e aumentar o número máximo de partições.
  Ingestão de dados do Amazon Redshift: sugira o uso de UNLOAD se ele não for usado.
Limitação do armazenamento de dados Se várias operações de leitura/gravação forem limitadas pelo armazenamento de dados durante a cópia, sugira verificar e aumentar a taxa de solicitação permitida para o armazenamento de dados ou reduzir a carga de trabalho simultânea.
runtime de integração Se você usar um IR (runtime de integração auto-hospedada) e a atividade de cópia aguardar tempo demais na fila até que o IR tenha o recurso disponível para ser executado, sugira escalar horizontalmente/verticalmente o IR.
  Se você usar um Azure Integration Runtime que esteja em uma região não ideal, resultando em leitura/gravação lenta, sugira configurar para usar um IR em outra região.
Tolerância a falhas Se você configurar a tolerância a falhas e ignorar linhas incompatíveis resultar em desempenho lento, sugira verificar se os dados de origem e de coletor são compatíveis.
Cópia em etapas Se a cópia preparada estiver configurada, mas não for útil para seu par de origem-coletor, sugira removê-la.
Retomar Quando a atividade de cópia é retomada do último ponto de falha, mas você altera a configuração DIU após a execução original, observe que a nova configuração DIU não tem efeito.

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. Confira a tabela a seguir na definição de cada estágio e saiba como Solucionar problemas de atividade de cópia no Azure IR e Solucionar problemas de atividade de cópia em IR auto-hospedado com tais informações.

Estágio Descrição
Fila O tempo decorrido até que a atividade de cópia realmente seja iniciada no runtime de integração.
Script de pré-cópia O tempo decorrido entre a atividade de cópia que começa no IR e o término da atividade de cópia com a execução do script de pré-cópia no armazenamento de dados de coletor. Aplique esse valor ao configurar o script de pré-cópia para coletores de banco de dados, por exemplo, ao gravar dados no Banco de Dados SQL do Azure, faça uma limpeza antes de copiar novos dados.
Transferência O tempo decorrido entre o fim da etapa anterior e o IR transferindo todos os dados da origem para o coletor.
Observe que as subetapas em transferência são executadas em paralelo, e algumas operações não são mostradas agora, por exemplo, analisar/gerar o formato de arquivo.

- Tempo até o primeiro byte: o tempo decorrido entre o fim da etapa anterior e a hora em que o IR recebe o primeiro byte do armazenamento de dados de origem. Aplica-se a fontes não baseadas em arquivo.
- Fonte de listagem: a quantidade de tempo gasto na enumeração de arquivos de origem ou partições de dados. O último se aplica quando você configura opções de partição para fontes de banco de dados, por exemplo, ao copiar dados de bancos de dados como Oracle/SAP HANA/Teradata/Netezza/etc.
-Lendo da origem: a quantidade de tempo gasto na recuperação de dados do armazenamento de dados de origem.
- Lendo da origem: a quantidade de tempo gasto na gravação de dados no armazenamento de dados do coletor. Observe que alguns conectores não têm essa métrica no momento, incluindo a Pesquisa de IA do Azure, o Azure Data Explorer, o armazenamento de tabelas do Azure, o Oracle, o SQL Server, o Common Data Service, o Dynamics 365, o Dynamics CRM e o Salesforce/Salesforce Service Cloud.

Solucionar problemas de atividade de cópia no Azure IR

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 do script de pré-cópia especificada para aprimorar 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: 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.

    • 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 um filtro do lado do servidor do armazenamento de dados e teriam um desempenho muito 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 o Azure IR na mesma região de armazenamento de dados de origem ou em uma região próxima.

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

    • Adote a melhor prática de carregamento de dados específicos 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 4 DIUs (unidades de integração de dados) – confira esta seção para ver mais detalhes. Geralmente você pode tentar aumentar o 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 o Azure IR na mesma região de armazenamento de dados de origem ou em uma região próxima.

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

    • Adote a melhor prática de carregamento de dados específicos do conector se aplicável. Por exemplo, ao copiar dados para o Azure Synapse Analytics, use o PolyBase ou a instrução 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 4 DIUs (unidades de integração de dados) – confira esta seção para ver mais detalhes. Geralmente você pode tentar aumentar o DIUs para obter um melhor desempenho.

      • Caso contrário, ajuste gradualmente as cópias paralelas. Observe que muitas cópias paralelas podem até mesmo prejudicar o desempenho.

    • Use o Azure IR na mesma região de armazenamento de dados do coletor ou em uma região próxima.

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 um tempo na fila até que o IR auto-hospedado tenha o recurso a ser executado. Verifique a capacidade e o uso do IR e escale vertical 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 um filtro do lado do servidor do armazenamento de dados e teriam um desempenho muito 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" tem uma duração de trabalho longa:

    • 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 as regiões do Azure: quanto menos, 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 no Azure, você poderá usar essa 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.

    • Adote a melhor prática de carregamento de dados específicos do conector se aplicável. Por exemplo:

    • 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:

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

    • Adote a melhor prática de carregamento de dados específicos do conector se aplicável. Por exemplo, ao copiar dados para o Azure Synapse Analytics, use o PolyBase ou a instrução 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 do coletor estiver no 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. Observe que muitas cópias paralelas podem até mesmo 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 de acordo com o Azure IR x o IR da VNet do Azure

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

  • 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 informações é baseado no Integration Runtime da rede virtual gerenciada, leva mais tempo em média do que a execução baseada no Integration Runtime padrão.

  • Causa: ao verificar os detalhes das execuções de pipeline, você pode ver que o pipeline lento está em execução no IR (rede virtual) da VNet gerenciada enquanto o normal está em execução no Azure IR. Por padrão, o IR da VNet gerenciada leva mais tempo na 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 tempo de espera para cada atividade de cópia ser iniciada e ocorre principalmente na VNet em vez do Azure IR.

Baixo desempenho durante o carregamento de dados no Banco de Dados SQL do Azure

  • Sintomas: a cópia de dados para o Banco de Dados SQL do Azure torna-se lenta.

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

    • A camada do Banco de Dados SQL do Azure não é alta o suficiente.

    • O uso da DTU do Banco de Dados SQL do Azure está próximo de 100%. Você pode monitorar o desempenho e considerar a atualização da 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.

    • WriteBatchSize não é grande o suficiente para ajustar 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, dados de pré-visualização, lista ou atualização de planilhas, pode 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 grande do Excel (>= 100 MB) para outro armazenamento de dados, é possível ocorrer um problema de desempenho ou OOM lento.

  • Causa:

    • Para operações como importação de esquema, visualização de dados e listagem de planilhas no conjunto do dados do Excel, o tempo limite é de 100 s e estático. Para grandes arquivos do Excel, essas operações podem não ser concluídas dentro do valor temporal.

    • A atividade de cópia lê o arquivo inteiro do Excel na memória e, em seguida, localiza a planilha e as células especificadas para ler os 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 a planilha de listagem, no menu suspenso da planilha, você pode clicar em "Editar" e inserir o nome/índice da planilha em vez disso.

    • Para copiar um arquivo grande do Excel (>100 MB) em outro repositório, use a origem do Excel do Fluxo de Dados que dá suporte à leitura de streaming e melhora o desempenho.

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

  • Sintomas: 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 é esperado. 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 grande tamanho (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 preso 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á muito 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:

Conteúdo relacionado

Confira os outros artigos sobre atividade de cópia: