Além da ementa

SQL para engenharia de dados

SQL é o único tema em que a banca pode pedir para você escrever ou descrever a consulta na hora. É teste de fluência: quem hesita entre ROW_NUMBER e GROUP BY entrega que usa SQL só para conferir resultado, não para transformar dado.

Como cai: Como você pegaria a última transação de cada conta?

Erros comuns

• ×Usar NOT IN com subconsulta que pode retornar NULL. Um único NULL faz a condição virar desconhecida e o resultado volta vazio. NOT EXISTS não tem esse problema.
• ×Achar que GROUP BY resolve 'a última transação de cada conta'. GROUP BY colapsa a linha e você perde as outras colunas; o certo é ROW_NUMBER particionado pela conta.
• ×Filtrar window function no WHERE. A janela é avaliada depois do WHERE; ou você envolve numa CTE e filtra fora, ou usa QUALIFY onde o motor suporta.
• ×Confundir RANK com DENSE_RANK e com ROW_NUMBER. Em empate, ROW_NUMBER desempata arbitrariamente, RANK pula posições e DENSE_RANK não pula.
• ×Pedir índice para tabela analítica em Parquet. Em Spark SQL e Athena não existe índice como no OLTP; o que ganha é particionamento, ordenação de arquivos e poda por estatística.
• ×Empilhar subquery aninhada onde uma CTE resolveria. Além de ilegível, dificulta reaproveitar o mesmo bloco e conversar sobre o plano com outra pessoa.

Vocabulário

window function

— Função que calcula um valor por linha olhando um conjunto de linhas relacionadas (a janela), sem colapsar o resultado como o GROUP BY faz.

Modelagem de dados

Modelagem é onde a banca vê se você pensa antes de escrever pipeline. Perguntar o grão de um fato é o teste mais rápido para saber se a pessoa já modelou de verdade ou só consumiu tabela pronta.

Como cai: Modele o fato de transações de cartão: qual é o grão?

Erros comuns

• ×Começar pela lista de colunas em vez do grão. Sem declarar o grão, você não consegue decidir o que é medida, o que é dimensão e nem validar duplicidade depois.
• ×Normalizar o modelo analítico até 3NF. Cada junção a mais custa leitura e shuffle; o modelo dimensional troca redundância controlada por velocidade e clareza.
• ×Chamar de star um modelo com dimensão em vários níveis. Se a dimensão está quebrada em subtabelas, é snowflake, e você precisa justificar a escolha.
• ×Usar SCD tipo 1 onde o negócio precisa de histórico. Sobrescrever o endereço do cliente reescreve o passado: a análise de risco por região do ano anterior muda sozinha.
• ×Ligar o fato à chave natural do cliente numa dimensão SCD tipo 2. A chave tem que ser a substituta da versão vigente na data do evento, senão o histórico não fecha.
• ×Adotar One Big Table por padrão. Ela é ótima para consulta e péssima para manter regra de negócio única; o custo aparece na terceira mudança de definição.

Vocabulário

grão

— A frase que define o que uma linha da tabela fato representa. "Uma linha por autorização de cartão" é um grão; "dados de cartão" não é.

Formatos de arquivo e formatos de tabela

É a pergunta que mede se você entende o que acontece no disco. Quem só sabe que 'Parquet é mais rápido' não explica predicate pushdown; quem confunde formato de arquivo com formato de tabela erra a resposta sobre Delta e Iceberg inteira.

Como cai: Por que Parquet é mais rápido que CSV para a mesma consulta?

Erros comuns

