Entrevistas de data engineering dependem muito de SQL e de saber se seus pipelines sobrevivem a rodar duas vezes, atrasados, ou fora de ordem. Espere perguntas de modelagem sem uma única resposta certa. Abaixo estão as perguntas mais frequentes, cada uma com uma resposta modelo. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
1
Qual é a diferença entre formatos orientados a linha e colunares?
Resposta
Formatos de linha como CSV ou Avro armazenam um registro inteiro junto, o que é bom para escrever e ler registros completos. Formatos colunares como Parquet e ORC armazenam cada coluna junta, então uma consulta que toca três de cinquenta colunas lê só essas três. Colunar também comprime muito melhor, porque uma coluna tem valores parecidos entre si. O trade-off é que escrever uma única linha é caro, por isso colunar é para analytics, e não para transações.
2
O que significa um batch job ser idempotente, e como você faz um de insert?
Resposta
Idempotente significa que rodá-lo duas vezes deixa o mesmo resultado de rodar uma vez só — o que importa porque retries acontecem, seja de um scheduler, uma falha ou uma pessoa. Para um insert, as respostas usuais são um merge ou upsert numa chave de negócio, apagar a partição de destino antes de escrever nela, ou uma constraint única que faz o duplicado falhar de forma inofensiva. Um INSERT simples num job reexecutado duplica os dados silenciosamente.
3
Qual é a diferença entre um star schema e um snowflake schema?
Resposta
Num star, as dimensões estão desnormalizadas em tabelas únicas ligadas diretamente ao fato. Num snowflake, as dimensões estão normalizadas em tabelas adicionais. O star precisa de menos joins e é mais rápido de consultar; o snowflake economiza storage e evita anomalias de atualização. Analytics geralmente escolhe o star, porque storage é barato e o tempo do analista não é.
4
O que é lazy evaluation no Spark, e qual é a diferença entre uma transformação e uma ação?
Resposta
Transformações — map, filter, join — constroem um plano e não executam nada. Uma ação — count, collect, write — dispara o plano inteiro. A laziness permite que o otimizador veja a cadeia toda e a reorganize, empurrando filtros para baixo e colapsando etapas. A consequência prática é que cronometrar uma transformação não mede nada, e o erro que você esperava na linha três aparece só na ação.
5
Qual é a diferença entre uma dependência ampla e uma estreita, e por que isso importa?
Resposta
Numa dependência estreita, cada partição de entrada alimenta uma partição de saída — um map ou filter, computável no nó que já tem os dados. Uma dependência ampla exige dados de várias partições, o que significa um shuffle pela rede. Shuffles dominam o runtime da maioria dos jobs, então um groupBy ou um join é o primeiro lugar onde você olha quando algo está lento.
6
Quando você usaria um broadcast join?
Resposta
Quando um dos lados é pequeno o bastante para caber na memória de cada executor — uma tabela de dimensão contra uma tabela fato grande. Fazer broadcast dela elimina o shuffle por completo, o que geralmente é a diferença entre minutos e horas. O limite é a memória: faça broadcast de algo grande demais e cada executor paga o preço, então o limiar é uma configuração que vale a pena conhecer em vez de chutar.
7
O que é Change Data Capture e quando você usa isso em vez de uma recarga completa?
Resposta
CDC lê o próprio log de mudanças do banco de dados de origem e transmite inserts, updates e deletes em vez de reler a tabela inteira. Você usa isso quando a tabela é grande demais para uma recarga completa caber na janela disponível, ou quando você precisa das mudanças em si — deletes, em particular, que uma comparação de snapshot completo só detecta pela ausência.