Fase lenta do Spark com pouca entrada/saída

Se você tiver uma fase lenta sem muita entrada/saída, isso poderá ser causado por:

• Ler muitos arquivos pequenos
• Gravar muitos arquivos pequenos
• UDF(s) lenta(s)
• Ingresso cartesiano
• Ingresso em explosão

Quase todos esses problemas podem ser identificados usando o DAG do SQL.

Abrir o DAG do SQL

Para abrir o DAG do SQL, role até a parte superior da página do trabalho e clique na Consulta SQL Associada:

Agora você deve ver o DAG. Caso contrário, role um pouco e você deverá vê-lo:

Antes de seguir em frente, familiarize-se com o DAG e onde o tempo está sendo gasto. Alguns nós do DAG têm informações de tempo úteis e outros não. Por exemplo, esse bloco levou 2,1 minutos e ainda fornece a ID do estágio:

Esse nó exige que você o abra para ver que levou 1,4 minutos:

Esses tempos são cumulativos, portanto, é o tempo total gasto em todas as tarefas, não no tempo do relógio. Mas ainda é muito útil, pois eles estão correlacionados com o tempo de relógio e o custo.

É útil familiarizar-se com onde o tempo está sendo gasto no DAG.

Ler muitos arquivos pequenos

Se você notar que um dos seus operadores de digitalização está demorando muito, abra-o e verifique o número de arquivos lidos:

Se você estiver lendo dezenas de milhares de arquivos ou mais, poderá ter um pequeno problema de arquivo. Seus arquivos não devem ter menos de 8 MB. Geralmente, o pequeno problema do arquivo é causado pelo particionamento em muitas colunas ou em uma coluna de alta cardinalidade.

Se você tiver sorte, talvez só precise correr OPTIMIZE. Independentemente disso, você precisa reconsiderar seu layout do arquivo.

Gravar muitos arquivos pequenos

Se você vir que sua gravação está demorando muito, abra-a e verifique o número de arquivos e a quantidade de dados gravados.

Se você estiver escrevendo dezenas de milhares de arquivos ou mais, poderá ter um pequeno problema de arquivo. Seus arquivos não devem ter menos de 8 MB. Geralmente, o pequeno problema do arquivo é causado pelo particionamento em muitas colunas ou em uma coluna de alta cardinalidade. Você precisa reconsiderar seu layout do arquivo ou ativar gravações otimizadas.

UDFs lentas

Se você sabe que possui UDFs ou observa algo semelhante no seu DAG, pode estar sofrendo com a presença de UDFs lentas.

Se você acha que está sofrendo com esse problema, tente desativar sua UDF para ver como ela afeta a velocidade do pipeline. Se a UDF for realmente onde o tempo está sendo gasto, sua opção mais segura é reescrever a UDF usando funções nativas. Se isso não for possível, considere o número de tarefas na fase de execução do UDF. Se for menor que o número de núcleos em seu cluster, repartition() seu dataframe antes de usar a UDF:

  (df
    .repartition(num_cores)
    .withColumn('new_col', udf(...))
  )

UDFs também podem sofrer de problemas de memória. Considere que cada tarefa pode ter que carregar todos os dados em sua partição na memória. Se esses dados forem muito grandes, as coisas poderão ficar muito lentas ou instáveis. A repartição também pode resolver esse problema, tornando cada tarefa menor.

Ingresso cartesiano

Se você vir uma junção cartesiana ou uma junção de loop aninhado na sua DAG, você deve saber que essas junções são muito caras. Certifique-se de que é isso que você pretendia e ver se há outra maneira.

Junção expansiva ou Explodir

Se você vir poucas linhas entrando em um nó e muitas outras saindo, pode estar sofrendo de um ingresso explosivo ou explosão

Leia mais sobre explosões na Guia de Otimização do Databricks.