• ×Dizer que Parquet é rápido 'porque é comprimido'. A compressão ajuda, mas o ganho principal vem de ler só as colunas pedidas e pular blocos inteiros pela estatística.
• ×Tratar Delta, Iceberg e Hudi como formatos de arquivo. São formatos de tabela: uma camada de metadados sobre arquivos que continuam sendo Parquet na maioria dos casos.
• ×Usar Parquet para stream de eventos com schema que muda toda semana. Formato colunar precisa de lote para render; Avro é feito para o caminho de escrita contínua.
• ×Achar que time travel é backup. É leitura de versões anteriores enquanto os arquivos existirem; a retenção é configurada e o vacuum apaga o que passou dela.
• ×Ignorar o problema de arquivo pequeno. Milhares de arquivos minúsculos matam a performance de leitura, e é por isso que compaction existe nos três formatos de tabela.
• ×Escolher formato de tabela pelo hype. O critério real é o motor que você usa, o padrão do time e o tipo de escrita: upsert frequente, batch grande ou multiengine aberto.

Vocabulário

log de transações

— Registro ordenado das operações sobre a tabela — quais arquivos entram e quais saem — que define o estado da tabela em cada versão.

Spark avançado: DataFrame, tuning e streaming

É o tema em que a sabatina para de perguntar conceito e começa a perguntar diagnóstico. Quem sabe nomear shuffle, skew e broadcast e dizer como confirmaria cada hipótese na Spark UI mostra que já operou job em produção.

Como cai: Seu job passou de 10 para 40 minutos sem mudar o código. Por onde começa?

Erros comuns

• ×Culpar o cluster antes de olhar o plano e a Spark UI. Job que dobra de tempo sem mudança de código quase sempre mudou de dado: volume, distribuição de chave ou quantidade de arquivos.
• ×Usar repartition onde coalesce bastava. Repartition dispara shuffle completo; coalesce só junta partições existentes e é a escolha certa para reduzir número de arquivos de saída.
• ×Fazer cache de tudo. Cache ocupa memória do executor, pode empurrar dado para disco e piorar o job; só compensa quando o mesmo DataFrame é reutilizado várias vezes.
• ×Escrever UDF em Python por comodidade. A serialização entre JVM e Python custa caro e o Catalyst não enxerga dentro da função, então ele não otimiza nada ali.
• ×Achar que AQE resolve todo skew. AQE trata partições de shuffle desbalanceadas em alguns tipos de join, mas não conserta concentração extrema numa única chave nem skew antes do shuffle.
• ×Confundir broadcast join com broadcast variable. Broadcast join é a estratégia de enviar a tabela pequena inteira para cada executor; variável de broadcast é outro mecanismo, para dado auxiliar.
• ×Aumentar shuffle partitions sem olhar o tamanho da partição. Partição pequena demais vira sobrecarga de tarefa; grande demais vira spill em disco.

Vocabulário

Catalyst

— Otimizador de consultas do Spark: analisa a expressão, aplica regras de otimização lógica, gera planos físicos candidatos e escolhe um.

data skew

— Distribuição desigual das chaves, em que uma ou poucas concentram volume desproporcional e caem todas na mesma partição.

Orquestração de pipelines

Sabatina de engenharia de dados quase sempre entra em falha e reprocessamento, porque é lá que o candidato mostra se já operou pipeline em produção. Quem só sabe desenhar o fluxo feliz trava na primeira pergunta sobre retry duplicando lançamento.

Como cai: Seu pipeline diário falhou às 3h e rodou de novo às 6h. O que precisa ser verdade para isso não duplicar dados?

Erros comuns

• ×Colocar o processamento pesado dentro da task do Airflow. O orquestrador vira gargalo e ponto único de falha; o certo é ele disparar o job no Databricks ou no EMR e acompanhar o estado.
• ×Encadear pipelines por horário em vez de por sinal. Se o upstream atrasa 20 minutos, o downstream lê dado incompleto e ninguém percebe até o relatório sair errado.
• ×Escrever task não idempotente. Qualquer retry, backfill ou clique em rerun duplica dado, e retry é justamente o que o orquestrador faz sozinho de madrugada.
• ×Configurar retry infinito ou sem backoff. Se a origem caiu, martelar a cada 30 segundos derruba de vez e ainda esconde o incidente atrás de uma task que fica amarela para sempre.
• ×Tratar SLA como enfeite. Sem prazo declarado, o pipeline que travou às 2h só é descoberto às 9h pelo usuário do relatório, e aí o custo já é reputacional.
• ×Confundir data lógica da execução com a hora do relógio. Se a task usa current_date em vez da data da janela, o backfill de ontem grava tudo com a data de hoje.

