← Voltar a Data Engineer — Indicium-AI

📇 Flashcards — Revisão Rápida

Data Engineer — Indicium-AI

Apresentação

📇 Flashcards — Data Engineer (Revisão Robusta)

Foco desta entrevista: Migration, SQL, Modelling, Modern data tooling. Exercícios em pseudo-code/whiteboard.

Conteúdo em Português, com versões para dizer em voz alta (spoken). Lê cada cartão, tenta responder em 20–30s, depois diz a spoken version.

Prioridade A — Migração (CRÍTICO para esta entrevista)

0a. Big Bang vs Phased

  • Pergunta: Big Bang vs Phased — quando cada um?
  • Resposta: Big Bang: sistema pequeno, janela aceitável. Phased: sistema grande, zero-downtime, rollback mais fácil.
  • Spoken: "Big Bang migra tudo de uma vez — risco alto mas simples. Phased migra por módulos — menos risco, rollback mais fácil."

0b. Validação pós-migração

  • Pergunta: Como validas que a migração foi bem-sucedida?
  • Resposta: Row count, checksums, amostragem, queries de negócio. Parallel run antes do cutover.
  • Spoken: "Row count por tabela, checksums em colunas críticas, amostragem de linhas, e corro as mesmas queries de negócio nos dois sistemas."

0c. CDC vs Full load

  • Pergunta: CDC vs batch full load — quando usar?
  • Resposta: CDC: dados que mudam frequentemente. Full load: histórico estático, carga inicial.
  • Spoken: "CDC para dados transacionais em tempo real. Full load para carga inicial ou tabelas que raramente mudam."

0d. Plano de rollback

  • Pergunta: O que incluis num plano de rollback?
  • Resposta: Backup antes do cutover; procedimento documentado; se phased, reverter só o último incremento.
  • Spoken: "Backup antes de cortar, procedimento escrito para reverter, e se for phased só revertemos o último módulo."

Prioridade A — Fundamentos (obrigatório)

  1. Star vs Snowflake
  • Pergunta: Diferença entre Star e Snowflake Schema?
  • Resposta: Star: fact central + dimensões planas, joins diretos. Snowflake: dimensões normalizadas com sub-dimensões, menos redundância, mais joins.
  • Spoken: "No Star tens uma fact table no centro e dimensões que ligam diretamente. No Snowflake as dimensões estão normalizadas — há sub-dimensões —, o que reduz redundância mas complica as queries."
  1. Fact vs Dimension
  • Pergunta: O que é fact table vs dimension table?
  • Resposta: Fact: medidas/eventos, FKs para dimensões, métricas. Dimension: contexto descritivo (quem, o quê, quando).
  • Spoken: "A fact table guarda o que aconteceu — vendas, cliques — com chaves para as dimensões. As dimensões dão o contexto — produto, cliente, data."
  1. SCD Type 1 vs 2
  • Pergunta: SCD Type 1 vs Type 2 — quando cada um?
  • Resposta: Type 1: overwrite, histórico não importa. Type 2: nova linha com valid_from/to, histórico importa.
  • Spoken: "Type 1 é overwrite — perdes o histórico. Type 2 adicionas nova linha e marcas a antiga como inativa — manténs histórico."
  1. Partitions (Spark)
  • Pergunta: Repartition vs Coalesce?
  • Resposta: Repartition: shuffle, redistribui. Coalesce: junta partições sem shuffle. Partições ≈ 2–4× cores.
  • Spoken: "Repartition faz shuffle e redistribui. Coalesce só junta partições — sem shuffle. Útil após um filter que reduziu muito os dados."
  1. Shuffle
  • Pergunta: O que é shuffle e porque é caro?
  • Resposta: Redistribuição de dados entre nós (joins, groupBy). Caro: I/O rede, serialização, possível skew.
  • Spoken: "Shuffle é quando os dados têm de viajar entre nós — em joins ou groupBy. É caro porque implica rede e serialização."
  1. Bronze/Silver/Gold
  • Pergunta: Propósito de cada camada na Medallion?
  • Resposta: Bronze: raw, imutável. Silver: limpo, validado, deduplicado. Gold: agregados, métricas, BI.
  • Spoken: "Bronze é o que chega, sem alterar. Silver é onde limpas e validas. Gold é onde tens as métricas de negócio para reporting."
  1. Idempotência
  • Pergunta: O que é idempotência em pipelines?
  • Resposta: Mesmo input = mesmo output. Merge/upsert, chave única. Crítico para retries.
  • Spoken: "Se correres a job duas vezes com os mesmos dados, o resultado é o mesmo. Usas merge em vez de append para evitar duplicados."
  1. Partitioning + Caching + Broadcast
  • Pergunta: As 3 alavancas de performance em Spark?
  • Resposta: Partitioning (paralelismo), Caching (reutilizar), Broadcast (join sem shuffle em tabela pequena).
  • Spoken: "Partitioning para paralelismo, cache quando reutilizas um DataFrame, broadcast para joins com tabelas pequenas sem shuffle."
  1. ETL vs ELT
  • Pergunta: ETL vs ELT — quando cada um?
  • Resposta: ETL: transforma antes de load. ELT: load primeiro, transforma no destino. ELT escala com o engine (Snowflake, Fabric).
  • Spoken: "No ETL transformas antes de carregar. No ELT carregas primeiro e transformas no destino — típico em cloud."
  1. Batch vs Streaming
  • Pergunta: Batch vs Streaming — quando cada um?
  • Resposta: Batch: relatórios, agregados, latência horas. Streaming: alertas, tempo real, latência segundos.
  • Spoken: "Batch para relatórios e histórico. Streaming quando precisas de resposta em tempo real."

