Perguntas de entrevista Data Engineer

Qual é a diferença entre ETL e ELT, e por que o ELT ganhou?

O ETL transforma os dados antes de carregá-los no warehouse, o que fazia sentido quando storage e computação do warehouse eram caros e rígidos. O ELT carrega os dados crus primeiro e transforma dentro do warehouse usando o próprio motor dele. O ELT ganhou para analytics porque os warehouses de nuvem tornaram a computação elástica e a separaram do storage, então manter os dados crus permite reconstruir modelos quando os requisitos mudam, em vez de reingerir dos sistemas de origem que você já não controla.

O que é um star schema e quando você não usaria um?

Um star schema tem uma tabela fato central de eventos com medidas numéricas, cercada por tabelas de dimensão desnormalizadas descrevendo o contexto. Ele é otimizado para consultas analíticas: poucos joins, agregação previsível, fácil para ferramentas de BI. Você evitaria isso num caso de uso puramente de event-streaming, em data science genuinamente exploratório sobre eventos crus, ou quando o warehouse é colunar o bastante para que uma tabela larga desnormalizada renda mais e custe menos manutenção.

Explique as slowly changing dimensions, em especial Type 2.

Uma SCD lida com atributos que mudam com o tempo, como um cliente que muda de cidade. Type 1 sobrescreve o valor antigo, perdendo o histórico. Type 2 insere uma linha nova com datas de validade e uma flag de atual, então um fato ligado pela surrogate key reflete o atributo como ele era no momento do evento. É isso que permite responder "quais foram as vendas por região no ano passado" corretamente, em vez de atribuir vendas antigas à nova região do cliente.

O que são window functions e onde elas superam um GROUP BY?

Uma window function calcula sobre um conjunto de linhas relacionadas à linha atual sem colapsá-las, então você mantém o detalhe no nível da linha junto com o agregado. Isso faz delas a ferramenta certa para totais acumulados, ranking dentro de uma partição, comparar uma linha com a média do grupo, e comparações lag/lead entre eventos consecutivos. Um GROUP BY forçaria você a agregar e depois juntar de volta ao detalhe — mais código, mais shuffling, e mais fácil de errar.

O que significa um pipeline ser idempotente, e por que isso importa?

Idempotente significa que rodar a mesma tarefa para o mesmo período duas vezes produz o mesmo resultado em vez de duplicar dados. Isso importa porque retries são inevitáveis — uma tarefa falha na metade, alguém roda ontem de novo, um backfill se sobrepõe a uma execução agendada. As implementações usuais são apagar e reescrever a partição de destino, ou um merge chaveado numa chave de negócio em vez de um insert cego. Pipelines que só funcionam se rodarem exatamente uma vez quebram na primeira vez que forem reexecutados.

Como você desenha um DAG do Airflow que seja seguro para backfill?

Cada tarefa deveria ser parametrizada pela data de execução lógica em vez de "agora", assim uma execução para uma data antiga lê e escreve os dados daquela data. As tarefas devem ser idempotentes, então uma reexecução sobrescreve sua própria partição. Configure retries sensatos com backoff, e use max_active_runs e pools para que um backfill de dois anos não sature o warehouse e sufoque as execuções de produção. Dependências entre DAGs são mais seguras expressas como checagens de disponibilidade de dados do que como horários chutados.

O que é um shuffle no Spark e por que ele é caro?

Uma transformação estreita como map ou filter funciona dentro de uma partição, então não precisa mover dados. Uma transformação ampla como groupBy, join ou repartition exige que linhas com a mesma chave acabem no mesmo executor, o que significa escrever dados intermediários em disco e movê-los pela rede — isso é um shuffle. Ele domina o runtime do job, então o tuning significa reduzir shuffles: fazer broadcast do lado pequeno de um join, filtrar antes de fazer join, e escolher um particionamento que combine com como você consulta.

O que é data skew e como você lida com isso?

Skew é quando uma chave tem uma fatia desproporcional das linhas, então uma única tarefa processa a maior parte dos dados enquanto o resto do cluster fica ocioso — o job parece 99% pronto por uma hora inteira. Você percebe isso na Spark UI como uma tarefa com input muito maior que as demais. Os remédios incluem "salgar" a chave quente para espalhá-la entre partições, fazer broadcast da tabela menor para evitar o shuffle join por completo, e tratar chaves quentes conhecidas separadamente da cauda longa.

Por que Parquet em vez de CSV ou JSON, e o que o particionamento acrescenta?

Parquet é colunar e comprimido, então uma consulta que lê três de quarenta colunas lê só essas colunas, e ele carrega um schema e estatísticas por coluna que deixam os motores pularem row groups inteiros. CSV e JSON forçam uma varredura completa e um reparse toda vez. Particionar por uma coluna que você filtra, geralmente data, permite ao motor pular diretórios inteiros, mas particionar demais cria milhões de arquivos pequenos, e o overhead de metadata passa a custar mais do que economiza.

O que o processamento exactly-once realmente significa em streaming?

A entrega exactly-once verdadeira não é alcançável de ponta a ponta; o que os sistemas entregam é processamento effectively-once, o que significa que duplicatas podem ser entregues, mas o resultado observável é como se cada mensagem contasse uma vez. Isso é alcançado com escritas idempotentes, deduplicação por uma chave de mensagem, ou sinks transacionais que confirmam offsets e saída atomicamente. Afirmar exactly-once sem dizer qual mecanismo garante isso é uma bandeira vermelha comum em entrevistas.

Como você lida com dados que chegam atrasados?

Primeiro decida a semântica: o registro é atribuído ao momento em que o evento aconteceu ou ao momento em que você o recebeu? Event time geralmente é o correto para analytics, mas exige que o pipeline reabra e reescreva uma partição já publicada. Watermarks definem quanto tempo você espera antes de tratar uma janela como fechada, e qualquer coisa mais atrasada vai para um caminho de correção ou uma tabela dedicada de chegadas tardias. O erro de design é descartar dados atrasados silenciosamente, porque os números então divergem da fonte e ninguém sabe por quê.

Como você testa qualidade de dados, e o que você verifica?

Os testes rodam como etapas do pipeline que falham de forma barulhenta, em vez de dashboards que ninguém lê. As checagens padrão são frescor, volume de contagem de linhas contra expectativas, unicidade de chaves, not-null em colunas obrigatórias, integridade referencial entre fato e dimensão, e faixas ou enumerações aceitas. Ferramentas como dbt tests ou Great Expectations formalizam isso. A decisão de design importante é quais falhas bloqueiam tarefas downstream e quais só alertam, porque bloquear em cada anomalia ensina as pessoas a ignorar alertas.