Spark

Folha de revisão · 2 temas · Engenharia de Dados

Feita para a véspera. Imprimir esta página tira o menu e as abas.

Spark: introdução

Spark é o motor por trás de quase todo pipeline moderno, incluindo o Databricks que o banco usa. A banca não quer a definição de marketing: quer que você descreva o que cada processo faz e o que acontece de verdade entre a linha de código e o resultado.

Como cai: O que acontece quando você chama .count()?

Erros comuns

Dizer que Spark é rápido porque 'roda em memória', sem explicar o quê. O ganho é não gravar o resultado intermediário de cada etapa em disco, como o MapReduce fazia entre map e reduce.
Achar que Spark carrega a base inteira na RAM. Ele processa por partição e derrama para disco quando não cabe; memória é otimização, não requisito.
Confundir driver com nó mestre do cluster. O driver é o processo da sua aplicação, que monta o plano e agenda tasks; o cluster manager é quem aloca recursos, e pode ser YARN, Kubernetes ou o standalone.
Não saber dizer o que uma transformação faz. Transformação não executa nada: ela acrescenta um nó ao plano. Só a ação dispara execução.
Trazer resultado para o driver sem pensar. collect() puxa todas as partições para a memória de um único processo, e é assim que se derruba o driver com uma tabela de bilhões de linhas.
Não relacionar shuffle com stage. A fronteira de stage é definida pelo shuffle: enquanto os dados não precisam ser redistribuídos entre executores, tudo cabe no mesmo stage.

Vocabulário

transformação: — Operação que devolve outro conjunto distribuído e apenas acrescenta um nó ao plano: filter, select, join, groupBy.
ação: — Operação que devolve um valor ao driver ou escreve num destino, e por isso dispara a execução: count, collect, show, write.
shuffle: — Redistribuição de dados entre executores, necessária quando a mesma chave precisa terminar no mesmo lugar.

Spark: RDD, transformações e ações

A ementa oficial ainda apresenta o Spark pela API de RDD, então a pergunta vem nesse vocabulário. Quem só decora a definição de 2014 tropeça na pergunta seguinte, que é por que hoje ninguém escreve RDD. Dominar os dois lados é o que mostra atualização.

Como cai: Quando você ainda usaria RDD em vez de DataFrame?

Erros comuns

Dizer que RDD é o mesmo que DataFrame com outro nome. DataFrame tem esquema e passa pelo otimizador Catalyst; RDD é opaco para o otimizador, que não sabe o que a sua função faz.
Achar que RDD é mutável. Toda transformação cria um novo RDD; a imutabilidade é o que torna a recomputação por lineage possível.
Confundir narrow com barato e wide com caro sem saber por quê. A diferença é a dependência: em narrow cada partição de saída depende de uma partição de entrada; em wide depende de várias, e por isso o dado precisa atravessar a rede.
Classificar reduceByKey como narrow porque 'reduz'. Toda operação por chave que precisa juntar chaves iguais é wide.
Achar que tolerância a falhas em Spark é replicação. É recomputação: com o lineage e a origem, o Spark refaz só as partições perdidas.
Recomendar RDD hoje sem justificativa. A resposta esperada é DataFrame e Spark SQL por padrão, com RDD reservado a controle fino e dado sem esquema.

Vocabulário

dependência narrow: — Cada partição de saída depende de no máximo uma partição de entrada.
dependência wide: — Uma partição de saída depende de várias partições de entrada, porque a mesma chave precisa se reunir num lugar só.