Estágio lento do Spark com pouca E/S

Se o senhor tiver um estágio lento com pouca E/S, isso pode ser causado por:

  • Leitura de muitos arquivos pequenos

  • Gravação de muitos arquivos pequenos

  • UDF(s) lento(s)

  • Cartesiano join

  • Explosão join

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

Abra o SQL DAG

Para abrir o DAG SQL, role a tela até a parte superior da pági na Job e clique em Associated SQL Query (Consulta associada):

ID DO SQL

Agora o senhor deve ver o DAG. Caso contrário, role a tela um pouco e o senhor a verá:

SLQ DAG

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

Nó de estágio lento

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

Nó de gravação lenta

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

É útil familiarizar-se com o local do DAG em que o tempo está sendo gasto.

Leitura de muitos arquivos pequenos

Se o senhor perceber que um dos operadores de varredura está demorando muito, abra-o e verifique o número de arquivos lidos:

Leitura de muitos arquivos

Se o senhor estiver lendo dezenas de milhares de arquivos ou mais, pode ter um problema de arquivo pequeno. Seus arquivos não devem ter menos de 8 MB. O problema do arquivo pequeno geralmente é causado pelo particionamento de muitas colunas ou de uma coluna de alta cardinalidade.

Se o senhor tiver sorte, talvez precise apenas executar OPTIMIZE. Independentemente disso, o senhor precisa reconsiderar a disposição do seu arquivo.

Gravação de muitos arquivos pequenos

Se o senhor perceber que a gravação está demorando muito, abra-a e verifique o número de arquivos e a quantidade de dados gravados:

Gravação de muitos arquivos

Se o senhor estiver gravando dezenas de milhares de arquivos ou mais, é possível que tenha um problema de arquivos pequenos. Seus arquivos não devem ter menos de 8 MB. O problema do arquivo pequeno geralmente é causado pelo particionamento de muitas colunas ou de uma coluna de alta cardinalidade. O senhor precisa reconsiderar a disposição dos arquivos ou ativar as gravações otimizadas.

UDFs lentos

Se o senhor sabe que tem UDFs ou vê algo assim no seu DAG, pode estar sofrendo com UDFs lentos:

Nó UDF

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

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

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

União cartesiana

Se o senhor vir um join cartesiano ou um loop aninhado join em seu DAG, saiba que essas junções são muito caras. Certifique-se de que é essa a intenção do senhor e veja se há outra maneira.

Exploding join ou explode

Se o senhor observar algumas linhas entrando em um nó e muito mais saindo, pode estar sofrendo de uma explosão join ou explode():

Explosão join

Leia mais sobre explosões no guia de otimização do Databricks.