Por que meu trabalho do AWS Glue ETL está em execução há tanto tempo?

Data da última atualização: 20/08/2021

Meu trabalho do AWS Glue está em execução há muito tempo.

-ou-

Minha tarefa complexa do AWS Glue está demorando muito para ser concluída.

Descrição breve

Alguns motivos comuns pelos quais seus trabalhos do AWS Glue demoram muito para ser concluídos são os seguintes:

  • Grandes conjuntos de dados
  • Distribuição não uniforme de dados nos conjuntos de dados
  • Distribuição desigual de tarefas entre os executores
  • Subprovisionamento de recursos

Resolução

Habilitar as métricas

O AWS Glue fornece métricas do Amazon CloudWatch que podem ser usadas para fornecer informações sobre os executores e a quantidade de dados feitos por cada executor. Você pode habilitar as métricas do CloudWatch em seu trabalho do AWS Glue seguindo um destes procedimentos:

Usando um parâmetro especial: adicione o seguinte argumento ao trabalho do AWS Glue. O parâmetro permite coletar métricas para a criação de perfil de trabalho para a execução do trabalho. As métricas estão disponíveis no console do AWS Glue e no console do CloudWatch.

Key: --enable-metrics

Uso do console do AWS Glue: para habilitar as métricas em um trabalho existente, faça o seguinte:

  1. Abra o console do AWS Glue.
  2. No painel de navegação, escolha Trabalhos.
  3. Selecione o trabalho para o qual você deseja habilitar as métricas.
  4. Escolha Ação e, em seguida, escolha Editar trabalho.
  5. Em Opções de monitoramento, selecione Métricas de trabalho.
  6. Escolha Salvar.

Uso da API: use a API do AWS Glue UpdateJob com a API -enable-metrics como o parâmetro DefaultArguments para habilitar as métricas em um trabalho existente.

Observação: o AWS Glue 2.0 não usa o YARN que relata métricas. Isso significa que você não pode obter algumas das métricas do executor, como numberMaxNeededExecutors e numberAllExecutor, para o AWS Glue 2.0.

Habilitar registro contínuo

Se você habilitar o registro contínuo em seu trabalho do AWS Glue, os logs de driver e executor em tempo real serão enviados para o CloudWatch a cada cinco segundos. Com essas informações de registro em tempo real, você pode obter mais detalhes sobre o trabalho em execução. Para obter mais informações, consulte Habilitação do registro contínuo para trabalhos do AWS Glue.

Confira os logs do driver e do executor

Nos logs do driver, confira se há tarefas executadas por um longo tempo antes de serem concluídas. Por exemplo:

2021-04-15 10:53:54,484 ERROR executionlogs:128 - g-7dd5eec38ff57a273fcaa35f289a99ecc1be6901:2021-04-15 10:53:54,484 INFO [task-result-getter-1] scheduler.TaskSetManager (Logging.scala:logInfo(54)): Finished task 0.0 in stage 7.0 (TID 139) in 4538 ms on 10.117.101.76 (executor 10) (13/14)
...
2021-04-15 12:11:30,692 ERROR executionlogs:128 - g-7dd5eec38ff57a273fcaa35f289a99ecc1be6901:2021-04-15 12:11:30,692 INFO [task-result-getter-3] scheduler.TaskSetManager (Logging.scala:logInfo(54)): Finished task 13.0 in stage 7.0 (TID 152) in 4660742 ms on 10.117.97.97 (executor 11) (14/14)

Nestes logs, você pode ver que uma única tarefa levou 77 minutos para ser concluída. Use estas informações para revisar por que a tarefa específica está demorando muito. Você pode fazer isso usando a interface do usuário da Web do Apache Spark. A interface do usuário do Spark fornece informações bem estruturadas para diferentes estágios, tarefas e executores.

Habilitar a interface do usuário do Spark

Você pode usar a interface do usuário do Spark para solucionar problemas de trabalhos do Spark que são executados por um longo tempo. Ao iniciar o servidor de histórico do Spark e ativar os logs da interface do usuário do Spark, você pode obter informações sobre os estágios e as tarefas. Você pode usar os logs para saber como as tarefas são executadas pelos operadores. Você pode habilitar a interface do usuário do Spark usando o console do AWS Glue ou a AWS Command Line Interface (AWS CLI). Para obter mais informações, consulte Habilitação da interface do usuário da Web do Apache Spark para trabalhos do AWS Glue.

Depois que o trabalho for concluído, você poderá ver os logs do driver semelhantes aos seguintes:

ERROR executionlogs:128 - example-task-id:example-timeframe INFO [pool-2-thread-1] s3n.MultipartUploadOutputStream (MultipartUploadOutputStream.java:close(414)): close closed:false s3://dox-example-bucket/spark-application-1626828545941.inprogress

Depois de analisar os logs do trabalho, você pode iniciar o servidor de histórico do Spark em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) ou usando o Docker. Abra a interface do usuário e navegue até a guia Executor para conferir se um determinado executor está sendo executado por mais tempo. Neste caso, a distribuição desigual do trabalho e a subutilização dos recursos disponíveis podem ser causadas devido a uma distorção de dados no conjunto de dados. Na guia Estágios, você pode obter mais informações e estatísticas sobre os estágios que demoraram muito. Você pode encontrar detalhes sobre se os estágios envolveram derramamentos aleados que são caros e demorados.

Planejamento de capacidade para unidades de processamento de dados (DPUs)

Se todos os executores contribuírem igualmente para o trabalho, mas o trabalho ainda demorar muito para ser concluído, considere adicionar mais operadores ao seu trabalho para melhorar a velocidade. O planejamento da capacidade da DPU pode ajudá-lo a evitar o seguinte:

  • Subprovisionamento que pode resultar em tempo de execução mais lento
  • Provisionamento excessivo que incorre em custos mais altos, mas fornece resultados no mesmo período de tempo

A partir das métricas do CloudWatch, você pode obter informações sobre o número de executores usados atualmente e o número máximo de executores necessários. O número de DPUs necessárias depende do número de partições de entrada e do tipo de operador solicitado.

Não se esqueça na sequência da definição do número de partições de entrada:

  • Se os arquivos do Amazon Simple Storage Service (Amazon S3) não forem divisíveis, o número de partições será igual ao número de arquivos de entrada.
  • Se os arquivos do Amazon S3 forem divisíveis e os dados não forem estruturados/semiestruturados, o número de partições será igual ao tamanho total do arquivo / 64 MB. Se o tamanho de cada arquivo for menor que 64 MB, o número de partições será igual ao número de arquivos.
  • Se os arquivos do Amazon S3 forem divisíveis e os dados estiverem estruturados, o número de partições será igual ao tamanho total do arquivo / 128 MB.

Faça o seguinte para calcular o número ideal de DPUs:

Por exemplo, suponha que o número de partições de entrada seja 428. Em seguida, você pode calcular o número ideal de DPUs pela seguinte fórmula:

Número máximo de executores necessários = número de partições de entrada / número de tarefas por executor = 428/4 = 107

Tenha em mente o seguinte:

  • O tipo de operador padrão é compatível com 4 tarefas por executor
  • O G.1X é compatível com 8 tarefas por executor
  • O G.2X é compatível com 16 tarefas por executor

O tipo de operador padrão tem dois executores, incluindo um driver, em um nó. Um destes executores é um driver no Spark. Portanto, você precisa de 108 executores.

O número de DPUs necessárias = (nº de executores/nº de executores por nó) + 1 DPU = (108/2) + 1 = 55.