Prioridade B — Spark (crítico para a vaga)

  1. Lazy evaluation
  • Pergunta: O que é lazy evaluation em Spark?
  • Resposta: Transformations constroem DAG; Actions disparam execução. Catalyst otimiza o plano.
  • Spoken: "As transformações não executam logo — constroem um plano. Só quando chamas uma action é que corre. O Catalyst otimiza antes."
  1. Broadcast join
  • Pergunta: Quando usar broadcast join?
  • Resposta: Tabela pequena (<100MB). Replica para todos os nós, sem shuffle nessa tabela.
  • Spoken: "Quando uma das tabelas é pequena, fazes broadcast — ela é replicada para todos os nós e evitas shuffle."
  1. Data skew
  • Pergunta: O que é data skew e como mitigar?
  • Resposta: Partições desequilibradas — algumas com muito mais dados. Salting (coluna aleatória), split da partição grande.
  • Spoken: "Skew é quando algumas partições têm muito mais dados que outras. Mitigas com salting — adicionas uma coluna aleatória para repartir melhor."
  1. DataFrame vs RDD
  • Pergunta: Porque preferir DataFrame a RDD?
  • Resposta: DataFrame tem Catalyst (otimização), API SQL-like, melhor performance. RDD é low-level.
  • Spoken: "DataFrame passa pelo Catalyst que otimiza o plano. RDD é mais manual. Para 99% dos casos, DataFrame."
  1. Job Spark lento — diagnóstico
  • Pergunta: O teu job Spark está lento. O que verificas?
  • Resposta: Shuffle excessivo, skew, falta de broadcast, sem cache em reutilização, muitos ficheiros pequenos, partições mal dimensionadas.
  • Spoken: "Verifico shuffle — há joins sem broadcast? Skew nas partições? Estou a reutilizar um DataFrame sem cache? Muitos ficheiros pequenos no read ou write?"
  1. Sort-Merge Join
  • Pergunta: O que é Sort-Merge Join e quando acontece?
  • Resposta: Ambas as tabelas partidas pela join key; merge local. Shuffle em ambas. Quando as tabelas são grandes.
  • Spoken: "É o join default para tabelas grandes. Ambas são partidas pela chave, há shuffle, e depois merge local em cada partição."
  1. Predicate pushdown
  • Pergunta: O que é predicate pushdown?
  • Resposta: O Catalyst empurra filtros para o mais perto possível da fonte (ex: Parquet). Lê menos dados.
  • Spoken: "O otimizador empurra os filtros para baixo — para o Parquet, por exemplo — para que leias menos dados."
  1. Coalesce antes de write
  • Pergunta: Porque fazer coalesce antes de escrever?
  • Resposta: Evitar muitos ficheiros pequenos (small files problem). Cada partição vira um ficheiro.
  • Spoken: "Se escreveres com muitas partições, tens muitos ficheiros pequenos — lento em leituras futuras. Coalesce reduz o número."

