Estágio lento do Spark com pouca E/S

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

• Lendo muitos arquivos pequenos
• Escrevendo 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 SQL DAG, role para cima até a parte superior da página do trabal ho e clique em Associated SQL Query (Consulta associada ):

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

Antes de prosseguir, familiarize-se com o DAG e com 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 até fornece o ID do estágio:

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

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

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

Lendo muitos arquivos pequenos

Se você perceber que um de seus operadores de escaneamento está demorando muito, abra-o e procure o número de arquivos lidos:

Se você estiver lendo dezenas de milhares de arquivos ou mais, talvez tenha um pequeno problema com o arquivo. Seus arquivos não devem ter menos de 8 MB. O problema de arquivos pequenos geralmente é causado pelo particionamento em muitas colunas ou em 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.

Escrevendo muitos arquivos pequenos

Se você perceber 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, você pode ter um pequeno problema de arquivo. Seus arquivos não devem ter menos de 8 MB. O problema de arquivos pequenos geralmente é causado pelo particionamento em muitas colunas ou em uma coluna de alta cardinalidade. O senhor precisa reconsiderar a disposição dos arquivos ou ativar as gravações otimizadas.

UDFs lentos

Se você sabe que tem UDFs ou vê algo parecido em seu DAG, talvez esteja sofrendo com UDFs lentos:

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 clustering, repartition() seu dataframe antes de usar o UDF:

Python

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

Os UDFs também podem sofrer 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.

Cartesiano join

Se o senhor vir um join cartesiano ou um loop aninhado join no seu DAG, saiba que essas junções são muito caras. Verifique se é isso que você pretendia 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():

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