Otimizar aplicativos Apache Spark no HDInsight

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

Visão geral

Você pode enfrentar os cenários comuns abaixo

O mesmo trabalho do Spark é mais lento do que antes no mesmo cluster HDInsight
O trabalho do Spark é mais lento no cluster HDInsight do que no local ou em outro provedor de serviços de terceiros
O trabalho do Spark é mais lento em um cluster HDI do que em outro cluster HDI

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

Como os dados são armazenados
Como o cluster é configurado
As operações usadas ao processar os dados.
Serviço yarn não íntegro
Restrições de memória devido a executores de tamanho inadequado e OutOfMemoryError
Muitas tarefas ou poucas tarefas
A distorção de dados causou algumas tarefas pesadas ou tarefas lentas
Tarefas mais lentas em nós inválidos

Verificar alertas ResourceManager ou NodeManager
Verificar o status de ResourceManager e NodeManager no YARN > RESUMO: todos os NodeManager devem estar em Started e somente o Active ResourceManager deve estar em Started

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

Veja mais informações em Problemas comuns do Yarn

Vá para Interface do usuário do Ambari > YARN > SUMMARY, verifique CLUSTER MEMORY em ServiceMetrics
Verifique as métricas de fila do yarn em detalhes:

Acesse a interface do usuário do Yarn e verifique as métricas do agendador do Yarn https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
Como alternativa, você pode verificar as métricas do agendador do Yarn por meio da API Rest do Yarn. 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 na configuração de executores do Spark
ApplicationMaster
- No modo 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

Observação

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

Compare o total de recursos do novo aplicativo com os recursos disponíveis do Yarn na fila especificada

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

Qual estágio está lento
Os v-cores totais da CPU do executor são totalmente utilizados em Event-Timeline na guia Estágio
Se estiver usando spark sql, qual é o plano físico na guia SQL
O DAG é muito longo em um estágio
Observe as métricas de tarefas (tamanho da entrada, tamanho da gravação embaralhada, Tempo em GC) na guia Estágio

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

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

spark.sql.shuffle.paritions é 200 por padrão. Podemos ajustar com base nas necessidades de negócios embaralhando dados para junções ou agregações.
spark.sql.files.maxPartitionBytes é 1G por padrão no HDI. O número máximo de bytes a serem empacotados em uma única partição ao ler arquivos. Essa configuração só é efetiva ao usar fontes baseadas em arquivo, como Parquet, JSON e ORC.
AQE no Spark 3.0. Consulte Execução de consulta adaptável