Prioridade B — Lakehouse & Fabric

  1. Delta Lake
  • Pergunta: O que é Delta Lake?
  • Resposta: Parquet + log de transações. ACID, time travel, upserts, schema evolution.
  • Spoken: "É Parquet com um log de transações. Dá-te ACID, time travel e upserts — coisas que o Parquet puro não tem."
  1. Lakehouse vs Lake vs Warehouse
  • Pergunta: Porque Lakehouse em vez de Lake ou Warehouse?
  • Resposta: Lakehouse junta flexibilidade do lake (ficheiros, ML) com ACID e performance do warehouse. Um sistema para raw + analytics.
  • Spoken: "O lake é flexível mas sem ACID. O warehouse é estruturado mas caro para raw. Lakehouse combina os dois."
  1. Time travel (Delta)
  • Pergunta: O que é time travel no Delta?
  • Resposta: Consultar versões anteriores dos dados. Útil para rollback, debugging, reprocessamento.
  • Spoken: "Consegues ler o estado da tabela num ponto no tempo — para rollback ou para debugar o que mudou."
  1. Microsoft Fabric — componentes
  • Pergunta: O que inclui o Microsoft Fabric para Data?
  • Resposta: Lakehouse (OneLake, Delta), Pipelines (orquestração), Notebooks (Spark), integração com Power BI.
  • Spoken: "Lakehouse com OneLake, pipelines para orquestração, notebooks Spark, e integração com Power BI na mesma plataforma."

Prioridade B — Qualidade & Fiabilidade

  1. Pipeline estável
  • Pergunta: Como garantias que o pipeline não falha em produção?
  • Resposta: Idempotência, retry com backoff, validação de schema, monitoring, dead-letter para falhas.
  • Spoken: "Idempotência, retries, validação à entrada, monitoring e alertas. E um sítio para falhas que não consegues processar."
  1. Schema validation
  • Pergunta: Como validas o schema dos dados à entrada?
  • Resposta: Esperado vs recebido (Great Expectations, dbt tests). Checks: not null, tipos, ranges, formatos.
  • Spoken: "Defino o schema esperado e comparo com o que chega. Uso ferramentas como Great Expectations ou dbt para testes."
  1. Retry com backoff
  • Pergunta: Porque exponential backoff em retries?
  • Resposta: Evitar sobrecarregar o sistema em falhas transitórias. Espera cresce (1s, 2s, 4s...).
  • Spoken: "Se a API ou o serviço está sobrecarregado, esperar mais tempo antes de tentar de novo evita piorar a situação."
  1. Dead-letter queue
  • Pergunta: O que é dead-letter queue (DLQ)?
  • Resposta: Fila para mensagens/registos que falharam após N retries. Permite análise e reprocessamento manual.
  • Spoken: "É onde vão os registos que não consegues processar após vários retries. Depois podes analisar e corrigir."

