Estágio Slow Spark com pouca E/S

Se você tem um estágio lento com pouca E/S, isso pode ser causado por:

• Ler muitos ficheiros pequenos
• Escrever muitos ficheiros pequenos
• UDF(s) lento(s)
• Junção cartesiana
• Adesão explosiva

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

Abra o SQL DAG

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

Agora você deve ver o DAG. Se não, role um pouco e você deve vê-lo:

Antes de seguir em frente, 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, este bloco demorou 2,1 minutos e até fornece o ID do palco:

Este nó requer que você o abra para ver que levou 1,4 minutos:

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

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

Ler muitos ficheiros pequenos

Se vir que um dos seus operadores de análise está a demorar muito tempo, abra-o e procure o número de ficheiros que lê:

Se você estiver lendo dezenas de milhares de arquivos ou mais, você pode ter um pequeno problema de arquivo. Os seus ficheiros não devem ter menos de 8MB. O problema do arquivo pequeno é mais frequentemente causado pelo particionamento em muitas colunas ou uma coluna de alta cardinalidade.

Se tiver sorte, talvez só precise executar o OTIMIZE. Independentemente disso, você precisa reconsiderar o layout do arquivo.

Escrever muitos ficheiros pequenos

Se vir que a sua escrita está a demorar muito tempo, abra-a e procure o número de ficheiros e a quantidade de dados que foram gravados:

Se estiver a escrever dezenas de milhares de ficheiros ou mais, poderá ter um pequeno problema com ficheiros. Os seus ficheiros não devem ter menos de 8MB. O problema do arquivo pequeno é mais frequentemente causado pelo particionamento em muitas colunas ou uma coluna de alta cardinalidade. Você precisa reconsiderar o layout do arquivo ou ativar gravações otimizadas.

UDFs lentas

Se você sabe que tem UDFs, ou vê algo assim em seu DAG, você pode estar sofrendo de UDFs lentos:

Se você acha que está sofrendo com esse problema, tente comentar seu UDF para ver como ele afeta a velocidade do seu pipeline. Se o UDF é realmente onde o tempo está sendo gasto, sua melhor aposta é reescrever o UDF usando funções nativas. Se isso não for possível, considere o número de tarefas no estágio que executa seu UDF. Se for menor que o número de núcleos no cluster, repartition() o dataframe antes de usar o 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 podem ficar muito lentas ou instáveis. A repartição também pode resolver esse problema, tornando cada tarefa menor.

Junção cartesiana

Se você vir uma junção cartesiana ou uma junção de loop aninhada em seu DAG, saiba que essas junções são muito caras. Certifique-se de que é isso que você pretendia e veja se há outra maneira.

Explosão ou explosão

Se você vir algumas linhas entrando em um nó e magnitudes mais saindo, você pode estar sofrendo de uma junção explodindo ou explodindo():

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