Estágio lento do Spark com pouca E/S

Se você tiver um estágio lento sem muita E/S, 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 em Consulta SQL Associada:

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

Antes de prosseguir, familiarize-se com o DAG e onde o tempo está sendo gasto. Alguns nós no 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ó requer que você o abra para ver que demorou 1,4 minutos:

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

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

Ler muitos arquivos pequenos

Se você vir que um dos seus operadores de verificação está demorando muito, abra-o e procure 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 tiver sorte, talvez você precise executar apenas 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 procure o número de arquivos e a quantidade de dados gravados:

Se você estiver gravando 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ê souber que você tem UDFs, ou ver algo assim no seu DAG, poderá estar sofrendo de UDFs lentas:

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

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

As UDFs também podem sofrer de problemas de memória. Considere que cada tarefa pode ter que carregar todos os dados na 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. Verifique se é isso que você pretendia e veja se há outra maneira.

Ingresso explosivo ou explosão

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.