Prioridade C — System Design & SQL

  1. Lambda vs Kappa
  • Pergunta: Lambda vs Kappa architecture?
  • Resposta: Lambda: batch + streaming em paralelo. Kappa: só streaming, batch como caso especial.
  • Spoken: "Lambda tem dois caminhos — batch para histórico, stream para tempo real. Kappa usa só stream, batch é replay."
  1. CDC (Change Data Capture)
  • Pergunta: O que é CDC e quando usar?
  • Resposta: Captura alterações em DBs (insert, update, delete). Debezium, etc. Para sincronizar DB transacional com lake.
  • Spoken: "Capturas as mudanças na base de dados em tempo real — inserts, updates, deletes — e envias para o lake."
  1. ROW_NUMBER vs RANK
  • Pergunta: ROW_NUMBER vs RANK — quando cada um?
  • Resposta: ROW_NUMBER: único por linha, sem empates. RANK: gaps em empates. DENSE_RANK: sem gaps.
  • Spoken: "ROW_NUMBER dá um número único. RANK em empates dá o mesmo número mas salta os seguintes. DENSE_RANK não salta."
  1. LAG e LEAD
  • Pergunta: O que fazem LAG() e LEAD()?
  • Resposta: LAG: valor da linha anterior na partição. LEAD: valor da linha seguinte. Útil para comparação período a período.
  • Spoken: "LAG pega o valor da linha anterior, LEAD da seguinte. Útil para 'este mês vs mês passado'."

Prioridade C — GenAI & Diferencial

  1. Data + AI-ready
  • Pergunta: Como te posicionas como Data Engineer + AI-ready?
  • Resposta: Pipelines para RAG (docs → chunk → embed → vector DB), dados para treino, qualidade para grounding.
  • Spoken: "Construí pipelines para alimentar RAG — ingestão de docs, chunking, embeddings. Entendo como os dados alimentam sistemas de AI."
  1. RAG — pipeline de dados
  • Pergunta: Que parte do RAG é responsabilidade do Data Engineer?
  • Resposta: Ingestão de documentos, chunking, geração de embeddings, carga no vector DB. O modelo de linguagem é outro componente.
  • Spoken: "O Data Engineer trata da ingestão, chunking, embeddings e carga no vector store. O LLM e o retrieval são outra camada."

Prioridade C — Vaga & Recrutamento

  1. Desafios da vaga (memorizar)
  • Pergunta: Quais os 4 desafios principais que a contratação deve resolver?
  • Resposta: Estabilizar e otimizar pipelines; melhorar processamento Spark; evolução Lakehouse em Fabric; reforçar performance, qualidade, escalabilidade, fiabilidade.
  • Spoken: "Estabilizar pipelines, melhorar Spark, evoluir o Lakehouse no Fabric, e reforçar boas práticas de performance e qualidade."
  1. Range salarial e modelo
  • Pergunta: Range salarial e modelo de trabalho desta vaga?
  • Resposta: 30–65k (experiência/senioridade). Maioritariamente remote. Office raro.
  • Spoken: "Entre 30 e 65k consoante experiência. Modelo maioritariamente remoto, ida ao office é rara."
  1. Foco da função
  • Pergunta: Qual o foco desta posição — BI ou engenharia?
  • Resposta: Arquitetura e engenharia de dados. Não é BI/analytics.
  • Spoken: "O foco é arquitetura e engenharia de dados — pipelines, Spark, Lakehouse. Não é BI ou analytics."

Perguntas para fazer ao entrevistador

  1. "Que tipo de migrações estão a fazer — legacy para cloud, ou entre plataformas?"
  2. "Como validam que a migração foi bem-sucedida?"
  3. "Qual a estratégia de cutover que preferem — big bang ou phased?"
  4. "Que ferramentas usam para migração (DMS, Fivetran, custom)?"
  5. "Como lidam com dados de baixa qualidade na origem?"
  6. "Como gerem versionamento de dados no Lakehouse?"

Frases-chave para a reunião

  • "Sempre tenho um plano de rollback documentado antes do cutover."
  • "Profiling antes de migrar — conhecer a qualidade dos dados na origem evita surpresas."
  • "CDC quando os dados mudam frequentemente; full load quando é histórico estático."
  • "Partitioning + caching + broadcast joins — são as três alavancas que mais impacto têm em jobs Spark."
  • "Idempotência é crítica — merge em vez de append, chave única, para que retries não corrompam dados."

Zona de prática

Sem perguntas. Clica em Editar para adicionar.