Vocabulário

idempotência

— Rodar a mesma task sobre a mesma janela uma ou várias vezes deixa o destino no mesmo estado final.

Ingestão e CDC

Ingestão é a fronteira entre o mundo transacional e o analítico, e é onde o banco tem mais medo: consulta mal feita no core afeta cliente pagando cartão. A banca usa este tema para ver se você pensa no impacto sobre a origem, não só no destino.

Como cai: Como você replicaria a tabela de contas do core bancário para o lake sem pesar no core?

Erros comuns

• ×Fazer carga full de tabela grande todo dia por comodidade. Custa janela, custa leitura na origem e ainda assim não conta o que aconteceu entre as fotos.
• ×Usar data_atualizacao como marca d água sem tratar dado atrasado. Registro que chega depois com timestamp antigo fica para trás da marca e nunca é lido.
• ×Achar que consulta incremental por timestamp captura tudo. Ela não vê DELETE e perde atualizações intermediárias entre duas leituras.
• ×Confundir CDC com replicação de banco. CDC entrega um fluxo de eventos de mudança para quem quiser consumir; replicação mantém uma cópia idêntica e fecha a porta para transformação.
• ×Esperar ordenação global no Kafka. A ordem é garantida por partição, então a chave que você escolhe é o que define se os eventos da mesma conta chegam em ordem.
• ×Tratar entrega ao menos uma vez como se fosse exatamente uma vez. Sem idempotência ou chave de deduplicação no destino, uma reentrega vira lançamento duplicado.
• ×Aplicar o fluxo de CDC no destino com INSERT. Sem MERGE, update vira linha nova e delete simplesmente não existe no lake.

Vocabulário

watermark

— marca do ponto até onde você já leu — um timestamp ou um identificador crescente

Arquiteturas de dados

Arquitetura é onde a banca mede senioridade. Qualquer pessoa lista nomes; o que separa é dizer o que cada escolha custa e em que condição você mudaria de ideia. A pergunta sobre fonte da verdade é a que mais expõe quem nunca conciliou número com área de negócio.

Como cai: O saldo no core diverge do saldo no relatório. Qual é a fonte da verdade?

Erros comuns

• ×Descrever Lambda e Kappa como opções equivalentes. Lambda cobra caro em manter a mesma regra escrita duas vezes; Kappa cobra em reprocessamento de histórico pelo próprio stream. Sem citar esse custo, a resposta vira lista.
• ×Tratar Lakehouse como marketing de Data Lake. O que muda é concreto: formato de tabela com transação, evolução de schema e time travel sobre armazenamento de objetos.
• ×Dizer que Data Mesh é arquitetura técnica. Os quatro princípios são organizacionais antes de tudo; sem times de domínio com dono, o Mesh vira lake bagunçado com nome novo.
• ×Confundir Source of Record com Source of Truth. SoR é onde o dado nasce; SoT é a visão consolidada e governada usada para decidir. Podem ser sistemas diferentes sem que ninguém esteja errado.
• ×Responder que a fonte da verdade é sempre o core bancário. Para saldo em tempo real, sim; para o número do relatório regulatório de fechamento, a verdade é a visão consolidada e datada, não a tela do momento.
• ×Propor Data Mesh para uma empresa com um time de dados de oito pessoas. Governança federada e plataforma self-serve exigem escala organizacional; abaixo dela, é overhead.

Vocabulário

Source of Record

— O sistema onde o dado nasce e que é autoritativo sobre o fato original.

Source of Truth

— A visão consolidada, tratada e governada que a organização usa para decidir.

AWS para engenharia de dados

