Explique narrow e wide, e o que isso tem a ver com o desempenho de um job que agrega gasto por cartão.

Narrow é quando cada partição de saída depende de no máximo uma partição de entrada: map, filter, flatMap. Dá para executar tudo dentro do executor, encadeando as operações sem tráfego de rede, e por isso o Spark junta essas etapas num mesmo stage. Wide é quando uma partição de saída depende de várias de entrada, porque registros com a mesma chave precisam se encontrar. Aí é shuffle: serializa, grava em disco local, transfere pela rede e relê. No job de gasto por cartão, o filtro de período e o cálculo de valor são narrow e saem de graça no mesmo stage. O agrupamento por cartão é wide e é ele que corta o job em dois stages e domina o tempo. O que eu faço para melhorar: filtrar o máximo possível antes do agrupamento, usar reduceByKey em vez de groupByKey para agregar antes de trafegar, e checar na Spark UI se há chave concentrada criando uma task muito mais longa que as outras.

Spark

Spark · tema 10 de 30

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

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

Por padrão eu não usaria: escrevo DataFrame ou Spark SQL, porque aí o Catalyst enxerga o esquema e a semântica da operação e consegue empurrar filtro para a leitura, podar coluna e escolher a estratégia de join. Com RDD, o otimizador não sabe o que a minha função faz e executa exatamente o que eu mandei. Ainda assim eu desço para RDD em três situações. Primeira, quando preciso de controle fino sobre partição, por exemplo aplicar uma lógica que trata a partição inteira como unidade ou implementar um particionador próprio. Segunda, quando o dado não tem esquema nenhum: arquivo binário, texto livre de contrato digitalizado, formato proprietário que eu preciso parsear antes de conseguir estruturar. Terceira, código legado que já está em RDD, funciona e não justifica reescrita. Fora isso, descer para RDD é abrir mão de otimização de graça, e é assim que se explica isso numa revisão de código.

35 min · 2 vídeos · 13 cards · 1 drill

Por que cai

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.

Pré-teste · 1 de 2

responda antes de ver

O que significa dizer que um RDD é imutável?

Confiança:

Vídeo · português · 25 min

Trabalha o RDD com exercícios, que é o formato que fixa transformação contra ação. Faça os exercícios em vez de assistir passivamente: você precisa conseguir classificar operações sem pensar.

Em uma frase

RDD é uma coleção distribuída, imutável e particionada de registros, capaz de se reconstruir sozinha depois de uma falha — e é a abstração de baixo nível sobre a qual o Spark inteiro foi construído.

As quatro propriedades

1Distribuído: os registros estão espalhados pelas máquinas do cluster.
2Imutável: nenhuma transformação altera o RDD existente; cada uma cria outro.
3Particionado: a partição é a unidade de paralelismo, e vira uma task.
4Resiliente: perdeu uma partição, o Spark recomputa só ela a partir do lineage.

A imutabilidade não é purismo funcional. É o que torna a recomputação segura: como nada muda depois de criado, refazer uma partição produz exatamente o mesmo resultado.

Transformações e ações

Tipo	Devolve	Executa?	Exemplos
Transformação	Outro RDD	Não: acrescenta ao plano	map, filter, flatMap, reduceByKey, join
Ação	Valor ao driver ou escrita no destino	Sim: dispara o job	count, collect, take, reduce, saveAsTextFile

Você encadeia transformações à vontade e nada acontece. A ação é o gatilho.

Narrow e wide

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ó.

map, filter, flatMap e union são narrow: cada executor resolve o que tem em mãos e o Spark encadeia essas etapas dentro do mesmo stage, sem tráfego de rede.

groupByKey, reduceByKey, join, distinct e repartition são wide. Para somar o gasto de um cartão, todas as transações daquele cartão precisam terminar na mesma partição, e não há como saber onde elas estão sem redistribuir. Isso é o shuffle: serializar, gravar em disco local, transferir pela rede, reler.

Lineage e tolerância a falhas

O Spark guarda como cada RDD foi derivado do anterior. Esse registro é o lineage, e ele funciona como uma receita de reconstrução.

Quando um executor cai, o Spark não recorre a réplica: ele recomputa. Olha o lineage, identifica quais partições se perderam, e reexecuta apenas as tasks daquelas partições em outro executor. Se o shuffle anterior ainda existir em disco, ele parte de lá; senão, refaz desde a leitura.

RDD é API legada

Essa é a parte que o material de curso costuma não dizer. O RDD é a API original, de 2014, e continua sendo a base de execução do Spark — mas não é mais a API que se escreve. Hoje o padrão é DataFrame e Spark SQL.

O motivo é o Catalyst, o otimizador. Ele só consegue trabalhar se conhecer o esquema e a semântica da operação: aí empurra filtro para a leitura do arquivo, descarta colunas que ninguém pediu, reordena joins e escolhe a estratégia física. Com RDD, o conteúdo da sua função é opaco: o Spark executa literalmente o que você mandou, na ordem em que você mandou.

Quando RDD ainda cabe

Três situações defensáveis: controle fino sobre particionamento ou sobre a partição como unidade de processamento; dado sem esquema, como binário ou texto livre que você precisa parsear antes de estruturar; e código legado que já roda bem e não justifica reescrita.

Fora isso, descer para RDD é abrir mão de otimização de graça.

Se quiser outro ângulo

Vai direto no ponto que a banca cobra. Assista depois do primeiro e tente enunciar a regra com suas palavras antes que o vídeo enuncie.

Como cai na sabatina

“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.

Flashcards

Card 1 de 13

0 certos · 0 a rever

Drill

Narrow ou wide?

Classifique cada operação pela dependência entre partições. Se for wide, diga em voz alta por que a mesma chave precisa se encontrar.

1.map
2.filter
3.groupByKey
4.reduceByKey
5.flatMap
6.join entre dois RDDs por chave
7.union
8.distinct
9.repartition

Quiz · 1 de 2

Como o Spark recupera uma partição perdida quando um executor cai?

Explique para um gerente

Explique para um colega de outra área o que significa dizer que um conjunto de dados é imutável e mesmo assim sobrevive à queda de uma máquina.

Responda em voz alta antes de seguir. Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.

Perguntas de sabatina deste tema

· Quando você ainda usaria RDD em vez de DataFrame?
· Explique narrow e wide, e o que isso tem a ver com o desempenho de um job que agrega gasto por cartão.

Responder no simulado

Para ir além

PróximoAs zonas de um Data Lake