Otimize aplicativos Apache Spark no HDInsight

Este artigo fornece uma visão geral das estratégias para otimizar aplicativos Apache Spark no Azure HDInsight.

Descrição geral

Você pode enfrentar os seguintes cenários comuns

A mesma tarefa Spark está mais lenta do que antes no mesmo cluster HDInsight
O trabalho Spark é mais lento no cluster HDInsight do que localmente ou em outro fornecedor de serviços terceirizado.
A tarefa Spark é mais lenta num cluster HDI do que noutro cluster HDI

O desempenho de seus trabalhos do Apache Spark depende de vários fatores. Esses fatores de desempenho incluem:

Como os seus dados são armazenados
Como o cluster é configurado
As operações que são usadas ao processar os dados.
Serviço de fios insalubres
Restrições de memória devido a executores de tamanho inadequado e OutOfMemoryError
Demasiadas tarefas ou poucas tarefas
A distorção de dados causou algumas tarefas pesadas ou tarefas lentas
Tarefas mais lentas em nós defeituosos

Verifique se o ResourceManager ou o NodeManager alerta
Verifique o status do ResourceManager e do NodeManager no YARN > RESUMO: Todo o NodeManager deve estar em Iniciado e apenas o Ative ResourceManager deve estar em Iniciado

Verifique se a interface do usuário do Yarn está acessível através de https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster
Verifique se há exceções ou erros no login do ResourceManager /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Veja mais informações em Problemas Comuns do Yarn

Vá para Ambari UI > YARN > SUMMARY, verifique CLUSTER MEMORY em ServiceMetrics
Verifique as métricas da fila de fios em detalhes:

Vá para a interface do Yarn, veja as métricas do agendador do Yarn através de https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
Como alternativa, você pode verificar as métricas do agendador de fios por meio da API Yarn Rest. Por exemplo, curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". Para ESP, você deve usar o usuário administrador de domínio.

Todos os recursos de executores: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Veja mais informações em configuração de executores de faísca
ApplicationMaster
- No modo de cluster, use spark.driver.memory e spark.driver.cores
- No modo cliente, use spark.yarn.am.memory+spark.yarn.am.memoryOverhead e spark.yarn.am.cores

Nota

yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb

Compare os recursos totais da sua nova aplicação com os recursos disponíveis do Yarn na sua fila especificada.

Precisamos identificar os sintomas abaixo por meio da interface do usuário do Spark ou do Spark History:

Qual fase é lenta
São v-cores de CPU dos executores totalmente utilizados na Linha do Tempo de Eventos na guia Stage
Se estiver a usar o SQL do Apache Spark, qual é o plano físico na aba SQL?
O DAG é demasiado longo numa fase?
Observe as métricas das tarefas (tamanho de entrada, tamanho de gravação aleatória, tempo de GC) na guia Palco

Há muitas otimizações que podem ajudá-lo a superar esses desafios, como o armazenamento em cache e permitir a distorção de dados.

Em cada um dos artigos a seguir, você pode encontrar informações sobre diferentes aspetos da otimização do Spark.

spark.sql.shuffle.partitions é 200 por padrão. Podemos ajustar com base nas necessidades empresariais ao embaralhar dados para uniões ou agregações.
spark.sql.files.maxPartitionBytes é 1G por padrão no IDH. O número máximo de bytes para empacotar em uma única partição ao ler arquivos. Essa configuração só é eficaz ao usar fontes baseadas em arquivos, como Parquet, JSON e ORC.
AQE no Spark 3.0. Consulte Execução adaptável de consultas

Esta página foi útil?