Solucionar problemas de gargalos de desempenho no Azure Databricks

Nota

Este artigo conta com uma biblioteca de código aberto hospedada no GitHub em: https://github.com/mspnp/spark-monitoring.

A biblioteca original suporta o Azure Databricks Runtimes 10.x (Spark 3.2.x) e anteriores.

O Databricks contribuiu com uma versão atualizada para dar suporte ao Azure Databricks Runtimes 11.0 (Spark 3.3.x) e superior na l4jv2 ramificação em: https://github.com/mspnp/spark-monitoring/tree/l4jv2.

Observe que a versão 11.0 não é compatível com versões anteriores devido aos diferentes sistemas de registro usados no Databricks Runtimes. Certifique-se de usar a compilação correta para seu Databricks Runtime. A biblioteca e o repositório GitHub estão em modo de manutenção. Não há planos para novos lançamentos, e o suporte a problemas será apenas o melhor esforço. Para quaisquer perguntas adicionais sobre a biblioteca ou o roteiro para monitoramento e registro em log de seus ambientes do Azure Databricks, entre em contato com azure-spark-monitoring-help@databricks.com.

Este artigo descreve como usar painéis de monitoramento para encontrar gargalos de desempenho em trabalhos do Spark no Azure Databricks.

O Azure Databricks é um serviço de análise baseado no Apache Spark que facilita o desenvolvimento e a implantação rápidos de análises de big data. Monitorar e solucionar problemas de desempenho é essencial ao operar cargas de trabalho do Azure Databricks de produção. Para identificar problemas comuns de desempenho, é útil usar visualizações de monitoramento com base em dados de telemetria.

Pré-requisitos

Para configurar os painéis do Grafana mostrados neste artigo:

• Configure seu cluster Databricks para enviar telemetria para um espaço de trabalho do Log Analytics usando a Biblioteca de Monitoramento do Azure Databricks. Para obter detalhes, consulte o Leiame do GitHub.

• Implante o Grafana em uma máquina virtual. Para obter mais informações, consulte Usar painéis para visualizar métricas do Azure Databricks.

O painel do Grafana implantado inclui um conjunto de visualizações de séries temporais. Cada gráfico é um gráfico de série temporal de métricas relacionadas a um trabalho do Apache Spark, os estágios do trabalho e as tarefas que compõem cada estágio.

Visão geral do desempenho do Azure Databricks

O Azure Databricks é baseado no Apache Spark, um sistema de computação distribuída de uso geral. O código do aplicativo, conhecido como trabalho, é executado em um cluster Apache Spark, coordenado pelo gerenciador de cluster. Em geral, um trabalho é a unidade de computação de mais alto nível. Um trabalho representa a operação completa executada pelo aplicativo Spark. Uma operação típica inclui a leitura de dados de uma fonte, a aplicação de transformações de dados e a gravação dos resultados no armazenamento ou em outro destino.

Os trabalhos são divididos em fases. O trabalho avança através dos estágios sequencialmente, o que significa que os estágios posteriores devem esperar que os estágios anteriores sejam concluídos. Os estágios contêm grupos de tarefas idênticas que podem ser executadas em paralelo em vários nós do cluster Spark. As tarefas são a unidade mais granular de execução que ocorre em um subconjunto dos dados.

As próximas seções descrevem algumas visualizações de painel que são úteis para a solução de problemas de desempenho.

Latência de trabalho e estágio

A latência do trabalho é a duração da execução de um trabalho desde o seu início até à sua conclusão. Ele é mostrado como percentis de uma execução de trabalho por cluster e ID de aplicativo, para permitir a visualização de valores atípicos. O gráfico a seguir mostra um histórico de trabalho onde o percentil 90 atingiu 50 segundos, embora o percentil 50 tenha sido consistentemente em torno de 10 segundos.

Investigue a execução de trabalhos por cluster e aplicativo, procurando picos de latência. Depois que clusters e aplicativos com alta latência forem identificados, passe a investigar a latência do estágio.

A latência do estágio também é mostrada como percentis para permitir a visualização de valores atípicos. A latência do estágio é dividida por cluster, aplicativo e nome do palco. Identifique picos na latência da tarefa no gráfico para determinar quais tarefas estão atrasando a conclusão do estágio.

O gráfico de taxa de transferência do cluster mostra o número de trabalhos, estágios e tarefas concluídas por minuto. Isso ajuda você a entender a carga de trabalho em termos do número relativo de estágios e tarefas por trabalho. Aqui você pode ver que o número de trabalhos por minuto varia entre 2 e 6, enquanto o número de estágios é de cerca de 12 – 24 por minuto.

Soma da latência de execução da tarefa

Essa visualização mostra a soma da latência de execução de tarefas por host em execução em um cluster. Use este gráfico para detetar tarefas que são executadas lentamente devido à lentidão do host em um cluster ou a uma alocação incorreta de tarefas por executor. No gráfico a seguir, a maioria dos hosts tem uma soma de cerca de 30 segundos. No entanto, dois dos anfitriões têm somas que giram em torno de 10 minutos. Os hosts estão sendo executados lentamente ou o número de tarefas por executor está mal alocado.

O número de tarefas por executor mostra que dois executores recebem um número desproporcional de tarefas, causando um gargalo.

Métricas de tarefas por estágio

A visualização de métricas de tarefa fornece o detalhamento de custo para a execução de uma tarefa. Você pode usá-lo para ver o tempo relativo gasto em tarefas como serialização e desserialização. Esses dados podem mostrar oportunidades de otimização — por exemplo, usando variáveis de transmissão para evitar o envio de dados. As métricas da tarefa também mostram o tamanho dos dados aleatórios de uma tarefa e os tempos de leitura e gravação aleatórios. Se esses valores forem altos, isso significa que muitos dados estão se movendo pela rede.