A stack do time é AWS mais Databricks, então a banca vai testar se você sabe onde cada serviço encaixa e quanto ele custa. A pergunta de custo do Athena é quase certa, porque separa quem já pagou a conta de quem só leu a documentação.

Como cai: Uma consulta no Athena custou caro. O que você olha primeiro?

Erros comuns

• ×Achar que Athena cobra por tempo de consulta. A cobrança padrão é por volume de dados varridos, então otimizar é reduzir bytes lidos, não segundos gastos.
• ×Criar partição no S3 e esquecer de registrar no catálogo. Sem MSCK REPAIR, ALTER TABLE ADD PARTITION, crawler ou partition projection, o Athena não enxerga a partição e continua varrendo tudo.
• ×Escolher Redshift para consulta exploratória esporádica sobre o lake. Você paga cluster ligado o tempo todo para um uso que o Athena atenderia sob demanda.
• ×Usar EMR por hábito onde Glue ou Databricks resolveriam. EMR entrega controle do cluster e da versão do Spark, e cobra isso em operação e tuning.
• ×Tratar Lake Formation como sinônimo de bucket policy. Ele dá permissão fina por tabela, coluna e linha sobre o catálogo, coisa que política de S3 não expressa.
• ×Anexar policy larga na role do job para destravar o deploy. Menor privilégio é requisito em banco, e a banca pergunta como você restringiria depois.
• ×Guardar arquivo pequeno demais no S3. Milhares de arquivos de poucos KB destroem a performance do Athena e do Spark por sobrecarga de listagem e abertura.

Segurança e privacidade de dados em banco

Em banco, privacidade não é assunto jurídico: é requisito de arquitetura. A banca usa este tema para ver se você projeta pensando em quem pode ver o quê, ou se joga tudo cru no lake e resolve depois. Também é o tema em que responder 'a gente criptografa' sem qualificar derruba a nota.

Como cai: Um analista precisa cruzar transações por cliente sem ver o CPF. Como você resolve?

Erros comuns

• ×Dizer que dado pseudonimizado está fora da LGPD. Só o dado anonimizado sai do escopo da lei; pseudonimizado continua sendo dado pessoal, porque existe uma chave que reverte a operação.
• ×Chamar hash de CPF de anonimização. O hash é determinístico e o universo de CPFs é pequeno e enumerável: dá para montar a tabela inteira por força bruta e reidentificar todo mundo.
• ×Tratar mascaramento como se fosse criptografia. Mascaramento age na exibição do dado; criptografia protege o dado armazenado ou em trânsito. Cada um responde a uma ameaça diferente.
• ×Achar que criptografia em repouso resolve acesso indevido. Quem tem permissão de leitura recebe o dado já decifrado; contra o analista curioso o controle é RBAC, ABAC e máscara de coluna.
• ×Confundir base legal com consentimento. Consentimento é uma das dez hipóteses do art. 7º; em banco a maior parte do tratamento se apoia em execução de contrato, obrigação legal, prevenção à fraude e proteção ao crédito.
• ×Despejar tudo cru na zona raw e adiar a proteção para a camada de consumo. A raw costuma ser a zona com menos controle e mais retenção: é ali que o vazamento acontece.
• ×Esquecer o direito de eliminação no desenho. Formato imutável, backup e log de auditoria transformam um DELETE simples em projeto se ninguém pensou nisso antes.

Vocabulário

RBAC

— Acesso concedido pelo papel do usuário.

ABAC

— Acesso decidido por atributos do usuário e do dado no momento da consulta.

DataOps e observabilidade

Todo candidato sabe construir um pipeline. A banca quer saber o que acontece quando ele quebra em silêncio, que é o modo de falha mais caro em banco. Este tema separa quem entrega job de quem entrega dado confiável.

Como cai: Como você descobre que um pipeline entregou dado errado antes do usuário descobrir?

Erros comuns