Outra métrica de tarefa é o atraso do agendador, que mede quanto tempo leva para agendar uma tarefa. Idealmente, esse valor deve ser baixo em comparação com o tempo de computação do executor, que é o tempo gasto realmente executando a tarefa.

O gráfico a seguir mostra um tempo de atraso do agendador (3,7 s) que excede o tempo de computação do executor (1,1 s). Isso significa que se gasta mais tempo esperando que as tarefas sejam agendadas do que fazendo o trabalho real.

Neste caso, o problema foi causado por ter muitas partições, o que causou muita sobrecarga. A redução do número de partições reduziu o tempo de atraso do agendador. O gráfico seguinte mostra que a maior parte do tempo é gasto na execução da tarefa.

Taxa de transferência e latência de streaming

A taxa de transferência de streaming está diretamente relacionada ao streaming estruturado. Há duas métricas importantes associadas à taxa de transferência de streaming: linhas de entrada por segundo e linhas processadas por segundo. Se as linhas de entrada por segundo superarem as linhas processadas por segundo, isso significa que o sistema de processamento de fluxo está ficando para trás. Além disso, se os dados de entrada vierem de Hubs de Eventos ou Kafka, as linhas de entrada por segundo devem acompanhar a taxa de ingestão de dados no front-end.

Dois trabalhos podem ter taxa de transferência de cluster semelhante, mas métricas de streaming muito diferentes. A captura de tela a seguir mostra duas cargas de trabalho diferentes. Eles são semelhantes em termos de taxa de transferência de cluster (trabalhos, estágios e tarefas por minuto). Mas a segunda execução processa 12.000 linhas/s contra 4.000 linhas/seg.

A taxa de transferência de streaming geralmente é uma métrica de negócios melhor do que a taxa de transferência de cluster, porque mede o número de registros de dados que são processados.

Consumo de recursos por executor

Essas métricas ajudam a entender o trabalho que cada executor executa.

As métricas percentuais medem quanto tempo um executor gasta em várias coisas, expresso como uma proporção de tempo gasto versus o tempo total de computação do executor. As métricas são:

• % Tempo de serialização
• % Tempo de desserialização
• % de tempo de execução da CPU
• % de tempo da JVM

Essas visualizações mostram o quanto cada uma dessas métricas contribui para o processamento geral do executor.

As métricas de embaralhamento são métricas relacionadas ao embaralhamento de dados entre os executores.

• E/S aleatórias
• Memória aleatória
• Utilização do sistema de ficheiros
• Utilização do disco

Gargalos comuns de desempenho

Dois gargalos de desempenho comuns no Spark são retardatários de tarefas e uma contagem de partições aleatórias não ideais.

Retardatários de tarefas

As fases de um trabalho são executadas sequencialmente, com as fases anteriores a bloquear as posteriores. Se uma tarefa executar uma partição de redistribuição mais lentamente do que outras tarefas, todas as tarefas no cluster têm de aguardar que a tarefa lenta seja atualizada antes de a fase poder terminar. Isso pode acontecer pelos seguintes motivos:

1. Um anfitrião ou grupo de anfitriões está lento. Sintomas: alta latência de tarefa, estágio ou trabalho e baixa taxa de transferência de cluster. A soma de latências de tarefas por host não será distribuída uniformemente. No entanto, o consumo de recursos será distribuído uniformemente entre os executores.

2. As tarefas têm uma agregação cara para executar (distorção de dados). Sintomas: alta latência de tarefa, alta latência de estágio, alta latência de trabalho ou baixa taxa de transferência de cluster, mas a soma de latências por host é distribuída uniformemente. O consumo de recursos será distribuído uniformemente entre os executores.

3. Se as partições forem de tamanho desigual, uma partição maior pode causar execução de tarefa desequilibrada (desvio de partição). Sintomas: O consumo de recursos do executor é alto em comparação com outros executores em execução no cluster. Todas as tarefas em execução nesse executor serão executadas lentamente e manterão a execução do estágio no pipeline. Diz-se que esses estágios são barreiras de palco.

Contagem de partições aleatórias não ideais

Durante uma consulta de streaming estruturada, a atribuição de uma tarefa a um executor é uma operação que consome muitos recursos para o cluster. Se os dados aleatórios não tiverem o tamanho ideal, a quantidade de atraso de uma tarefa afetará negativamente a taxa de transferência e a latência. Se houver poucas partições, os núcleos no cluster serão subutilizados, o que pode resultar em ineficiência de processamento. Por outro lado, se houver muitas partições, há uma grande sobrecarga de gerenciamento para um pequeno número de tarefas.

Use as métricas de consumo de recursos para solucionar problemas de distorção de partição e má alocação de executores no cluster. Se uma partição estiver enviesada, os recursos do executor serão elevados em comparação com outros executores em execução no cluster.

Por exemplo, o gráfico a seguir mostra que a memória usada pelo embaralhamento nos dois primeiros executores é 90X maior do que os outros executores:

Próximos passos

• Monitorando o Azure Databricks em um espaço de trabalho do Azure Log Analytics
• Caminho de aprendizagem: crie e opere soluções de aprendizado de máquina com o Azure Databricks
• Documentação do Azure Databricks
• Descrição geral do Azure Monitor

Recursos relacionados

• Monitorizar o Azure Databricks
• Send Azure Databricks application logs to Azure Monitor (Enviar registos de aplicações do Azure Databricks para o Azure Monitor)
• Use dashboards to visualize Azure Databricks metrics (Utilizar dashboards para visualizar as métricas do Azure Databricks)
• Arquitetura de análise moderna com o Azure Databricks
• Ingestão, ETL (extrair, transformar, carregar) e pipelines de processamento de fluxo com o Azure Databricks