• ×Confundir monitoramento de job com observabilidade de dado. Job verde e dado errado é o cenário mais comum: o pipeline rodou, só entregou lixo.
• ×Testar só na camada final. Quando o erro aparece na gold, a causa já está três camadas atrás e o reprocessamento é caro.
• ×Alertar em tudo. Alerta que dispara toda semana e ninguém investiga é ruído: treina o time a ignorar, incluindo o alerta que importava.
• ×Achar que contrato de dados é documentação. Contrato é acordo com esquema, semântica, prazo e consequência declarada quando alguém quebra.
• ×Reprocessar com append. Rodar o mesmo dia duas vezes e duplicar transação é o defeito mais visível de pipeline não idempotente.
• ×Deixar CI/CD de fora porque 'não dá para testar sem dado de produção'. Dá: esquema, transformação em amostra sintética e contrato são testáveis sem tocar em PII.
• ×Tratar linhagem como diagrama bonito. Linhagem é o que responde, às três da manhã, quais dashboards param se esta tabela estiver errada.

Vocabulário

linhagem

— Registro de origem e destino de cada tabela e coluna ao longo do pipeline.

Custo e performance

Engenheiro júnior faz o pipeline rodar; sênior faz rodar barato e explica a conta. Em banco, com volume alto e plataforma paga por uso, a banca usa este tema para ver se você raciocina com número ou com palpite.

Como cai: A fatura do lake dobrou em um mês. Como você investiga?

Erros comuns

• ×Otimizar antes de medir. Sem Spark UI, plano de execução ou relatório de custo, você está adivinhando qual das quatro alavancas mexer.
• ×Achar que o problema é sempre o cluster. Na maioria dos casos de lake, o gargalo é layout de arquivo e volume varrido, não falta de CPU.
• ×Particionar por coluna de alta cardinalidade, como CPF ou id_transacao. Gera milhares de diretórios com arquivos minúsculos e piora tudo.
• ×Confundir particionamento com Z-ORDER. Partição elimina diretórios inteiros na leitura; Z-ORDER organiza dentro dos arquivos para o data skipping funcionar.
• ×Usar spot para tudo. Interrupção no driver mata o job; em janela crítica com SLA regulatório, a economia não paga o risco.
• ×Rodar cluster interativo para carga agendada. Cluster de job sobe, executa e morre; cluster interativo ocioso cobra por estar de pé.
• ×Guardar tudo para sempre na classe padrão de armazenamento. Sem política de ciclo de vida e sem VACUUM, você paga por versões que ninguém vai ler.

Vocabulário

data skipping

— pular arquivos com base nas estatísticas gravadas

Como responder na sabatina

A sabatina avalia raciocínio em voz alta, não recall. Dois candidatos com o mesmo conhecimento tiram notas diferentes por causa de estrutura de resposta. Este é o único tema que melhora sua nota em todos os outros.

Como cai: Você não sabe a resposta. O que faz?

Erros comuns

• ×Responder rápido demais. Começar a falar em dois segundos sinaliza reflexo, não raciocínio, e você perde a chance de fazer a pergunta que reduziria o escopo.
• ×Monólogo de dez minutos. A banca precisa cobrir vários assuntos; quem não devolve a palavra é interrompido e leva a nota de quem não sabe ouvir.
• ×Jargão sem explicar. Dizer shuffle, CDC ou idempotência sem uma frase de tradução não prova domínio, prova que você decorou o termo.
• ×Negar a premissa da pergunta. Se o entrevistador diz 'o pipeline está lento', responder 'mas não deveria estar' queima tempo. Aceite o cenário e trabalhe dentro dele.
• ×Chutar quando não sabe. Um chute errado contamina toda a resposta anterior; dizer o que você faria para descobrir mantém a credibilidade e ainda mostra método.
• ×Só teoria, sem exemplo. Resposta correta e genérica pontua menos que resposta correta com um caso que você viveu, mesmo pequeno.
• ×Fechar sem recomendar. Listar três opções e não escolher nenhuma é o jeito mais comum de parecer indeciso justamente quando você tinha a resposta certa.